Sprachen

Open-Graph-Tags: Kein Rankingfaktor, aber dennoch ein SEO-Pflichtprogramm

Was Open-Graph-Tags sind, warum sie kein Google-Rankingfaktor sind, was Google tatsächlich mit og:title/og:image/og:site_name macht, dokumentierte plattformspezifische og:image-Größen, plattformspezifisches Fallback- und Caching-Verhalten sowie wie Sie ein erneutes Scraping erzwingen.

Erstveröffentlicht: 2. Juli 2026 · Zuletzt aktualisiert: 3. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

Open-Graph-Tags (OG-Tags) sind <meta>-Elemente im head Ihrer Seite, die aus dem Open-Graph-Protokoll (ogp.me, von Facebook entwickelt) stammen und Ihre Seite als teilbares Objekt beschreiben. Die vier erforderlichen Eigenschaften sind og:title, og:type, og:image und og:url; ergänzen Sie og:description, og:site_name, og:locale und og:image:alt. Ihre Hauptaufgabe ist die Linkvorschau-Karte, die Personen sehen, wenn Ihre URL auf Facebook, LinkedIn, Slack, Discord, WhatsApp und iMessage geteilt wird – sie sind also ein CTR-Hebel, kein Rankingfaktor. Aber Google liest sie: og:title ist unter den Quellen aufgeführt, die für den SERP-Titellink verwendet werden können (ergänzt im August 2024), og:image ist ein dokumentierter Input für die automatische Auswahl von Bild-Thumbnails in der Suche und in Discover, und og:site_name ist ein Input mit niedrigerer Priorität für den in den Ergebnissen angezeigten Seitennamen – nichts davon garantiert, dass Ihr Wert unverändert verwendet wird. Praktischer Kern: og:image benötigt eine absolute URL und eine dokumentierte Alt-Beschreibung; jede Plattform veröffentlicht ihre eigenen Größenempfehlungen (LinkedIn: mindestens 1200×627, 1,91:1; Google Discover: mindestens 1200px breit, 16:9) statt einer universellen Zahl, obwohl 1200×630 (1,91:1) die langjährige plattformübergreifende Konvention ist; fehlende Tags führen zu einer unkontrollierten (nicht leeren) Vorschau; jede Plattform cached das Scraping, daher behebt das Bearbeiten der Tags nicht bereits geteilte Links – erzwingen Sie ein erneutes Scraping mit dem Facebook Sharing Debugger oder dem LinkedIn Post Inspector. Die meisten Social-Crawler führen kein JavaScript aus, daher müssen die Tags im serverseitig gerenderten HTML vorhanden sein.

TL;DR — Open-Graph-Tags sind <head>-<meta>-Elemente aus dem Open-Graph- Protokoll (ogp.me, von Facebook entwickelt), die Ihre Seite als teilbares Objekt beschreiben. Erforderlich: og:title, og:type, og:image, og:url; üblich optional: og:description, og:site_name, og:locale und og:image:alt. Wiederholte Eigenschaften bilden Arrays, wobei bei Konflikten das erste Tag bevorzugt wird. Sie sind kein Ranking-Faktor – sie sind die Darstellungsebene für Linkvorschauen in sozialen Netzwerken/Chat-Apps (Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage). Die Verarbeitung durch Suchmaschinen ist getrennt und sollte nicht aus der Open-Graph-Gültigkeit abgeleitet werden. Das Protokoll selbst legt keine Pixelmaße für og:image fest – jeder Konsument veröffentlicht seine eigene Größenangabe (LinkedIn, Google Discover) – liefern Sie also ein og:image mit absoluter URL, das für die von Ihnen unterstützten Plattformen dimensioniert ist; wissen Sie, dass fehlende Tags eine unkontrollierte, nicht leere Vorschau erzeugen; und denken Sie daran, dass jede Plattform das Scraping zwischenspeichert – das Bearbeiten von Tags behebt keine bereits geteilten Links, erzwingen Sie also ein erneutes Scraping. Die meisten Social-Crawler führen kein JavaScript aus, daher müssen die Tags im serverseitig gerenderten HTML vorhanden sein.

Evidence for this claim The Open Graph protocol defines og:title, og:type, og:image, and og:url as basic metadata for representing a page as a graph object. Scope: Open Graph protocol vocabulary; platform rendering can vary. Confidence: high · Verified: Open Graph protocol Evidence for this claim Meta's sharing crawler uses server-rendered Open Graph metadata and provides Sharing Debugger tools to inspect and refresh scraped information. Scope: Meta/Facebook sharing behavior, distinct from search ranking. Confidence: high · Verified: Meta for Developers: Webmasters sharing guide

Was Open-Graph-Tags tatsächlich sind

Open-Graph-Tags sind <meta>-Elemente im <head> Ihrer Seite, definiert durch das Open-Graph-Protokoll – eine Spezifikation, die Facebook erstellt und unter ogp.me veröffentlicht hat. Die Prämisse des Protokolls ist, dass eine Webseite mit einem kleinen, konsistenten Vokabular von Eigenschaften in ein reichhaltiges “Objekt” verwandelt werden kann, sodass jede Plattform dieselbe Vorschau aus denselben Tags erstellen kann. Googles eigener Entwickler-Erklärer formuliert den Ursprung klar: Das Open-Graph-Protokoll “provides Facebook with the metadata necessary to allow web pages to have the same functionality as other Facebook objects,” laut web.devs Artikel zur Social Discovery.

Die Spezifikation markiert vier Eigenschaften als erforderlich – og:title, og:type, og:image, und og:url – und diejenigen, die Sie fast immer zusätzlich hinzufügen, sind og:description, og:site_name und og:locale, plus strukturierte Untereigenschaften wie og:image:width, og:image:height und og:image:alt (die eigene Anleitung der Spezifikation: eine Seite, die og:image angibt, sollte auch og:image:alt angeben).

Wiederholte Tags und strukturierte Eigenschaften folgen bestimmten Regeln. Das Protokoll erlaubt es Ihnen, eine Stammeigenschaft zu wiederholen, um mehrere Objekte zu beschreiben (z. B. mehrere Kandidatenbilder) – wenn Konsumenten widersprüchliche Werte für dieselbe Eigenschaft sehen, gewinnt das erste Tag in der Dokumentreihenfolge. Eine strukturierte Untereigenschaft wie og:image:width gilt für das og:image-Tag unmittelbar davor, nicht für jedes Bild auf der Seite. Halten Sie also das og:image jedes Bildes und seine strukturierten Untereigenschaften in der Quellreihenfolge gruppiert. Dies ist verhaltensbezogenes Verhalten auf Protokollebene von ogp.me selbst, keine plattformspezifische Eigenheit.

Der Rahmen, den ich Ihnen ans Herz legen möchte: Dies ist die Darstellungsebene für soziale Netzwerke/Chats, das Gegenstück zur SERP-Darstellungsebene, die Sie bereits mit dem Titel-Tag und der Meta-Description verwalten. Gleiche Idee – kontrollieren Sie, wie sich Ihre Seite präsentiert – nur auf einer anderen Oberfläche.

Die wichtigsten Open-Graph-Tags einzeln

Der web.dev-Erklärer von Google gibt den Zweck jedes Tags in einer Zeile an: og:title ist “the title of the web page,” og:description ist “the description of the web page,” og:image ist die “URL to an image attached to the shared post,” og:url ist “the canonical url of the web page,” und og:type ist “a string that indicates the type of the web page” (web.dev). Praktisch:

  • og:title — die Kartenüberschrift. Halten Sie sie ungefähr so lang wie das, was auf Mobil-/Desktop-Karten angezeigt wird; verwenden Sie den rohen Titel ohne angehängtes Site-Name-Branding. Dies ist getrennt von Ihrem HTML-<title>-Element, obwohl Google für den Titel-Link auf beide zurückgreifen kann (siehe unten).
  • og:description — der Karten-Kurzbeschreibungstext. Ein oder zwei Sätze; längerer Text wird auf den meisten Plattformen abgeschnitten.
  • og:image — das Vorschaubild und die Eigenschaft, die die Karte macht oder bricht. Es muss eine absolute URL sein (https://…) — ein relativer Pfad wird von Crawlern stillschweigend ignoriert. Fügen Sie og:image:width/og:image:height hinzu, damit Plattformen die Karte layouten können, bevor das Bild fertig geladen ist, und og:image:alt mit einer echten Beschreibung — das Protokoll selbst empfiehlt dies, wann immer Sie og:image angeben.
  • og:url — die kanonische URL für die Seite (richten Sie sie an Ihrem rel=canonical aus, damit Shares auf einer Adresse konsolidiert werden).
  • og:type — deklariert den Objekttyp. website ist der Standard (und das, als was jede nicht markierte Seite behandelt wird); article schaltet zusätzliche Eigenschaften wie article:author, article:published_time und article:section frei; es gibt auch profile, book, video.* und music.*-Typen. Dies ist für Plattformfunktionen relevant, nicht direkt für SEO.
  • og:site_name und og:locale — das optionale, aber nützliche Paar. og:site_name benennt die Marke hinter der Seite; og:locale (Standard en_US) wird nur benötigt, wenn der Inhalt nicht in amerikanischem Englisch ist.

Sind Open-Graph-Tags ein Ranking-Faktor? Nein — aber hier ist, was Google damit macht

Es gibt keine offizielle Google-Quelle, die besagt, dass OG-Tags das Ranking beeinflussen. Sie steuern Erscheinungsbild, nicht Position — genau derselbe Bereich, in den John Mueller die Meta-Beschreibung einordnete: Sie wird “primarily used as a snippet in the search results page. And that’s not something that we would use for ranking” (via Search Engine Journal’s write-up). Kein namentlich genannter Google-Vertreter hat ein gleichwertiges, aufzeichnungsfähiges Zitat speziell zu Open Graph und Ranking abgegeben, daher werde ich keins erfinden — die Beweise sind der dokumentierte Mechanismus, und der Mechanismus ist ausschließlich Erscheinungsbild. Es gibt drei bestätigte Stellen, an denen Googles eigene Dokumentation sagt, dass es Ihre OG-Tags liest — und in jedem Fall ist gültiges Markup eine Eingabe, auf die Google zurückgreifen kann, keine Garantie für eine bestimmte Anzeige, einen bestimmten Ausschnitt oder ein bestimmtes Ranking- oder Traffic-Ergebnis. Das Fehlen in einem dieser Dokumente ist auch kein Beweis dafür, dass Google das Tag anderswo ignoriert — behandeln Sie dies als “was dokumentiert ist”, nicht als erschöpfende Liste aller Dinge, die Googles Systeme berühren könnten.

Seit 26. August 2024 listet Googles Dokumentation “Content in og:title meta tags” unter den Quellen, die es zur automatischen Generierung des Titel-Links — der klickbaren Überschrift in den Ergebnissen — verwenden kann. Die Änderungsprotokollzeile ist direkt: “Google Search can use content within og:title meta tags to automatically generate title links” (Search Central changelog). Es ist eine von etwa neun Quellen, aus denen Google schöpft (title-link docs) — keine Garantie, dass Ihr og:title wörtlich verwendet wird.

og:image als Quelle für Bild-Thumbnails

Der Abschnitt Image SEO best practices von Google enthält einen Abschnitt mit dem Titel „Specify a preferred image with metadata“, in dem zwei Metadatenquellen genannt werden, mit denen Sie beeinflussen können, welches Bild für die Suche ausgewählt wird: schema.orgs primaryImageOfPage (oder ein Bild auf der Hauptentität) oder „das og:image meta-Tag.“ Google stellt klar, dass „die Auswahl einer Bildvorschau durch Google vollständig automatisiert ist“ und warnt davor, „ein generisches Bild (z. B. Ihr Site-Logo) oder ein Bild mit Text im schema.org-Markup oder im og:image meta-Tag zu verwenden.“ In der Discover-Dokumentation werden für Discover-Bilder dieselben zwei Optionen genannt, mit zusätzlichen konkreten Vorgaben: mindestens 1200 Pixel breit, mehr als 300 000 Gesamtpixel und ein Seitenverhältnis von 16:9 (das eigene Beispiel ist 1280×720) – beachten Sie, dass dies ein anderes Verhältnis ist als die 1,91:1-Konvention für Social-Card-Bilder weiter unten, sodass ein einzelnes, für Social Sharing dimensioniertes Bild nicht automatisch der bevorzugte Discover-Bildausschnitt ist.

Die Fachpresse (Search Engine Land, Search Engine Journal, Search Engine Roundtable) berichtete Anfang März 2026 über diese Images/Discover-Dokumentation als neu und meldete, dass die Rolle von og:image nun auch AI Overviews umfasst. Ich konnte auf den eigenen Images- oder Discover-Seiten von Google keine Erwähnung von AI Overviews direkt bestätigen – keine der beiden Seiten nennt derzeit AI Overviews oder „AI surfaces“ – behandeln Sie die Search/Discover-Rolle also als dokumentierte Tatsache und die AI-Overviews-Erweiterung als von Dritten berichtet, nicht als etwas, das Googles eigene Dokumentation ausdrücklich feststellt. In jedem Fall handelt es sich hier um Auswahl, nicht um Ranking: og:image ist einer von mehreren Inputs, ohne Garantie für die genaue Anzeige.

og:site_name als Quelle für den Site-Namen

Für den neben Ihren Ergebnissen angezeigten Site-Namen sagt Google, dass sein System „auch Inhalte in og:site_name, <title>, Überschriftenelementen und anderen Texten auf einer Startseite berücksichtigt. Allerdings ist WebSite-strukturierte Daten am wichtigsten“ (Site Names-Dokumentation). og:site_name ist also ein Hebel, der in der Priorität unter WebSite-Schema-Markup liegt. (Für Videoseiten gibt es einen vierten Berührungspunkt: Google unterstützt OGP und liest og:video:image für Video-Thumbnails, laut der Video-SEO-Dokumentation.)

Wenn man alles zusammenfügt, lautet die ehrliche Schlagzeile: Google liest Ihre OG-Tags, aber nur, um zu entscheiden, wie Ihr Ergebnis aussieht – niemals, wo es rankt.

Wie soziale Plattformen und Chat-Apps OG-Tags verwenden

Die primäre, alltägliche Aufgabe von OG-Tags ist die Link-Preview-Karte. Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage und Telegram lesen sie alle, um die Karte zu erstellen, die vor einem Klick angezeigt wird.

X/Twitter ist der Sonderfall. Twitter Cards sind, in Googles Worten, „eine Erweiterung des Open Graph Protocol, die für Twitter gilt“ (web.dev). X prüft zuerst twitter:card / twitter:*-Tags und fällt pro Eigenschaft auf OG-Tags zurück; wenn twitter:card vollständig fehlt, kann X trotzdem eine Karte aus OG-Daten erstellen, verwendet aber standardmäßig den einfachen summary-Kartentyp. Wissenswert: Das alte Twitter Card Validator-Tool wurde um 2022 eingestellt, als die Plattform umbenannt wurde – mehrere Konkurrenz-Guides verweisen noch darauf, als wäre es aktiv. Es gibt keinen offiziellen X-spezifischen Validator mehr; Debugger von Drittanbietern für OG füllen die Lücke.

Empfohlene og:image-Größe und -Format

Das Open Graph Protocol selbst legt keine Pixelmaße oder Seitenverhältnisse für og:image fest – ogp.me definiert nur die strukturierten Eigenschaften (og:image:width, og:image:height, og:image:type, og:image:alt), nicht eine erforderliche Größe. Die Größenbestimmung ist eine Entscheidung pro Konsument, und die Konsumenten sind sich nicht alle einig:

  • LinkedIn dokumentiert sein eigenes Minimum direkt: 1200 × 627 px, 1,91:1-Verhältnis; Bilder, die schmaler als etwa 401 px sind, werden nur als kleines Vorschaubild gerendert.
  • Google Discover dokumentiert mindestens 1200 px breit, mehr als 300 000 Gesamtpixel, 16:9-Seitenverhältnis (Beispiel: 1280×720) für seine Metadaten zum bevorzugten Bild – ein deutlich anderes Verhältnis als die unten genannte Social-Card-Konvention.
  • Facebooks aktuelle Sharing-Dokumentation verlangt Bilder „mindestens 1080 Pixel breit“, ohne ein universelles Verhältnis festzulegen; für Details verweist sie auf einen separaten Best-Practices-Leitfaden.

Angesichts dieser Bandbreite bleibt 1200 × 630 px (etwa 1,91:1) der praktische plattformübergreifende Standard, den die meisten Implementierer verwenden – er liegt nahe an LinkedIns eigenem Minimum und wird auf Facebook, Slack, Discord, WhatsApp und iMessage akzeptabel (wenn auch nicht immer pixelgenau) dargestellt, und X zeigt ihn als große Bildkarte. Behandeln Sie ihn als sinnvolle Konvention, nicht als Regel, die eine einzelne Spezifikation vorschreibt – wenn Ihnen eine bestimmte Plattform sehr wichtig ist, prüfen Sie deren aktuelle Dokumentation, statt anzunehmen, dass dieser Wert dort garantiert korrekt ist.

Zwei Dinge sind harte Regeln, keine Konventionen:

  • Absolute URL erforderlich. og:image muss auf eine vollständige https://…-URL verweisen; ein relativer Pfad wird von Crawlern ignoriert.
  • Keine generischen Logos oder textlastigen Bilder, wenn das Bild auch für die Thumbnail-Auswahl von Google in Frage kommen soll – Google warnt ausdrücklich vor beidem und vor extremen Seitenverhältnissen. Setzen Sie auch og:image:alt mit einer echten Beschreibung.

Was passiert, wenn Open-Graph-Tags fehlen

Ein verbreiteter Mythos ist, dass „keine OG-Tags“ „reiner Textlink, kein Bild“ bedeutet. Das stimmt nicht – Plattformen greifen auf Alternativen zurück, sie lassen nichts leer. Facebook füllt die Lücken aus dem <title> der Seite, der Meta-Description und dem ersten verwendbaren Inhaltsbild; LinkedIn verhält sich ähnlich und behandelt Bilder, die schmaler als etwa 401 px sind, nur als Vorschaubild. Das eigentliche Risiko beim Weglassen von OG-Tags ist also eine unkontrollierte, schlechtere Vorschau – ein zufälliges Bild im Text, ein trunkierter <title> – nicht eine fehlende. Wenn Ihnen wichtig ist, wie eine Seite beim Teilen aussieht (und bei allem, was Sie bewerben würden, sollte es das sein), setzen Sie die Tags, statt jede Plattform raten zu lassen.

Warum Ihre aktualisierten OG-Tags nicht angezeigt werden – Caching und erneutes Scraping

Das ist der häufigste praktische Schmerzpunkt. Facebook, LinkedIn und Slack cachen die gescrapten OG-Daten, sodass das Bearbeiten Ihrer Tags bereits geteilte Links nicht rückwirkend aktualisiert. Facebooks eigene Webmaster-Dokumentation bestätigt einen spezifischen Mechanismus, den es zu kennen lohnt: „Bilder werden basierend auf der URL gecacht und werden nicht aktualisiert, es sei denn, die URL ändert sich“ – wenn Sie also ein hängengebliebenes Bild beheben möchten, kann das Ändern des og:image-Dateinamens (nicht nur seines Inhalts) einen neuen Abruf erzwingen. Ich habe keine Quelle von Erstanbietern dafür, wie lange der Cache jeder Plattform genau lebt, bevor er von selbst abläuft – behandeln Sie also keine konkrete Dauer, die Sie anderswo zitiert sehen, als dokumentierte Garantie – erzwingen Sie stattdessen pro Plattform ein erneutes Scraping, statt darauf zu warten:

  • Facebook Sharing Debugger (developers.facebook.com/tools/debug) – fügen Sie die URL ein und verwenden Sie „Scrape Again“, um einen neuen Abruf auszulösen.
  • LinkedIn Post Inspector – ruft die Karte erneut ab und zeigt eine Vorschau; wenn das Bild weiterhin nicht geladen wird, prüfen Sie, ob es blockiert ist oder hinter einer Anmeldung liegt.
  • X/Twitter – kein offizieller Validator seit etwa 2022. Da X auf OG-Tags zurückfällt, ist ein allgemeiner OG-Debugger plus ein neues Teilen der praktische Weg.

Da Crawler cachen und sich Inhalte ändern, sind OG-Tags nicht wirklich „einmal setzen und vergessen“: Nach einer größeren Inhalts- oder Bildaktualisierung auf einer hochwertigen Seite sollten Sie sie erneut scrapen.

Implementierungs-Stolperfallen: JavaScript, Bytelimits, absolute URLs

Der größte Punkt hängt direkt mit dem Rendering zusammen: Die meisten Crawler von Social-Media-Plattformen führen kein JavaScript aus. OG-Tags, die clientseitig injiziert werden – etwa von React nach der Hydration – sind für sie unsichtbar; der Crawler sieht ein leeres <head>. Die Tags müssen im rohen, serverseitig gerenderten HTML vorhanden sein. Dies ist dieselbe Crawl-vs.-Render-Unterscheidung, die JavaScript-lastige Websites auch anderswo betrifft (siehe JavaScript-SEO). Von Slack wird berichtet (nicht in einer offiziellen Spezifikation dokumentiert), dass es nur eine begrenzte Anzahl von Bytes vom Anfang einer Seite abruft. Setzen Sie Ihre OG-Tags daher als Sicherheitsmarge früh in <head>, statt sie nach einem großen Inline-Skript- oder Style-Block zu platzieren. Und noch einmal, weil es der stille Killer ist: og:image muss eine absolute URL sein.

Bing, Microsoft und Open Graph

Zu Bing ist hier weit weniger dokumentiert als zu Google. Der Markup-Validator von Bing (in den Bing-Webmaster-Tools) listet Open Graph unter den strukturierten Markup-Formaten auf, die er erkennt, neben schema.org, Microdata, Microformats und RDFa. Auch weist Bings Migrationsleitfaden darauf hin, OG-Metadaten während eines Umzugs aktuell zu halten – aber Bing hat keine Google-ähnlichen Details dazu veröffentlicht, ob oder wie OG-Daten in seine Snippets oder Thumbnails einfließen. In der Praxis ist der stärkere Konsument von OG-Tags im Microsoft-Ökosystem LinkedIn (im Besitz von Microsoft), das og:title, og:description, og:image und og:url liest, um seine Share-Karten zu erstellen. Behaupten Sie nicht zu viel über einen Bing-Mechanismus, der nicht dokumentiert ist.

Häufige Open-Graph-Mythen, entlarvt

  • „OG-Tags sind ein Google-Ranking-Faktor.“ Nein – keine offizielle Quelle sagt das. Sie beeinflussen die Darstellung (Titel-Link, Bild-Thumbnail, Site-Name-Quellen), nicht die Position.
  • „OG ist nur für Facebook, für echtes SEO irrelevant.“ Veraltet. Googles eigene Dokumentation listet og:title (Titel-Links, hinzugefügt Aug. 2024), og:image (eine Bildauswahl-Eingabe für die Suche/Discover) und og:site_name (eine Site-Name-Eingabe mit niedrigerer Priorität) als drei separate Darstellungsfunktionen, für die es OG-Tags liest – wobei „AI Overviews“ speziell auf Branchenpresse-Berichte zurückgeht, nicht auf eine Behauptung auf Googles eigenen Images/Discover-Seiten zum Zeitpunkt dieser Prüfung.
  • „Keine OG-Tags bedeuten einen schlichten Link ohne Bild.“ Nein – Plattformen fallen auf <title>/Meta-Description/erstes Bild zurück, was eine unkontrollierte Vorschau ergibt, keine leere.
  • „Das Aktualisieren von og:image behebt sofort jeden bereits geteilten Link.“ Nein – Facebook/LinkedIn/Slack cachen den Scrape; Sie müssen ein erneutes Scraping erzwingen, und CDN-Caching kann es weiter verzögern.
  • „Nutzen Sie den Twitter-Card-Validator, um X-Vorschauen zu beheben.“ Dieses Tool wurde ~2022 eingestellt; es gibt jetzt keinen offiziellen X-Validator.
  • „Jede Bildgröße/URL funktioniert für og:image.“ Nein – es muss eine absolute URL sein, und Google warnt vor generischen Logos, Text-im-Bild und extremen Seitenverhältnissen für die eigene Thumbnail-Auswahl.

Wo es weitergeht

Diese Seite ist ein tiefer Einblick unter dem Meta-Tags-für-SEO-Hub, der Karte des On-Page-Clusters, welche Head-Elemente tatsächlich wichtig sind. Open Graph ist die Darstellungsebene für Social/Chat – ihre Geschwister auf der SERP-Darstellungsseite sind der Titel-Tag (den Google möglicherweise aus Ihrem og:title ableitet) und die Meta-Description (das nächste Analogon: kein Ranking-Faktor, alles um den Klick). Für die Bild- und Site-Name-Seite überschneidet sich OG mit Schema-Markup – Google behandelt og:image und primaryImageOfPage aus Schema als alternative Thumbnail-Quellen. Und da die meisten Social-Crawler kein JavaScript ausführen, hängt das gesamte Thema von Rendering und JavaScript-SEO ab.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.