Bilder-SEO und LCP-Optimierung 2026: Der komplette Leitfaden

Öffnen Sie die Browser-DevTools auf nahezu jeder Website und werfen Sie einen Blick auf den Netzwerk-Tab. Die größte einzelne Datei auf der Seite ist in neun von zehn Fällen ein Bild. Das Hero-Foto, ein Produktbild, eine eingebettete Illustration — diese Dateien sind in der Regel größer als HTML, CSS und JavaScript zusammen.

Damit sind Bilder der größte Hebel, den Sie überhaupt zur Verfügung haben. Sie wirken sich sowohl auf SEO (Alt-Text, Dateinamen, Bildersuchergebnisse, Schema) als auch auf Core Web Vitals (Largest Contentful Paint, Cumulative Layout Shift, Gesamtseitengewicht) aus. Dennoch gehören Bilder zu den am stärksten vernachlässigten Bereichen der technischen Optimierung. Designer laden hochaufgelöste PNGs aus Figma hoch, Entwickler binden sie ohne width- oder height-Attribute ein, und Redakteure fügen Dateinamen wie IMG_4738.jpg in das CMS ein.

Dieser Leitfaden vereint Bilder-SEO und Bildleistung zu einem praxistauglichen Arbeitsablauf. Am Ende wissen Sie genau, was Sie auf Ihrer Website in welcher Reihenfolge beheben sollten und wie Sie das Ergebnis überprüfen.

---

Warum Bilder der größte verborgene SEO- und Leistungshebel sind

Bilder berühren nahezu jede Kennzahl, die Google relevant findet:

• Alt-Text-Indexierung: Google liest Alt-Attribute, um zu verstehen, was auf der Seite zu sehen ist und was jedes Bild darstellt. Fehlende oder generische Alt-Texte bedeuten verlorene Ranking-Signale.
• Google Bilder: Ein überraschend großer Anteil organischen Traffics kommt nach wie vor über die Bildersuche. Beschreibende Dateinamen und Alt-Attribute sind die Eintrittskarte.
• LCP (Largest Contentful Paint): Auf den meisten Inhaltsseiten ist das Hero-Bild das LCP-Element. Ein langsames Hero bedeutet einen schlechten LCP-Wert, der sich unmittelbar auf das Ranking auswirkt.
• CLS (Cumulative Layout Shift): Bilder ohne explizite Maße verursachen beim Laden Layout-Sprünge, was den CLS verschlechtert und Nutzer frustriert.
• Gesamtseitengewicht: Unoptimierte Bilder blähen das Seitengewicht um Megabytes auf, was TTFB verlangsamt, mobile Datenkosten erhöht und die Erfahrung für alle ohne Glasfaser verschlechtert.

Beheben Sie die Bilder, und Sie beheben fünf Probleme auf einmal. Ignorieren Sie sie, und Ihre Audit-Berichte werden weiterhin dieselben orangen und roten Balken anzeigen, ganz gleich, was Sie anderswo tun.

---

Grundlagen des Bilder-SEO

Die Grundlagen des Bilder-SEO haben sich in einem Jahrzehnt nicht dramatisch verändert, doch die meisten Websites machen sie immer noch falsch. Hier kommt es auf folgende Punkte an.

Beschreibende Dateinamen

Dateinamen wie IMG_0042.jpg, DSC9382.png oder Bildschirmfoto 2026-05-23 um 14.32.png sagen Google nichts. Benennen Sie Ihre Dateien vor dem Hochladen um. Ein beschreibender Dateiname verwendet Bindestriche, Kleinbuchstaben und kurze relevante Schlüsselwörter:

• Schlecht: IMG_0042.jpg
• Besser: rote-laufschuhe-seitenansicht.jpg
• Am besten: rote-laufschuhe-seitenansicht-nike-air-zoom.jpg

Übertreiben Sie es nicht mit zwanzigwortigen, mit Schlüsselwörtern überfrachteten Namen. Streben Sie drei bis sieben beschreibende Wörter an.

Alt-Text, der zwei Zwecken dient

Alt-Text hat zwei Aufgaben: Er beschreibt das Bild für Nutzer mit Bildschirmlesegeräten und teilt Suchmaschinen mit, was das Bild darstellt. Guter Alt-Text erfüllt beide Aufgaben auf natürliche Weise.

Schreiben Sie Alt-Text so, als würden Sie das Bild jemandem am Telefon beschreiben — und behalten Sie dabei das Thema der Seite im Hinterkopf. Ist das Bild dekorativ — ein Trenner, ein Symbol neben einem Text, der bereits dasselbe beschreibt — verwenden Sie ein leeres Alt-Attribut (alt=""), nicht eine mit Schlüsselwörtern überladene Formulierung.

Der häufigste Alt-Text-Fehler besteht darin, ihn bei aussagekräftigen Bildern leer zu lassen. Der zweithäufigste besteht darin, ihn mit Schlüsselwörtern zu füllen. Beides signalisiert Suchmaschinen Nachlässigkeit, und beides versagt bei Bildschirmleser-Nutzern.

Bildunterschriften, Titel und umgebender Text

Google verwendet den Text rund um ein Bild als zusätzlichen Kontext. Ein Produktfoto in einem Absatz, der das Produkt beschreibt, wird weitaus besser verstanden als dasselbe Foto auf einer leeren Seite. Verwenden Sie Bildunterschriften dort, wo sie einen Mehrwert bieten. Vermeiden Sie das title-Attribut — es bringt wenig SEO-Nutzen und fügt am Desktop einen unhandlichen Tooltip hinzu.

Strukturierte Daten: ImageObject

Fügen Sie wichtigen Bildern — Ihrem Logo, primären Produktfotos, Rezeptbildern, Artikel-Hero-Aufnahmen — ImageObject-strukturierte Daten hinzu. Geben Sie mindestens contentUrl, license und creator an. Das erschließt reichhaltigere Bildersuchergebnisse und hilft KI-Systemen, Ihre Bilder korrekt zu verwenden.

---

Die LCP-Verbindung: Hero-Bild = LCP-Element

Largest Contentful Paint misst, wie schnell das größte sichtbare Element fertig geladen ist. Auf den allermeisten Inhaltsseiten ist dieses Element das Hero-Bild — das Foto oben in einem Artikel, das Produktbild auf einer PDP oder das Banner auf einer Landing Page.

Das bedeutet, dass Ihr Hero-Bild eine grundlegend andere Behandlung verdient als die übrigen Bilder der Seite.

Wie LCP berechnet wird

Der Browser misst die Zeit vom Navigationsstart bis zum vollständigen Rendern des größten sichtbaren Elements. Bei einem Bild bedeutet "gerendert", dass die Bytes heruntergeladen sind und das Bild gezeichnet wurde. Die Uhr läuft ab dem Moment, in dem die URL eingegeben wird.

Der Schwellenwert von Google für "gutes" LCP beträgt 2,5 Sekunden. Ein Hero-Bild von 800 KB, das nicht priorisiert ist, verfehlt diesen Wert auf Mittelklasse-Mobilgeräten im 4G-Netz regelmäßig.

Sonderbehandlung für das Hero

Drei moderne Techniken verändern die LCP-Leistung grundlegend:

fetchpriority="high"

Das Hinzufügen von fetchpriority="high" zum Hero-Bildelement weist den Browser an, es vor anderen Ressourcen herunterzuladen. Dieses eine Attribut kann den LCP-Wert in langsamen Netzen um 500-1500 ms verringern.

Preload-Hinweise

Wenn Ihr Hero aus einem srcset ausgewählt wird, kann der Browser den Download erst starten, nachdem das Layout berechnet wurde. Ein <link rel="preload" as="image" imagesrcset="..." imagesizes="..."> im Head löst dies, indem es den Browser anweist, sofort zu laden.

Eager Loading (NICHT Lazy)

Laden Sie das Hero-Bild niemals lazy. loading="lazy" bei einem Above-the-Fold-Bild ist eine der häufigsten Ursachen für schlechtes LCP. Eager Loading ist der Standard — stellen Sie sicher, dass kein globales Skript und keine CMS-Vorlage dies für Ihr Hero überschreibt.

---

Moderne Bildformate: AVIF, WebP, JPEG XL

Als JPEG ausgelieferte Fotos und als PNG ausgelieferte Grafiken lassen 30-70 % an Dateigröße liegen. Moderne Formate — AVIF, WebP und JPEG XL — erzeugen bei gleicher visueller Qualität dramatisch kleinere Dateien.

Format	Typische Ersparnis ggü. JPEG	Browser-Unterstützung (2026)	Am besten geeignet für
AVIF	50-70 %	Chrome, Edge, Firefox, Safari 16.4+	Fotos, Hero-Bilder, alles Große
WebP	25-35 %	Universell (98 %+)	Zuverlässiges Fallback vor AVIF
JPEG XL	40-60 %	Eingeschränkt (standardmäßig nur Safari)	Für die Produktion noch nicht praktikabel
JPEG	Basis	Universell	Letzte Rückfallebene für sehr alte Browser

Fallback-Strategie mit dem picture-Element

Die sauberste Auslieferungsstrategie nutzt <picture> mit mehreren Quellen. Der Browser wählt die erste Quelle, die er dekodieren kann:

<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" alt="..." width="1200" height="675">
</picture>

AVIF zuerst, WebP als Fallback, JPEG als letzte Notlösung. Jeder Besucher erhält das kleinste Format, das sein Browser unterstützt — ohne JavaScript und ohne Kompatibilitätsrisiko.

---

Responsive Bilder richtig umgesetzt

Ein 2400 Pixel breites Hero-Bild ist für einen 360-Pixel-Telefonbildschirm überdimensioniert. Responsive Bilder liefern jedem Gerät die passende Größe.

srcset und sizes

Das srcset-Attribut listet mehrere Auflösungen auf. Das sizes-Attribut teilt dem Browser mit, wie breit das Bild bei unterschiedlichen Breakpoints dargestellt wird, sodass er bereits vor dem Download die passende Auflösung wählen kann.

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="..."
  width="1600"
  height="900">

Warum die Standardlogik des Browsers ohne sizes scheitert

Ohne sizes-Attribut nimmt der Browser an, das Bild fülle den gesamten Viewport. Für ein Seitenleistenbild, das auf einem 1440-Pixel-Display tatsächlich nur 300 Pixel breit ist, kann der Browser die 1600-Pixel-Version herunterladen, obwohl die 400-Pixel-Version korrekt gewesen wäre. Das Ergebnis: verschwendete Bandbreite und langsameres LCP.

Geben Sie sizes immer an, wenn Sie srcset verwenden. Berechnen Sie die tatsächliche Anzeigebreite bei jedem Breakpoint und schreiben Sie sie als CSS-ähnliche Medienabfrageliste.

---

Lazy Loading: wann sinnvoll und wann NICHT

Natives Lazy Loading — loading="lazy" — verzögert das Laden eines Bildes, bis es sich in der Nähe des Viewports befindet. Das ist hervorragend für lange Seiten mit vielen Bildern unterhalb des Folds. Für das Hero ist es katastrophal.

Verwenden Sie Lazy Loading für

• Bilder, die mehr als einen Bildschirm unterhalb des Folds liegen
• Lange Artikel mit zahlreichen Illustrationen
• Produktraster jenseits des initial sichtbaren Bereichs
• Footer-Logos und dekorative Bilder am Seitenende

Niemals lazy laden

• Hero-Bilder und Banner oberhalb des Folds
• Das Logo im Header (es ist stets sichtbar)
• Das erste Produktbild auf einer PDP
• Jedes Bild, das das LCP-Element ist oder sein könnte

IntersectionObserver vs. nativ

Natives loading="lazy" wird überall unterstützt und sollte die Standardwahl sein. Greifen Sie nur auf einen JavaScript-basierten IntersectionObserver zurück, wenn Sie eine feingranulare Kontrolle über die Schwelle benötigen oder Animationen parallel zum Laden auslösen möchten.

---

CLS durch Bilder vermeiden

Cumulative Layout Shift misst unerwartete Layout-Sprünge. Bilder ohne explizite Maße sind die häufigste Ursache. Wenn ein Bild geladen wird, kennt der Browser plötzlich seine Größe und schiebt alles darunter nach unten — jeder Link, den der Nutzer gerade anklicken wollte, springt außer Reichweite.

Setzen Sie immer width und height

Jedes <img>-Element sollte width- und height-Attribute haben, die dem intrinsischen Seitenverhältnis der Datei entsprechen. Der Browser nutzt diese, um vor dem Download Platz zu reservieren.

Verwenden Sie CSS aspect-ratio

Für responsive Layouts, bei denen das Bild seinen Container ausfüllt, kombinieren Sie width- und height-Attribute mit aspect-ratio in CSS. Das Element reserviert proportional Platz, und das Bild füllt diesen aus, sobald es eintrifft.

Platzhalter geringer Qualität

Für eine noch flüssigere Erfahrung können Sie einen winzigen, verschwommenen Platzhalter (LQIP oder BlurHash) anzeigen, der durch das vollständige Bild ersetzt wird. Frameworks wie Next.js und Astro liefern dies standardmäßig mit.

---

CDNs und Bildoptimierungsdienste

Bilder für jede Seite manuell zu optimieren ist auf Dauer nicht tragbar. Ein moderner Stack delegiert dies an einen Dienst oder eine Build-Pipeline.

Bild-CDNs

• Cloudinary: Ausgereift, funktionsreich, im Maßstab teuer. Hervorragende Transformations-URLs.
• ImageKit: Geringere Kosten, ähnliche Funktionen, einfacheres Onboarding.
• Cloudflare Images: Pauschale Preisgestaltung, tiefe Integration mit dem Cloudflare-CDN, einfachere API.
• imgix: Lange etabliert, beliebt bei Medienseiten.

Build-Pipelines

Für statische Sites erzeugen Sie optimierte Bilder zur Build-Zeit mit sharp (Node) oder ImageMagick. Astro, Next.js und Nuxt bieten Bildkomponenten, die AVIF, WebP und responsive Varianten automatisch verarbeiten.

Wofür sollten Sie sich entscheiden?

Ist Ihre Bildbibliothek groß und wird häufig aktualisiert, verwenden Sie ein CDN. Haben Sie einen statischen Satz an Bildern und wünschen sich maximale Leistung ohne Kosten pro Anfrage, nutzen Sie eine Build-Pipeline. Viele Sites kombinieren beides — Build-Zeit für Hero- und Produktbilder, CDN für nutzergenerierte Inhalte.

---

Eine 10-Schritte-Checkliste für ein Bildaudit

1. Listen Sie jedes Bild auf Ihrer Startseite und den meistbesuchten Seiten auf.
2. Prüfen Sie die Dateinamen — benennen Sie alles um, was nach IMG_ oder Bildschirmfoto aussieht.
3. Auditieren Sie Alt-Texte — ergänzen Sie fehlende, vereinfachen Sie mit Schlüsselwörtern überladene.
4. Identifizieren Sie Ihr LCP-Element. Lassen Sie PageSpeed Insights laufen und prüfen Sie, ob es Ihr Hero-Bild ist.
5. Bestätigen Sie, dass das Hero fetchpriority="high" trägt und nicht lazy geladen wird.
6. Stellen Sie sicher, dass alle Bilder width- und height-Attribute besitzen.
7. Prüfen Sie die ausgelieferten Formate — liefern Sie AVIF/WebP an unterstützende Browser?
8. Untersuchen Sie die srcset- und sizes-Attribute. Wird die richtige Auflösung gewählt?
9. Testen Sie auf einem echten Mobilgerät im 4G-Netz, nicht nur auf Ihrem schnellen Desktop.
10. Fügen Sie ImageObject-strukturierte Daten für Ihre wichtigsten Bilder hinzu.

---

Was Sie zuerst beheben sollten

Wenn Sie diese Woche nur drei Dinge erledigen können, dann diese:

1. Beheben Sie das Hero. Fügen Sie fetchpriority="high" hinzu, entfernen Sie Lazy Loading und konvertieren Sie es zu AVIF mit WebP-Fallback. Diese eine Änderung verschiebt LCP häufig von schlecht auf gut.
2. Ergänzen Sie width und height bei jedem Bild. CLS sinkt häufig über Nacht auf nahezu null.
3. Auditieren Sie Alt-Texte auf Ihren zehn wichtigsten Seiten. Schreiben Sie für jedes aussagekräftige Bild einen beschreibenden, hilfreichen Alt-Text.

Alles Übrige — CDN-Migration, Build-Pipelines, JPEG-XL-Einführung — kann warten. Diese drei Maßnahmen liefern den Großteil des Nutzens.

Möchten Sie sehen, wie Ihre Bilder abschneiden? Führen Sie unter webseoauditor.com/try ein kostenloses Audit durch und erhalten Sie eine priorisierte Liste von Bildproblemen in SEO, Barrierefreiheit und Core Web Vitals — mit den konkreten Dateien und Seiten, die Aufmerksamkeit erfordern.