Bild-SEO: Bilder suchmaschinenfreundlich einbinden

Bild-SEO heißt: Suchmaschinen müssen verstehen können, was auf einem Bild zu sehen ist, und der Browser muss es schnell ausliefern können. Das Erste erledigen Dateiname, Alt-Text, Bildunterschrift und der Text ringsum; das Zweite Format, Größe und die vier Attribute srcset, sizes, loading und fetchpriority.

Bilder sind Inhalt, kein Beiwerk. Sie bringen über die Bildersuche eigenen Traffic, sie stützen die Relevanz einer Seite – und falsch eingebunden sind sie der schnellste Weg zu einer langsamen Website. Der Median einer mobilen Startseite liegt bei rund 911 KB reinen Bilddaten, auf dem Desktop bei etwa 1.058 KB. Kein anderer Ressourcentyp wiegt so schwer.

Das Wichtigste in Kürze

• Nur Bilder im src eines <img> werden indexiert. CSS-Hintergrundbilder tauchen in der Bildersuche nicht auf.
• Der Alt-Text ist der eine Text mit zwei Aufgaben: Er ersetzt das Bild für blinde Nutzende und ist das, was eine Suchmaschine vom Motiv versteht.
• Genau ein Bild pro Seite bekommt fetchpriority="high": das LCP-Bild. Und genau dieses Bild bekommt niemals loading="lazy".
• sizes beschreibt die Anzeigebreite, nicht die Dateibreite. Fehlt es, rechnet der Browser mit 100vw und lädt in jedem begrenzten Layout zu groß.
• width und height als HTML-Attribute reservieren den Platz, bevor CSS geladen ist – dagegen hilft kein aspect-ratio im Stylesheet.
• AVIF zuerst, WebP als Fallback, JPEG als letzte Stufe – beide modernen Formate sind heute praktisch überall verfügbar.

Was Google von einem Bild überhaupt sieht

Bevor es um Optimierung geht, lohnt der nüchterne Blick darauf, was überhaupt ankommt. Google indexiert Bilder, die im src-Attribut eines <img>-Elements stehen, in den Formaten BMP, GIF, JPEG, PNG, WebP, SVG und AVIF. Alles andere ist unsichtbar – und „alles andere“ heißt vor allem: CSS-Hintergrund­bilder.

/* Für die Bildersuche existiert dieses Bild nicht */
.hero { background-image: url("/img/schreibtisch.jpg"); }

Das ist keine Kleinigkeit. Wer sein bestes Produktfoto als background-image einbaut, verzichtet auf die Bildersuche, auf den Alt-Text und auf die Chance, dass das Bild als Vorschaubild für die Seite gewählt wird. Es gibt dafür auch keinen Trick: kein aria-label, kein Sitemap-Eintrag, kein verstecktes <img> daneben. Hintergrundbilder sind für Dekoration da – Inhalt gehört ins <img>.

Der zweite blinde Fleck ist die Zeit. Googles Crawler scrollen und klicken nicht. Ein Bild, das erst nach einer Nutzerinteraktion oder beim Scrollen per JavaScript in den src geschrieben wird, steht im gerenderten HTML nicht drin – und damit auch nicht im Index.

Dateiname, Pfad und Umgebung

Der Dateiname ist ein schwaches Signal, aber ein kostenloses. Google nennt in seiner eigenen Dokumentation das Beispiel my-new-black-kitten.jpg gegenüber IMG00023.JPG – er gibt „Hinweise auf das Motiv“. Mehr sollte man sich davon nicht versprechen: Ein Rankingfaktor ist er nicht, und Bindestrich-Keywords im Dateinamen haben noch nie eine Position bewegt.

• Kleingeschrieben, mit Bindestrichen, ohne Umlaute und Leerzeichen. bürostuhl übersicht.jpg wird zu b%C3%BCrostuhl%20%C3%BCbersicht.jpg und ist damit weder lesbar noch teilbar.
• Dieselbe URL für dasselbe Bild, über alle Seiten hinweg. Wechselnde Bild-URLs für identische Motive verteilen die Signale auf mehrere Objekte.
• Ein thematisch passender Ordner (/img/buero/…) hilft bei großen Beständen der Einordnung.

Genauso wichtig ist die Umgebung: Suchmaschinen werten Seitentitel, Überschriften und den Text direkt um das Bild herum aus. Ein Bild im passenden Abschnitt wird besser verstanden als eines im Niemandsland zwischen zwei Themen.

Alt-Text: ein Text, zwei Aufgaben

Das alt-Attribut beschreibt den Bildinhalt – für blinde Nutzende und für Suchmaschinen, die das Bild nicht „sehen“ können. Wie du gute Alternativtexte formulierst, zeigt ausführlich Alt-Texte richtig schreiben; fürs SEO gilt dieselbe Regel wie für die Barrierefreiheit: beschreiben, nicht vollstopfen.

<!-- Falsch: eine Keyword-Liste, die niemandem hilft -->
<img src="/img/stuhl.webp" alt="Bürostuhl Bürostuhl kaufen ergonomisch günstig Büromöbel Berlin">

<!-- Falsch: der Dateiname als Alternativtext -->
<img src="/img/img-2931.webp" alt="img-2931.webp">

<!-- Richtig: beschreibt, was zu sehen ist -->
<img src="/img/stuhl.webp" alt="Bürostuhl mit Netzrücken, Armlehnen und Rollen, seitlich fotografiert">

Google stuft Keyword-Stuffing im alt-Attribut ausdrücklich als Verhalten ein, das dazu führen kann, dass eine Seite als Spam eingestuft wird. Eine automatische Strafe ist das nicht – aber ein schlechtes Geschäft: Der Text wird schlechter und der Gewinn ist bestenfalls null.

Drei Details, die regelmäßig durcheinandergehen:

• Dekorative Bilder bekommen alt="" – das Attribut ist vorhanden, der Wert leer. Das Attribut wegzulassen ist etwas völlig anderes: Dann liest ein Screenreader im Zweifel den Dateinamen vor.
• Ist das Bild ein Link oder Button, beschreibt der Alt-Text das Ziel der Aktion, nicht das Motiv.
• Das title-Attribut ersetzt nichts. Es wird von Screenreadern uneinheitlich ausgegeben, ist per Tastatur und auf Touch-Geräten nicht erreichbar und bringt fürs SEO nichts.

Zur Einordnung: Laut Web Almanac 2024 haben nur 55 % aller Bilder im Web einen nicht-leeren Alternativtext. Ein Teil der übrigen 45 % ist korrekt als dekorativ ausgezeichnet – der größere Teil ist es nicht.

Format wählen: JPEG, WebP oder AVIF

Die Formatfrage ist die mit dem größten Hebel pro Minute Arbeit. Googles eigene Messwerte für WebP: verlustfreie WebP-Bilder sind 26 % kleiner als PNGs, verlustbehaftete 25–34 % kleiner als vergleichbare JPEGs bei gleichem Qualitätsindex; verlustbehaftetes WebP mit Transparenz ist typischerweise dreimal kleiner als PNG. AVIF komprimiert in der Praxis noch einmal deutlich besser – belastbare Herstellerzahlen dazu gibt es allerdings nicht, deshalb sollte man sich hier auf eigene Messungen verlassen statt auf kursierende Prozentwerte.

Beim Support ist die Diskussion inzwischen weitgehend erledigt (caniuse, Abruf 27. Juli 2026):

Die Faustregel, mit der ich gut fahre: AVIF anbieten, WebP als Fallback, JPEG als letzte Stufe. Für Fotos ist verlustbehaftete Kompression richtig, für Grafiken mit harten Kanten und wenigen Farben ist verlustfreies WebP oder PNG oft kleiner als AVIF. Und für alles, was aus Vektoren besteht – Logos, Icons, Diagramme – ist SVG konkurrenzlos, weil es bei jeder Größe scharf bleibt und meist nur wenige Kilobyte wiegt.

<picture> für Formate und Bildausschnitte

Der Unterschied zwischen srcset und <picture> verwirrt zuverlässig, dabei ist die Regel einfach:

• Dasselbe Motiv in mehreren Größen → srcset und sizes direkt am <img>.
• Anderes Dateiformat oder anderer Bildausschnitt → <picture> mit <source>.

Formatumschaltung: Der Browser nimmt die erste <source>, deren Typ er versteht. Reihenfolge ist deshalb entscheidend – erst AVIF, dann WebP, dann das <img> als Fallback.

<picture>
  <source type="image/avif" srcset="/img/schreibtisch.avif">
  <source type="image/webp" srcset="/img/schreibtisch.webp">
  <img
    src="/img/schreibtisch.jpg"
    alt="Höhenverstellbarer Schreibtisch in Stehhöhe, daneben ein Bürostuhl"
    width="1600"
    height="900"
    loading="lazy"
    decoding="async"
  />
</picture>

Wichtig dabei: alt, width, height, loading, decoding und fetchpriority gehören ans <img>, nicht an die <source>-Elemente. Das <img> ist der eigentliche Inhalt; die <source> sind nur Alternativangebote.

Art Direction – also ein wirklich anderer Bildausschnitt auf kleinen Geräten – läuft über media:

<picture>
  <source media="(max-width: 40em)" srcset="/img/team-hochformat-600.avif">
  <img src="/img/team-quer-1600.avif" alt="Das fünfköpfige Team im Großraumbüro" width="1600" height="900">
</picture>

Nur 9,3 % der Seiten nutzen <picture> überhaupt (Web Almanac 2024) – meistens zu Recht, denn für den Normalfall reicht srcset.

srcset und sizes richtig rechnen

Hier passiert der teuerste Fehler im Bild-SEO, weil er unsichtbar ist. Zwei Deskriptor-Arten stehen zur Wahl:

• w-Deskriptoren (bild-800.avif 800w) geben die echte Pixelbreite der Datei an. Sie brauchen zwingend ein passendes sizes.
• x-Deskriptoren (bild@2x.avif 2x) sind für Bilder mit fester Anzeigegröße – dort ist sizes wirkungslos und darf weg.

Und jetzt der Punkt, an dem fast alle stolpern: sizes beschreibt, wie breit das Bild im Layout dargestellt wird – nicht, wie breit die Datei ist. Der Browser rechnet daraus zusammen mit der Pixeldichte des Geräts den Bedarf aus und greift erst dann in die srcset-Liste.

Der Klassiker sieht so aus:

<!-- Falsch: das Bild füllt nur die halbe Spalte, sizes behauptet volle Breite -->
<img srcset="foto-480.avif 480w, foto-960.avif 960w, foto-1920.avif 1920w"
     sizes="100vw" src="foto-960.avif" alt="…">

<!-- Richtig: sizes bildet das echte Layout ab -->
<img srcset="foto-480.avif 480w, foto-960.avif 960w, foto-1920.avif 1920w"
     sizes="(max-width: 40em) 100vw, (max-width: 64em) 50vw, 800px"
     src="foto-960.avif" alt="…">

Und wenn sizes ganz fehlt? Dann nimmt der Browser bei w-Deskriptoren 100vw an – also die volle Fensterbreite. In jedem mehrspaltigen oder in der Breite begrenzten Layout lädt er damit systematisch zu groß. MDN beziffert den Unterschied an einem Beispiel: 128 KB für die 800-px-Datei gegenüber 63 KB für die 480-px-Datei; auf dem Handy also 65 KB, die niemand braucht.

Randnotiz – sizes="auto" ist noch keine Lösung. Das Schlüsselwort lässt den Browser die tatsächliche Layoutbreite selbst ermitteln, klingt also nach dem Ende aller Rechnerei. Es ist laut HTML-Spezifikation aber nur zusammen mit loading="lazy" gültig – für das LCP-Bild damit grundsätzlich ausgeschlossen – und Safari wertet es Stand Juli 2026 nicht aus. Wer es nutzt, gibt Fallback-Werte dahinter an: sizes="auto, (max-width: 30em) 100vw, 50vw".

Das LCP-Bild: die eine Regel, die wirklich zählt

Auf 85,3 % der Desktop- und 76,0 % der mobilen Seiten ist ein Bild das LCP-Element – also das größte Inhaltselement im ersten sichtbaren Bereich und damit der Wert, der über den Core-Web-Vitals-Test entscheidet. Für dieses eine Bild gelten zwei Regeln:

1. fetchpriority="high" – damit der Browser es vor Skripten und Stylesheets anfordert.
2. Kein loading="lazy". Niemals.

Die zweite Regel klingt selbstverständlich und wird trotzdem massenhaft gebrochen: Rund 16–17 % der Seiten mit einem Bild-LCP verzögern genau dieses Bild selbst – 10,4 % (mobil) beziehungsweise 11,5 % (Desktop) durch natives loading="lazy", weitere 5,9 % durch JavaScript-Lösungen mit data-src.

Besonders tückisch ist die Kombination beider Attribute am selben Bild: Das Bild bleibt zurückgestellt, solange es außerhalb des Viewports ist, und wird erst danach mit hoher Priorität geladen. Der Prioritätsgewinn verpufft, der Verlust bleibt.

<!-- Falsch: hebt sich gegenseitig auf -->
<img src="hero.avif" loading="lazy" fetchpriority="high" alt="…">

<!-- Falsch: fünf Bilder mit hoher Priorität sind wie kein Bild mit hoher Priorität -->
<img src="a.avif" fetchpriority="high"> <img src="b.avif" fetchpriority="high"> …

fetchpriority wird von allen aktuellen Browsern unterstützt; die späten Nachzügler waren Firefox (ab 132) und Safari (ab 17.2). Eingesetzt wird es auf 17,3 % der mobilen und 16,3 % der Desktop-Seiten – Tendenz steigend.

Ein <link rel="preload" as="image"> brauchst du dafür in der Regel nicht: Steht das <img> mit fetchpriority="high" im ausgelieferten HTML, findet der Preload-Scanner es ohnehin sofort. Lohnend ist der Preload nur, wenn das Bild erst über CSS oder JavaScript entdeckt wird – und dann müssen imagesrcset und imagesizes exakt mit dem <img> übereinstimmen, sonst lädt der Browser zwei Dateien:

<link rel="preload" as="image"
      href="/img/hero-800.avif"
      imagesrcset="/img/hero-480.avif 480w, /img/hero-800.avif 800w, /img/hero-1600.avif 1600w"
      imagesizes="(max-width: 40em) 100vw, 800px"
      fetchpriority="high">

Lazy Loading für alles darunter

Unterhalb des ersten Viewports ist loading="lazy" dagegen genau richtig und kostet nichts. Chrome lädt solche Bilder vor, sobald sie 1250 px (schnelle Verbindung) beziehungsweise 2500 px (langsame Verbindung) an den sichtbaren Bereich heranrücken – im Test waren dadurch 97,5 % der Bilder innerhalb von 10 Millisekunden nach dem Sichtbarwerden fertig. Sichtbares Nachladen erlebt man damit praktisch nicht. (Diese Schwellen sind Chromes dokumentierte Werte; Firefox und Safari nutzen eigene, nicht veröffentlichte Heuristiken.)

decoding="async" gehört als Gewohnheit dazu: Es erlaubt dem Browser, das Bild zu dekodieren, ohne das Rendering zu blockieren. Auf den LCP hat es typischerweise keinen messbaren Effekt – es ist Hygiene, keine Optimierung.

Was nicht mehr in einen Neubau gehört, ist das alte data-src-Muster mit eigenem JavaScript. Es hängt die Bilder an die Ausführung eines Skripts, ist für Crawler riskant und verzögert nachweislich LCP-Bilder. Wenn es zwingend JavaScript sein muss, dann per IntersectionObserver – so empfiehlt es auch Google.

Keine Layout-Sprünge

width und height als HTML-Attribute (unitlos, mit den echten Maßen der Datei) sind der einfachste Performance-Gewinn überhaupt: Der Browser reserviert den Platz, bevor auch nur ein Byte des Bildes geladen ist. Dazu gehört im Stylesheet:

img { max-width: 100%; height: auto; }

Ohne diese zwei CSS-Zeilen verzerrt das Bild, sobald die Breite skaliert. Und aspect-ratio im CSS ersetzt die Attribute nicht – es wirkt erst, wenn das Stylesheet geladen ist, die Attribute wirken sofort. Trotzdem tragen laut Web Almanac 2024 nur 32 % aller Bilder überhaupt width und height.

Zwei Vorlagen zum Übernehmen

Der ganze Unterschied zwischen dem wichtigsten Bild und allen anderen steckt in zwei Attributen:

<!-- Hero- bzw. LCP-Bild: früh laden, hohe Priorität, kein lazy -->
<img
  src="/img/hero-800.avif"
  srcset="/img/hero-480.avif 480w, /img/hero-800.avif 800w, /img/hero-1600.avif 1600w"
  sizes="(max-width: 40em) 100vw, 800px"
  width="1600"
  height="900"
  fetchpriority="high"
  decoding="async"
  alt="Höhenverstellbarer Schreibtisch in Stehhöhe, Bedienpanel an der Tischkante"
/>

<!-- Inhaltsbild weiter unten: lazy, normale Priorität -->
<img
  src="/img/detail-800.avif"
  srcset="/img/detail-480.avif 480w, /img/detail-800.avif 800w, /img/detail-1600.avif 1600w"
  sizes="(max-width: 40em) 100vw, 800px"
  width="1600"
  height="900"
  loading="lazy"
  decoding="async"
  alt="Nahaufnahme des Bedienpanels mit vier Speicherplätzen für Sitzhöhen"
/>

Kontext und Bildunterschrift

Eine sichtbare Bildunterschrift mit <figure> und <figcaption> verstärkt die thematische Zuordnung – und Bildunterschriften werden überdurchschnittlich oft gelesen.

<figure>
  <img src="/img/kontrast-pruefung.avif" alt="Zwei Farbpaare nebeneinander, das linke mit dem Wert 7,1 zu 1, das rechte mit 2,3 zu 1" width="800" height="450" loading="lazy">
  <figcaption>Das linke Paar besteht die WCAG-Anforderung, das rechte nicht.</figcaption>
</figure>

Die Regel dabei: alt und figcaption dürfen nicht denselben Text enthalten. Der Alt-Text ersetzt das Bild, die Bildunterschrift ergänzt es – sind beide identisch, hört ein Screenreader alles doppelt. Bei einem rein illustrativen Bild mit erklärender Unterschrift kann alt="" sogar die richtige Wahl sein.

Bild-Sitemap: kleiner geworden

Eine Bild-Sitemap hilft Google, Bilder zu finden, die im HTML nicht ohne Weiteres sichtbar sind – etwa weil sie per JavaScript nachgeladen werden. Eine Ranking-Maßnahme ist sie nicht.

Wichtig ist der aktuelle Stand: Google dokumentiert seit Dezember 2025 nur noch zwei Tags. <image:caption>, <image:title>, <image:license> und <image:geo_location> sind aus der Doku verschwunden und werden nicht mehr ausgewertet – viele Ratgeber zeigen sie trotzdem noch.

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://beispiel.de/buero/schreibtische.html</loc>
    <image:image>
      <image:loc>https://beispiel.de/img/schreibtisch.avif</image:loc>
    </image:image>
  </url>
</urlset>

Pro <url>-Eintrag sind bis zu 1.000 <image:image>-Tags erlaubt. Wie das in die normale Sitemap passt, steht unter robots.txt & Sitemaps.

Das Vorschaubild steuern – neu seit März 2026

Am 2. März 2026 hat Google seine Bilder-Dokumentation um einen Abschnitt erweitert, den bislang kaum ein deutschsprachiger Ratgeber abbildet: Für die Auswahl des Vorschaubilds in Suche und Discover zieht Google sowohl schema.org-Auszeichnungen (primaryImageOfPage beziehungsweise image am mainEntity) als auch das og:image-Meta-Tag heran.

<meta property="og:image" content="https://beispiel.de/img/schreibtisch-1600.jpg">

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "url": "https://beispiel.de/buero/schreibtische.html",
  "primaryImageOfPage": {
    "@type": "ImageObject",
    "contentUrl": "https://beispiel.de/img/schreibtisch-1600.jpg",
    "width": 1600,
    "height": 900
  }
}

Zwei Dinge sind wichtig: og:image verlangt absolute URLs – relative Pfade werden ignoriert. Und das ist kein Ranking-Signal, sondern eine Angabe zur Darstellung. Google rät außerdem von generischen Motiven wie Logos und von extremen Seitenverhältnissen ab.

Wer in Google Discover auftauchen will, braucht zusätzlich große Bilder: mindestens 1.200 px Breite, mehr als 300.000 Gesamtpixel, Seitenverhältnis 16:9 – und die Erlaubnis für große Vorschauen:

<meta name="robots" content="max-image-preview:large">

Mehr zu diesem Tag und zu Social-Vorschauen steht unter Open Graph & Social.

Lizenz- und Urhebermetadaten

Wer eigene Fotos veröffentlicht, kann sie in Google Bilder als lizenzierbar kennzeichnen lassen. Pflicht ist ein ImageObject mit contentUrl plus mindestens einer der Eigenschaften creator, creditText, copyrightNotice oder license. Für den sichtbaren „Licensable“-Hinweis ist konkret die Eigenschaft license erforderlich; acquireLicensePage empfiehlt Google zusätzlich, damit Interessierte direkt zur Lizenzseite kommen.

{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://beispiel.de/img/schreibtisch-1600.jpg",
  "license": "https://beispiel.de/bildlizenz.html",
  "acquireLicensePage": "https://beispiel.de/bild-kaufen.html",
  "creditText": "Foto: Beispiel GmbH",
  "creator": { "@type": "Person", "name": "Anna Beispiel" },
  "copyrightNotice": "© 2026 Beispiel GmbH"
}

Bild-SEO und Barrierefreiheit sind dieselbe Arbeit

Das ist der Punkt, an dem dieses Thema für mich zusammenläuft: Fast jede Maßnahme, die ein Bild auffindbar macht, macht es zugleich zugänglich – und umgekehrt.

• Der Alt-Text erfüllt gleichzeitig WCAG 1.1.1 Nicht-Text-Inhalte (Stufe A) und liefert Suchmaschinen die Bildbeschreibung.
• Text im Bild ist doppelt schlecht: nicht durchsuchbar, nicht skalierbar, nicht kontrastanpassbar – siehe 1.4.5 Bilder von Text (Stufe AA). Ausgenommen sind Logos und Fälle, in denen die genaue Darstellung wesentlich ist.
• Bedeutungstragende Grafikelemente brauchen 3:1 Kontrast (1.4.11) – ein Diagramm mit hellgrauen Linien auf Weiß ist für viele schlicht leer.
• Inline-SVG braucht einen eigenen Namen:

<svg role="img" aria-labelledby="titel-diagramm" viewBox="0 0 400 200">
  <title id="titel-diagramm">Balkendiagramm: Bildanteil am Seitengewicht 2021 bis 2026</title>
  <!-- Pfade -->
</svg>

<!-- Rein dekoratives SVG -->
<svg aria-hidden="true" focusable="false" viewBox="0 0 24 24"><!-- Pfad --></svg>

Seit dem 28. Juni 2025 ist das für viele Anbieter nicht mehr nur guter Stil: Das BFSG verpflichtet bestimmte Produkte und Dienstleistungen im Verbrauchergeschäft – mit Ausnahmen etwa für Kleinstunternehmen. Ob es dich betrifft, klärt die BFSG-Prüfung.

Prüfen und messen

• PageSpeed Insights / Lighthouse: Das Audit „Largest Contentful Paint image was lazily loaded“ findet den teuersten Fehler in Sekunden. Ebenso „Properly size images“ und „Serve images in next-gen formats“.
• URL-Prüfung in der Search Console: Steht das Bild im gerenderten HTML im src? Wenn nicht, wird es nicht indexiert.
• Leistungsbericht → Suchtyp „Bild“: zeigt, ob die Bildersuche überhaupt Traffic liefert.
• Rich-Results-Test für ImageObject und primaryImageOfPage.
• Selbst nachmessen: DevTools → Netzwerk → nach Bildern filtern, Spalte „Größe“ sortieren. Alles über 200 KB unter der Lupe.

Häufige Fehler

• Das LCP-Bild lazy geladen – der teuerste Bild-Fehler überhaupt.
• fetchpriority="high" auf mehreren Bildern: Sie konkurrieren um dieselbe Bandbreite, der Effekt hebt sich auf.
• sizes="100vw", obwohl das Bild nur die halbe Spalte füllt – der Browser lädt dauerhaft doppelt so große Dateien.
• srcset mit w-Deskriptoren ohne sizes – dann gilt stillschweigend 100vw.
• width/height weggelassen – Layout-Sprünge und ein schlechterer CLS-Wert.
• Wichtige Bilder als CSS-Hintergrund – unsichtbar für die Bildersuche und ohne Alternativtext.
• 4000-px-Original in einem 800-px-Slot – vier Fünftel der Bytes für nichts.
• Alt-Text mit Keywords vollgestopft oder gleich der Dateiname als Alt-Text.
• Veraltete Sitemap-Tags (image:caption, image:title, image:license).
• Text als Bild, der dadurch unsuchbar und schlecht zugänglich wird.

Häufige Fragen

WebP oder AVIF?

Beides. AVIF komprimiert besser, WebP ist minimal breiter unterstützt (96,2 % gegenüber 93,4 %). Mit <picture> bietest du AVIF an und fällst automatisch auf WebP oder JPEG zurück – dann musst du dich gar nicht entscheiden.

Zählt der Dateiname 2026 noch?

Als schwacher Hinweis auf das Motiv, ja – Google nennt ihn ausdrücklich. Als Rankinghebel nein. Sprechende Namen kosten nichts, also nimmt man sie mit; mehr Aufwand als drei Sekunden ist es nicht wert.

Wie viele Bilder dürfen fetchpriority="high" bekommen?

Genau eines: das LCP-Bild. Chrome stuft die ersten großen Bilder ohnehin automatisch etwas höher ein; ein explizites high wirkt deutlich stärker, verliert diese Wirkung aber, sobald mehrere Bilder darum konkurrieren.

Brauche ich eine eigene Bild-Sitemap?

Nur, wenn Google deine Bilder im HTML nicht findet – typischerweise bei per JavaScript nachgeladenen Galerien oder sehr großen Beständen. Für eine normale Website mit <img>-Elementen im ausgelieferten HTML bringt sie nichts.

Hilft og:image dem Ranking?

Nein. Es beeinflusst, welches Bild als Vorschau gezeigt wird – in Suche, Discover und sozialen Netzwerken. Das ist eine Frage der Darstellung, nicht der Position.

Muss ich alt an jedes Bild schreiben?

An jedes: ja. Aber nicht überall mit Inhalt. Dekorative Bilder bekommen alt="", inhaltstragende eine Beschreibung. Das Attribut ganz wegzulassen ist immer falsch.

Und wenn ich das Bild nur als Hintergrund brauche?

Dann ist ein CSS-Hintergrund genau richtig – dekorative Flächen gehören nicht ins HTML. Nur eben: Was Inhalt ist, gehört ins <img>.

Fazit

Bild-SEO besteht aus zwei Hälften, und die meisten Websites erledigen nur eine. Die erste Hälfte ist Verstehbarkeit: ein Bild im <img>, ein beschreibender Alt-Text, ein sprechender Dateiname, thematischer Kontext mit Bildunterschrift. Die zweite Hälfte ist Auslieferung: modernes Format, srcset mit ehrlichem sizes, feste Maße gegen Layout-Sprünge – und die eine Regel, an der die meisten scheitern: Das LCP-Bild bekommt fetchpriority="high" und niemals loading="lazy". Wer beide Hälften macht, gewinnt Sichtbarkeit, Ladezeit und Barrierefreiheit in einem Aufwasch.

Quellen

• Image SEO best practices (Google Search Central – unterstützte Formate, Dateinamen, Alt-Text, Vorschaubild-Auswahl, Discover-Anforderungen)
• Responsive images (MDN – srcset, sizes, <picture> mit den Rechenbeispielen)