Open Graph

Was Open Graph 2026 wirklich ist

Ein Beitrag wird in LinkedIn geteilt, und statt des Aufmacherbilds erscheint das Footer-Logo in Briefmarkengröße. Das ist kein Rankingproblem, sondern ein Verteilungsproblem: Der Crawler der Plattform hat die HTML-Antwort gelesen, kein brauchbares Bild gefunden und sich selbst bedient. Open Graph ist die Gegenmaßnahme, ein kleiner Satz von Meta-Tags im Kopfbereich des Dokuments, mit dem eine Seite der Außenwelt mitteilt, als was sie dargestellt werden will: mit welchem Titel, welcher Beschreibung, welchem Bild, unter welcher Adresse und als welcher Objekttyp.

Das Open Graph Protocol stammt von Facebook und ist in seiner Spezifikation seit 2014 unverändert. Wer 2026 nach einer neuen Version oder neuen Properties sucht, sucht vergeblich. Bewegung gibt es ausschließlich bei den Plattformen, die das Protokoll interpretieren: beim Caching, bei den Bildzuschnitten, bei der Frage, welche Oberfläche welche Property überhaupt liest. Das ist eine gute Nachricht, denn es heißt, dass eine einmal saubere Implementierung jahrelang trägt und kein wiederkehrendes Wartungsthema ist.

Das folgende Video gibt einen kompakten Einstieg in die Rolle der og-Tags im Online-Marketing:

Für die Einordnung entscheidend: Open Graph ist kein Rankingfaktor. Google dokumentiert die von der Suche unterstützten Meta-Tags separat, og:title und og:description gehören nicht dazu. Eine dokumentierte Ausnahme gibt es, und sie ist wichtiger, als die meisten Teams denken: In der Discover-Dokumentation nennt Google og:image ausdrücklich als eine Möglichkeit, das große Vorschaubild einer Seite festzulegen. Wer auf Discover-Traffic spielt, hat in diesem einen Tag eine direkte Stellschraube in einer Google-Oberfläche, und Google hat vom 5. bis 27. Februar 2026 ein bestätigtes Discover-Update über 22 Tage ausgerollt (Google Search Status Dashboard), was die Aufmerksamkeit für diesen Kanal nicht kleiner gemacht hat.

Der zweite Grund, warum das Thema wieder auf Audit-Listen steht, ist die Zersplitterung der Distribution. Klicks entstehen längst nicht mehr nur in der klassischen Ergebnisliste. Eine Analyse von Seer Interactive vom September 2025 berichtete für Suchanfragen mit AI Overview einen Rückgang der organischen Klickrate von 1,76 auf 0,61 Prozent. Diese Zahl ist ein Studienergebnis und kein Erwartungswert für die eigene Domain, aber die Richtung ist eindeutig: Jeder Kanal, in dem ein Mensch noch selbst über einen Klick entscheidet, gewinnt an Gewicht. In Feeds und Messengern entscheidet darüber eine Karte, die aus drei Tags gebaut wird.

Die Tags, die wirklich zählen

Vier Properties tragen die gesamte Last. og:title ist der Titel der Vorschaukarte und hat mit dem Title-Tag nichts zu tun, auch wenn beide meist identisch befüllt werden. Sinnvoll ist das selten: Der Title-Tag arbeitet in einer Ergebnisliste, in der jemand aktiv gesucht hat, og:title arbeitet in einem Feed, in dem niemand gesucht hat. og:description ersetzt in der Vorschau die Meta-Description, die Facebook und LinkedIn ohne og-Angabe nur als Notlösung heranziehen. og:url legt die kanonische Adresse im sozialen Graphen fest und sorgt dafür, dass Shares verschiedener Parametervarianten auf einer Adresse zusammenlaufen. og:type entscheidet, welche weiteren Properties überhaupt gültig sind: article für redaktionelle Inhalte, website für alles Übrige, video und music für Medienobjekte.

og:image ist der Tag, der über Erfolg und Misserfolg entscheidet, und gleichzeitig der am häufigsten falsch gesetzte. Aktuelle Implementierungsleitfäden konvergieren auf 1200 × 630 Pixel, also ungefähr 1,91:1, als praktikablen plattformübergreifenden Standard für Facebook, LinkedIn, Slack, Discord, WhatsApp und X-kompatible Karten. Das ist keine Protokollvorgabe, sondern der kleinste gemeinsame Nenner der Zuschnitte. Für Google Discover kommt eine harte Untergrenze dazu: Die Dokumentation verlangt Bilder von mindestens 1200 Pixel Breite, damit die große Vorschau überhaupt ausgespielt wird. Ein 800 Pixel breites Bild ist damit nicht suboptimal, es ist disqualifiziert.

Ein minimaler, aber vollständiger Block sieht so aus:

<meta property="og:type" content="article" />
<meta property="og:title" content="Titel der Karte" />
<meta property="og:description" content="Zwei Zeilen, die zum Klick führen" />
<meta property="og:url" content="https://example.com/artikel/" />
<meta property="og:image" content="https://example.com/img/artikel.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Beschreibung des Motivs" />

Zwei Feinheiten aus der Praxis. Erstens erlaubt das Protokoll Arrays: Mehrere og:image-Angaben sind zulässig, die erste gilt als Standard, und strukturierte Unter-Properties wie og:image:width oder og:image:alt gehören unmittelbar hinter das Bild, auf das sie sich beziehen. Wer sie an das Ende des Kopfbereichs schiebt, bekommt bei mehreren Bildern eine Zuordnung, die niemand vorhersagen kann. Zweitens verwechseln viele Teams Open Graph mit Auszeichnungssprache für Maschinen. Das eine beschreibt die Darstellung eines Links außerhalb der eigenen Seite, das andere beschreibt die Semantik des Inhalts für Suchmaschinen. Wer einen Artikel korrekt auszeichnen will, braucht beides: den og-Block für die Karte und ein JSON-LD-Objekt, wie wir es im Eintrag zu strukturierten Daten und ihrer Rolle im technischen SEO beschreiben. Die beiden Ebenen konkurrieren nicht, sie adressieren verschiedene Leser.

Plattformen, Caching und die Cache-Falle

Jede Plattform hat ihren eigenen Crawler, ihren eigenen Cache und ihre eigene Toleranz gegenüber fehlenden Angaben. Facebook liest die og-Tags direkt und stellt mit dem Sharing Debugger ein Werkzeug bereit, das eine Seite erneut einliest. LinkedIn arbeitet mit dem Post Inspector: Wird eine URL unter linkedin.com/post-inspector eingereicht, liest LinkedIn die Seite neu und aktualisiert die zwischengespeicherte Vorschau für künftige Shares. Der entscheidende Satz, den Praxisberichte aus 2026 immer wieder bestätigen: Bereits veröffentlichte Beiträge behalten ihre alte Vorschau. Ein Korrekturlauf rettet den nächsten Post, nie den, der gerade läuft. Wer eine Kampagne plant, prüft die Karte deshalb vor dem ersten Share, nicht danach.

Das folgende deutschsprachige Tutorial zeigt die Umsetzung auf Facebook-Seite:

Bei X ist die Lage unbefriedigend. Der frühere Card Validator wurde eingestellt, einen verlässlichen offiziellen Weg zum Debuggen öffentlicher Karten gibt es nicht mehr, in der Praxis testet man über einen Entwurf oder über Drittvalidatoren. Für Teams, die Distribution planen, ist das eine echte Werkzeuglücke, und sie wird gern verschwiegen. Twitter Cards sind dabei kein Konkurrenzprotokoll, sondern eine Ergänzung: Fehlt twitter:card, greift die Plattform in der Regel auf die og-Angaben zurück. Man braucht also nicht zwei vollständige Sätze von Tags, sondern Open Graph als Basis und twitter:card nur dort, wo ein abweichendes Format gewollt ist, etwa summary_large_image. Eine Branchen-Statistiksammlung aus 2026 beziffert die Verbreitung unter Seiten mit strukturierter Auszeichnung auf 67,7 Prozent für Open Graph, 52,4 Prozent für Twitter Cards und 49,7 Prozent für JSON-LD. Die Quelle ist eine Zusammenstellung, kein primärer Crawl, entsprechend vorsichtig ist mit der Zahl umzugehen, aber die Rangfolge deckt sich mit dem, was wir in Audits sehen.

Der wichtigste technische Punkt betrifft das Rendering. Social Crawler holen sich das initiale HTML und führen kein clientseitiges JavaScript aus. Meta-Tags, die erst nach der Hydration in den Kopfbereich geschrieben werden, existieren für diese Crawler schlicht nicht, und der Betreiber sieht im Browser trotzdem eine korrekte Seite. Bei Single-Page-Anwendungen ist das der Standardfehler. Die Lösung heißt serverseitiges Rendern der Kopfdaten oder statisches Vorrendern, nicht ein weiteres Plugin.

Wo Open Graph in einer Netlinking-Operation zählt

Ehrlich bleiben: Open Graph transportiert keine Linkkraft. Eine Vorschaukarte verändert weder PageRank noch Ankertextverteilung, und wer og-Tags als Linkbuilding-Maßnahme verkauft, verkauft Floskeln. Der Hebel liegt woanders, und er ist trotzdem real.

Er liegt zuerst bei Digital PR und Linkbait. Ein Inhalt, der geteilt werden soll, um Erwähnungen und Verlinkungen einzusammeln, konkurriert im Feed mit Bewegtbild. Eine leere oder schiefe Karte kostet genau in dem Moment Reichweite, in dem der Inhalt seine Verteilung selbst erzeugen muss. Er liegt zweitens beim Einkauf redaktioneller Platzierungen: Erscheint ein bezahlter Beitrag auf einem fremden Medium, bestimmt dessen Template, wie der Beitrag außerhalb der Website aussieht. Ein Host, der jedem Artikel dasselbe generische Standardbild mitgibt, liefert eine Platzierung zweiter Wahl, sobald jemand sie teilen will. Diese Prüfung dauert dreißig Sekunden und wird fast nie gemacht. In unserem eigenen Verbund französischer Redaktionsmedien sitzt der og-Block im gemeinsamen Template, mit einem seitenindividuellen Bild pro Artikel. Wer sich ansehen will, wie die Hosts technisch aufgestellt sind, findet das offen einsehbare Medienverzeichnis mit den Kennzahlen jeder Domain, und die Konditionen pro Beitrag stehen ohne Anmeldung in der öffentlichen Preisübersicht.

Bleibt die Frage, was das messbar bringt. Kursierende Zahlen wie eine 2,3-fache Klickrate für optimierte Vorschaubilder, die einer HubSpot-Auswertung von 2025 zugeschrieben wird, halten einer Prüfung nicht stand: Zu Stichprobe, Plattformmix und Kontrollgruppe ist nichts auffindbar, und eine Zahl ohne Methodik ist ein Verkaufsargument, kein Befund. Aussagekräftiger ist die eigene Messung. Vergleichen Sie die Klickrate geteilter Links vor und nach der Einführung seitenindividueller Bilder, im selben Kanal, über gleich lange Zeiträume, mit derselben Beitragsfrequenz. Für Discover nutzen Sie die Leistungsdaten in der Search Console, wo Google seit Juni 2026 auch generative Oberflächen eigenständiger ausweist. Alles andere ist Bauchgefühl mit Nachkommastellen.

Häufige Fehler aus der Audit-Praxis

Der häufigste Fehler ist der relative Bildpfad. og:image verlangt eine absolute URL samt Protokoll und Host. Ein Pfad wie /img/artikel.jpg wird im Browser korrekt aufgelöst und von den meisten Plattform-Crawlern ignoriert, das Ergebnis ist eine Karte ohne Bild. Direkt dahinter kommt das eine Standardbild für alle Seiten: Das Logo auf jeder Karte macht jeden Artikel im Feed austauschbar. Der aktuelle Produktionsstandard ist die dynamische Erzeugung eines seitenspezifischen Bildes zur Build- oder Renderzeit, mit Titel und Rubrik im Bild angelegt, nicht als Textoverlay der Plattform.

Das folgende Video zeigt an Beispielen, wie man falsche og-Tags erkennt und korrigiert:

Der dritte Klassiker ist ein og:url, das auf eine andere Adresse zeigt als das Canonical, meist nach einer Domainmigration oder einer Umstellung von www auf die nackte Domain. Die Folge ist ein gespaltener sozialer Graph: Shares und Reaktionen verteilen sich auf zwei Adressen, und die Vorschau springt je nach Quelle. Ähnlich unauffällig ist der vierte Fehler, das blockierte Bild. Hotlink-Schutz, eine restriktive Regel am CDN oder eine 403-Antwort für unbekannte User-Agents genügen, damit die Plattform ein Bild anfordert, keines bekommt und die Karte ohne Motiv rendert. Die Seite selbst sieht dabei tadellos aus, weshalb der Fehler monatelang überlebt.

Der fünfte betrifft den Cache nach einem Relaunch. Neue Bild-URLs, alter Cache bei Facebook und LinkedIn, und die geteilten Karten zeigen wochenlang das alte Design. Ein Durchlauf durch die Debugger für die zwanzig wichtigsten Einstiegsseiten gehört nach jedem Relaunch in die Abnahmeliste, gleich neben die Prüfung der Weiterleitungen.

Zum Datenschutz, weil die Frage im deutschsprachigen Raum regelmäßig kommt und meistens falsch beantwortet wird: og-Tags sind statisches Markup im ausgelieferten HTML, sie übertragen von sich aus nichts an Dritte und sind damit unkritisch. Datenschutzrelevant wird es eine Ebene höher, bei eingebetteten Share-Buttons und Zählpixeln, die beim Seitenaufruf Verbindungen zu Plattformen aufbauen. Wer sauber arbeiten will, trennt beides: Die Meta-Angaben bleiben vollständig, die Widgets von Drittanbietern werden durch eigene Links auf die jeweilige Share-Adresse ersetzt. Das kostet eine Stunde Arbeit und nimmt der Diskussion die Grundlage.