Open-Graph-Bilder: Größen, Formate und warum dein Bild nicht angezeigt wird

Der 1200×630-Standard und warum

Der De-facto-Standard og:image Größe ist 1200×630 Pixel, einem Seitenverhältnis von ungefähr 1.91:1. Diese Zahl ist keine willkürliche Tradition: Sie liegt nahe am breitesten Seitenverhältnis, in dem die meisten Link-Vorschaukarten auf Facebook, LinkedIn, Slack und Discord angezeigt werden. Ein Bild mit 1200×630 Pixeln füllt die Karte deshalb aus, ohne dass die Plattform Balken hinzufügen oder es wesentlich beschneiden muss.

Kleinere Bilder funktionieren technisch, werden von der Plattform aber vergrößert, um die Karte zu füllen. Das macht Details weicher und kann deutlich schlechter aussehen als ein gezielt vorbereitetes Bild. Die meisten Plattformen nennen etwa 200×200 als Mindestgröße, damit ein Bild überhaupt als Vorschau akzeptiert wird. Betrachte das als Untergrenze, nicht als Ziel: Mit deutlich weniger als 1200×630 verschenkst du Qualität ohne Nutzen.

Von Twitter/X: summary_large_image Karte verwendet dasselbe 1200×630-Bild und dasselbe Seitenverhältnis, sodass ein Bild im Allgemeinen beide abdeckt: og:image und twitter:image ohne einen separaten Export zu benötigen.

Sicherer Bereich: was den Zuschnitt tatsächlich übersteht

Auch bei richtigem Seitenverhältnis schneiden verschiedene Plattformen die Karte je nach Anzeigestelle etwas anders zu. Ein Feed-Beitrag, eine Link-Vorschau in einer Direktnachricht und ein Seitenleistenmodul für „geteilte Links“ zeigen nicht immer denselben Ausschnitt desselben Bildes. Text oder ein Logo direkt am Rand kann an einer Stelle abgeschnitten werden, obwohl es in deiner eigenen Browser-Tab-Vorschau richtig aussah.

Die sichere Vorgehensweise ist, wichtige Inhalte – eine Überschrift, ein Logo oder ein Gesicht – innerhalb der ungefähr inneren 90% des Rahmens zu halten und an jeder Kante etwa 5–10% Rand zu lassen. Hintergrundbilder, Verläufe und dekorative Elemente können problemlos bis zum äußeren Rand reichen. Nur Inhalte, die jeder Betrachter sehen muss, sollten nach innen versetzt bleiben. Wenn dein Designwerkzeug es unterstützt, zeichne auf einer 1200×630-Arbeitsfläche ein Hilfsrechteck mit etwa 60px Abstand zu jeder Seite. Das ergibt einen vernünftigen sicheren Arbeitsbereich.

Format: JPG oder PNG und warum nicht WebP

Für die eigentliche Bilddatei sind JPG und PNG die sicheren Optionen. Die WebP-Unterstützung für og:image wird insbesondere von Crawlern und Bots für Link-Vorschauen uneinheitlich unterstützt. Manche unterstützen es, andere erzeugen bei einem WebP ohne Fehlermeldung gar keine Vorschau. Weil der Fehler unbemerkt bleibt, kann eine defekte Vorschau leicht veröffentlicht werden und erst auffallen, wenn jemand darauf hinweist.

Das ist eine strengere Kompatibilitätsanforderung als die Auslieferung von WebP an einen Browser, was fast jeder aktuelle Browser problemlos verarbeitet. Siehe unseren Vergleich von WebP, PNG und JPG für den allgemeinen Fall. Crawler für Link-Vorschauen sind andere, konservativere Clients als Nutzerbrowser, und ihre WebP-Unterstützung hinkt hinterher. Nutze JPG für fotografische Vorschaubilder, da es bei gleicher sichtbarer Qualität kleinere Dateien ergibt. Nutze PNG bei einfarbigen Flächen, Text oder wenn Transparenz in bestimmten Kontexten erhalten bleiben muss. Transparenz selbst ist bei einem OG-Bild allerdings unerheblich, weil es immer vor dem jeweiligen Hintergrund der Plattformkarte angezeigt wird.

Die meisten Plattformen akzeptieren GIF technisch als statisches Bild, aber für fotografische oder aufwendig gestaltete Vorschaubilder ist es keine sinnvolle Wahl. Es gibt hier keinen praktischen Grund, es JPG oder PNG vorzuziehen.

Die URL muss absolut sein

<meta property="og:image" content="/og-image.jpg" /> sieht plausibel aus und funktioniert beim direkten Seitenaufruf im Browser, weil dieser den relativen Pfad anhand der aktuellen Seiten-URL auflöst. Crawler für Link-Vorschauen führen diese Auflösung oft nicht zuverlässig aus oder verwenden eine falsche Basis. Praktisch ergibt das auf manchen Plattformen ein defektes oder ganz fehlendes Bild, während es auf anderen funktioniert. Dadurch ist der Fehler allein anhand von Nutzerberichten schwer zu diagnostizieren.

Gib immer die vollständige absolute URL einschließlich Schema und Domain an:

<meta property="og:image" content="https://example.com/og-image.jpg" />

In der Metadata API von Next.js bedeutet das, Folgendes festzulegen: metadataBase im Root-Layout, damit relative Bildpfade aus den Seitenmetadaten beim Build automatisch in absolute URLs aufgelöst werden, oder indem du die vollständige URL direkt auf jeder Seite einträgst in openGraph.images Eintrag, wie diese Website es tut.

Cache: Warum ein korrigiertes Bild noch die alte Vorschau zeigt

Das ist die häufigste Ursache für „Ich habe es korrigiert, aber es wird immer noch falsch angezeigt“. Plattformen speichern die abgerufenen Open-Graph-Daten einschließlich des Bildes pro URL im Cache. Dieser Cache wird nicht ungültig, nur weil du eine neue Datei bereitgestellt hast. Die Seite selbst neu zu laden, auch in einem privaten Fenster, sagt nichts darüber aus, was der Plattform-Cache noch enthält.

Jede große Plattform hat ein eigenes Werkzeug, um ein erneutes Auslesen zu erzwingen:

• Facebook / Meta: der Sharing Debugger (developers.facebook.com/tools/debug/) – füge die URL ein und klicke auf „Scrape Again“. Das erneuert auch den Cache für Link-Vorschauen in Instagram und WhatsApp, die Metas Crawler gemeinsam nutzen.
• X/Twitter: der Card Validator diente früher diesem Zweck. Seine Verfügbarkeit hat sich über die Zeit geändert. Ist er nicht erreichbar, ist eine harmlose Versionsabfrage an der URL, siehe unten, die verlässlichere Ersatzlösung.
• LinkedIn: der Post Inspector (linkedin.com/post-inspector/) – füge die URL ein, um einen erneuten Abruf zu erzwingen.
• Slack, Discord, iMessage: kein öffentlicher Debugger. Diese Dienste lassen ihren Cache meist nach eigenem Zeitplan irgendwann ablaufen oder aktualisieren ihn, sobald sich die URL auch nur leicht ändert.

Ist ein plattformspezifischer Debugger nicht verfügbar oder selbst störrisch, besteht die universelle Behelfslösung darin, die von der Plattform gesehene URL zu ändern. Hänge etwa eine Versionsabfrage an wie ?v=2 an den geteilten Link oder die Bild-URL selbst zwingt jede Plattform, sie als unbekannte Ressource zu behandeln und neu abzurufen, statt einen veralteten Cache-Eintrag auszuliefern.

Dateigröße und weitere Grenzen

Die meisten Plattformen dokumentieren eine Bildgrößenobergrenze im niedrigen einstelligen Megabytebereich. Facebooks dokumentierte Grenze lag historisch bei ungefähr 8MB. Auch Plattformen ohne ausdrücklich veröffentlichte Zahl brechen bei ungewöhnlich großen Dateien häufig wegen Zeitüberschreitung ab oder zeigen keine Vorschau. Da ein gut komprimiertes JPG oder PNG mit 1200×630 Pixeln für solche Inhalte meist deutlich unter 500KB liegt, bedeutet das Erreichen einer Grenze praktisch fast immer einen unoptimierten Export: ein riesiges Ausgangsfoto, das nur im Markup kleiner dargestellt, aber nicht in kleineren Abmessungen neu kodiert wurde, oder fotografischer Inhalt als PNG statt JPG. Siehe unseren Leitfaden zum Reduzieren der Bilddateigröße für die allgemeine Vorgehensweise zum Verkleinern eines Exports ohne sichtbaren Qualitätsverlust.

Lesbarkeit von Text in Vorschaubildgröße

Ein OG-Bild wird meist deutlich kleiner als seine ursprünglichen 1200×630 Pixel angezeigt. Eine Slack-Link-Vorschau oder eine Karte im mobilen Feed kann nur wenige hundert Pixel breit sein. Jeder im Bild enthaltene Text muss nach dieser Verkleinerung lesbar bleiben. Als Richtwert gilt: Fließtext unter ungefähr 40px bei der ursprünglichen Bildbreite von 1200px wird bei üblichen Feed-Darstellungen oft unscharf und unleserlich. Überschriften, die in Vorschaugröße lesbar sein sollen, müssen in der Regel deutlich größer sein – eher 60–80px oder mehr, fett und mit starkem Kontrast zum Hintergrund.

Auch deshalb solltest du das Bild selbst einfach halten. Eine überladene Komposition mit mehreren konkurrierenden Textelementen kann in voller Größe gut lesbar sein, wird in Kartengröße aber zu visuellem Rauschen. Eine einzelne klare Überschrift auf einem kontrastreichen Hintergrund bleibt auf allen Flächen zuverlässig lesbar, auf denen das Bild erscheint.

twitter:card braucht eine eigene Deklaration

Einstellung og:image reicht nicht automatisch für eine große Bildvorschau auf X/Twitter. Twitters Kartensystem liest sein eigenes twitter:card Meta-Tag zur Auswahl des Kartenstils. Ohne dieses verwenden manche Twitter-Clients ersatzweise eine kleinere Vorschaubildkarte, obwohl ein einwandfreies og:image vorhanden ist.

Deklariere es ausdrücklich:

<meta name="twitter:card" content="summary_large_image" />

Twitter greift ersatzweise zurück auf og:image für das tatsächliche Bild, wenn twitter:image nicht separat festgelegt ist. Du musst die Bild-URL daher meist nicht doppelt angeben. Die Angabe des Kartentyps selbst ist aber nicht optional, wenn du das Layout mit großem Bild möchtest.

Eine schnelle Reihenfolge zur Fehlersuche

1. Prüfe, ob die Bild-URL absolut statt relativ ist und sich direkt in einem Browser laden lässt.
2. Prüfe, ob das Format JPG oder PNG ist, nicht WebP.
3. Prüfe, ob die Abmessungen 1200×630 entsprechen oder nahe daran liegen.
4. Bestätigen twitter:card festgelegt ist, wenn speziell die Twitter-/X-Vorschau falsch ist.
5. Nutze das Debugger-Werkzeug der Plattform, um ein erneutes Abrufen zu erzwingen, bevor du annimmst, dass die Korrektur nicht funktioniert hat.
6. Wenn kein Debugger verfügbar ist, erhöhe eine Versionsangabe im Query-String der URL, um den Cache zu umgehen.

Häufig gestellte Fragen