für saubere Share-Vorschauen auf jeder Plattform
Ein geteilter Link ohne Bild, mit abgeschnittenem Titel oder falscher Beschreibung wirkt unprofessionell und wird seltener geklickt. Open-Graph-Tags steuern exakt, wie eine URL bei Facebook, LinkedIn, WhatsApp und weiteren Plattformen als Vorschau erscheint. Wer og:image, og:title und og:description korrekt setzt und die Bildgrößen pro Plattform beachtet, verwandelt jeden geteilten Link in eine kleine Werbeanzeige statt in eine verpasste Chance.
Inhaltsverzeichnis
- 1. Was Open-Graph-Tags technisch tun
- 2. Die vollständige og:-Tag-Referenz
- 3. Bildgrößen-Regeln für og:image richtig anwenden
- 4. Facebook-Eigenheiten: Cache, Debugger und Bildverhältnis
- 5. LinkedIn-Eigenheiten: eigener Cache und Post-Inspector
- 6. WhatsApp-Eigenheiten: minimalistische Vorschau, harte Limits
- 7. Hyvä/Magento-Implementierung von Open-Graph-Tags
- 8. Fallback-Strategie für Kategorie- und Produktseiten
- 9. Testen, validieren und Cache-Probleme lösen
- 10. Zusammenfassung
- 11. FAQ
1. Was Open-Graph-Tags technisch tun
Open-Graph-Tags sind Meta-Tags im <head> einer Seite, die dem Open-Graph-Protokoll folgen, ursprünglich 2010 von Facebook eingeführt und mittlerweile von praktisch jeder größeren Plattform als De-facto-Standard für Link-Vorschauen übernommen. Sobald eine URL auf Facebook, LinkedIn, WhatsApp, Slack oder Discord geteilt wird, ruft die jeweilige Plattform die Seite mit einem eigenen Crawler ab, liest die Open-Graph-Tags aus und baut daraus die Vorschaukarte mit Bild, Titel und Beschreibung.
Ohne gepflegte Open-Graph-Tags fällt jede Plattform auf eigene Heuristiken zurück: das erste gefundene Bild der Seite, den <title>-Tag und einen zufällig extrahierten Textausschnitt. Das Ergebnis ist meist unvorhersehbar, oft ein falsches Bild, ein abgeschnittener Titel oder eine Beschreibung, die aus der Navigation stammt statt aus dem eigentlichen Inhalt. Wer Open-Graph-Tags bewusst konfiguriert, übernimmt die volle Kontrolle über dieses Erscheinungsbild, unabhängig davon, welche Heuristik die jeweilige Plattform sonst anwenden würde.
2. Die vollständige og:-Tag-Referenz
Die Basis jeder Open-Graph-Implementierung besteht aus vier Pflicht-Properties: og:title, og:type, og:image und og:url. Darüber hinaus gibt es eine Reihe empfohlener und optionaler Properties, die je nach Content-Typ die Vorschau präzisieren. og:description liefert den Vorschautext, og:site_name zeigt den Markennamen unter dem Titel, und og:locale steuert die Sprachvariante der Vorschau, relevant für mehrsprachige Shops mit DE- und EN-Versionen.
Für Bild-Properties gibt es eine feine, aber wichtige Unterscheidung: og:image ist die URL selbst, während og:image:width, og:image:height und og:image:alt zusätzliche Metadaten liefern, die Plattformen beim Rendern verwenden, bevor das Bild überhaupt heruntergeladen wurde. Fehlen Breite und Höhe, muss die Plattform das Bild erst laden, um das Seitenverhältnis zu bestimmen, was bei langsamen Servern zu verzögerten oder fehlerhaften Vorschauen führen kann. Diese Angaben sind deshalb kein optionales Detail, sondern ein Performance-relevanter Bestandteil der Open-Graph-Tags.
<!-- Complete Open Graph tag set for a product page -->
<meta property="og:title" content="Wanderschuh Alpin Pro 2 - wasserdicht, Gore-Tex">
<meta property="og:type" content="product">
<meta property="og:url" content="https://mironsoft.de/wanderschuh-alpin-pro-2">
<meta property="og:image" content="https://mironsoft.de/media/catalog/product/alpin-pro-2-1200x630.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Wanderschuh Alpin Pro 2 in Schwarz-Orange, Seitenansicht">
<meta property="og:description" content="Wasserdichter Wanderschuh mit Gore-Tex-Membran, Vibram-Sohle und verstaerktem Zehenschutz. Ab Lager lieferbar.">
<meta property="og:site_name" content="mironsoft.de">
<meta property="og:locale" content="de_DE">
<meta property="og:locale:alternate" content="en_US">
<meta property="product:price:amount" content="149.90">
<meta property="product:price:currency" content="EUR">
3. Bildgrößen-Regeln für og:image richtig anwenden
Die häufigste Fehlerquelle bei Open-Graph-Tags ist ein falsch dimensioniertes Bild. Die aktuelle Empfehlung für og:image liegt bei 1200 x 630 Pixel, ein Seitenverhältnis von ungefähr 1,91:1. Bilder unter 200 x 200 Pixel werden von Facebook und LinkedIn oft gar nicht als große Vorschaukarte angezeigt, sondern nur als kleines Thumbnail neben dem Text, was die Klickrate deutlich reduziert. Die Dateigröße sollte 8 MB nicht überschreiten, in der Praxis empfiehlt sich aber eine komprimierte JPEG- oder WebP-Datei unter 300 KB, damit der Crawler das Bild zuverlässig und schnell abruft.
Ein zweiter, oft übersehener Punkt betrifft sicheres Laden: og:image:secure_url war früher notwendig für HTTPS-Bilder auf HTTP-Seiten, heute mit durchgängigem HTTPS in der Regel überflüssig, aber viele ältere Implementierungen führen es weiterhin doppelt. Wichtiger in der Praxis ist die absolute URL: og:image muss immer eine vollständige URL mit Protokoll sein, niemals ein relativer Pfad, da die Crawler der Plattformen keine Basis-URL der Seite kennen und einen relativen Pfad schlicht nicht auflösen können.
| Plattform | Empfohlene Bildgröße | Seitenverhältnis | Besonderheit |
|---|---|---|---|
| 1200 x 630 px | 1,91:1 | Zentrierter Bildausschnitt bei Abweichung | |
| 1200 x 627 px | ~1,91:1 | Eigener Cache, 7 Tage TTL | |
| 300 x 200 px min. | Quadratisch bevorzugt | Harte Größenlimits, kleine Vorschau | |
| Slack | 1200 x 630 px | 1,91:1 | Unbegrenzte Cache-Dauer ohne Refresh-API |
| Discord | 1200 x 630 px | 1,91:1 | Rendert og:image auch ohne og:type |
| Telegram | 1200 x 630 px | 1,91:1 | Kein eigener Cache, liest bei jedem Share neu |
4. Facebook-Eigenheiten: Cache, Debugger und Bildverhältnis
Facebook cacht Open-Graph-Daten pro URL für bis zu 30 Tage, unabhängig davon, wie oft sich der Inhalt der Seite ändert. Das bedeutet: Wird ein og:image nachträglich ausgetauscht, zeigt Facebook unter Umständen wochenlang weiterhin das alte Bild an, weil der Crawler die Seite nicht automatisch erneut abruft. Die Lösung ist der Facebook Sharing Debugger, mit dem sich der Cache für eine spezifische URL manuell erneuern lässt, ein Schritt, der nach jeder Änderung an og:title, og:description oder og:image zwingend nötig ist, damit die neue Vorschau sichtbar wird.
Eine weitere Facebook-Eigenheit betrifft die Bildzuschneidung: Weicht das Seitenverhältnis vom empfohlenen 1,91:1 ab, beschneidet Facebook das Bild automatisch mittig, was bei Produktbildern mit wichtigen Details am Rand zu unschönen Ergebnissen führt. Für E-Commerce-Bilder empfiehlt sich deshalb ein dediziertes og:image, das sich vom eigentlichen Produktbild unterscheidet und bereits im richtigen Seitenverhältnis mit ausreichend Rand um das Hauptmotiv herum vorliegt.
5. LinkedIn-Eigenheiten: eigener Cache und Post-Inspector
LinkedIn verwendet einen eigenen Crawler, der unabhängig vom Facebook-Crawler arbeitet und Open-Graph-Tags mit einer typischen Cache-Dauer von etwa sieben Tagen abruft. Wichtig ist, dass LinkedIn og:image zuverlässig ausliest, aber bei fehlendem oder zu kleinem Bild eher zurückhaltend eine Fallback-Vorschau ohne Bild anzeigt, statt wie Facebook automatisch ein beliebiges Seitenbild zu wählen. Das macht ein korrekt gesetztes og:image auf LinkedIn noch wichtiger als auf anderen Plattformen, insbesondere für B2B-Content, der häufig auf LinkedIn geteilt wird.
Zum Testen und Erzwingen einer Cache-Aktualisierung bietet LinkedIn den Post Inspector an, ein offizielles Tool, das die aktuell ausgelesenen Open-Graph-Daten anzeigt und einen manuellen Refresh auslöst. In der Praxis empfiehlt es sich, nach jedem Redesign oder jeder Content-Migration systematisch die wichtigsten URLs durch den Post Inspector zu schicken, bevor eine größere Kampagne mit Linkshares auf LinkedIn gestartet wird, um veraltete Cache-Einträge zu vermeiden.
<!-- LinkedIn-specific reinforcement: og:image:type helps the crawler
pick the correct MIME type without a HEAD request round trip -->
<meta property="og:image" content="https://mironsoft.de/media/catalog/product/alpin-pro-2-1200x627.jpg">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="627">
<!-- Article-type extension for blog posts (LinkedIn reads these too) -->
<meta property="article:published_time" content="2026-07-23T08:00:00+02:00">
<meta property="article:author" content="https://mironsoft.de/ueber-uns">
Der Zusatz og:image:type erspart LinkedIn eine separate HEAD-Anfrage zur MIME-Type-Erkennung und beschleunigt den Aufbau der Vorschaukarte spürbar, besonders bei Bildern, die über ein CDN mit generischem Content-Type ausgeliefert werden.
6. WhatsApp-Eigenheiten: minimalistische Vorschau, harte Limits
WhatsApp nutzt ebenfalls Open-Graph-Tags, rendert die Vorschau aber deutlich kompakter als Facebook oder LinkedIn: kleines Vorschaubild links, Titel und ein kurzer Beschreibungsausschnitt daneben. Der wichtigste technische Unterschied ist eine harte Größenbeschränkung des Bildes auf 300 KB in vielen App-Versionen, deutlich strenger als die 8 MB, die Facebook offiziell erlaubt. Ein zu großes og:image wird auf WhatsApp häufig gar nicht angezeigt, die Vorschau erscheint dann komplett ohne Bild, nur mit Titel und URL.
Ein weiteres WhatsApp-spezifisches Verhalten betrifft die Cache-Dauer auf mobilen Geräten: Anders als Facebook und LinkedIn hat WhatsApp keinen offiziellen Debugger, mit dem sich der Cache manuell erneuern lässt. In der Praxis hilft oft nur ein Anhängen eines Query-Parameters an die URL, um den Cache-Schlüssel zu verändern, allerdings nur als Notlösung, da dies für Kampagnenlinks zu unschönen, langen URLs führt. Der zuverlässigste Weg bleibt, og:image von Anfang an klein genug zu halten, damit WhatsApp es überhaupt zuverlässig lädt.
7. Hyvä/Magento-Implementierung von Open-Graph-Tags
In Hyvä-Themes werden Open-Graph-Tags am saubersten über ein eigenes ViewModel gesteuert, das im Head-Template die passenden Meta-Tags pro Seitentyp ausgibt: Produktseiten erhalten og:type="product" mit Preis- und Verfügbarkeitsdaten, Kategorieseiten und CMS-Seiten fallen auf og:type="website" zurück, Blogbeiträge auf og:type="article". Wichtig ist, dass das og:image für Produktseiten aus dem bereits vorhandenen Produktbild abgeleitet wird, idealerweise mit einem eigenen Image-Cache-Preset in der passenden 1200x630-Auflösung, statt das Originalbild in voller Auflösung auszuliefern.
Für Kategorien ohne eigenes Titelbild und für CMS-Seiten ohne redaktionell gepflegtes Bild empfiehlt sich ein Default-og:image auf Store-Ebene, das über die Store Configuration gepflegt wird und als Fallback dient. Diese Fallback-Logik verhindert, dass Facebook oder LinkedIn beim Fehlen eines spezifischen Bildes irgendein zufälliges Bild von der Seite wählt, etwa ein Logo in falscher Auflösung oder ein Icon aus der Navigation, was in der Praxis regelmäßig zu unprofessionell wirkenden Vorschauen führt.
<!--
app/design/frontend/Mironsoft/default/Magento_Theme/templates/html/head/og-tags.phtml
ViewModel: Mironsoft\SeoSuite\ViewModel\OpenGraph (ArgumentInterface)
-->
<?php /** @var \Mironsoft\SeoSuite\ViewModel\OpenGraph $openGraph */ ?>
<meta property="og:type" content="<?= $escaper->escapeHtmlAttr($openGraph->getType()) ?>">
<meta property="og:title" content="<?= $escaper->escapeHtmlAttr($openGraph->getTitle()) ?>">
<meta property="og:description" content="<?= $escaper->escapeHtmlAttr($openGraph->getDescription()) ?>">
<meta property="og:url" content="<?= $escaper->escapeUrl($openGraph->getCanonicalUrl()) ?>">
<meta property="og:site_name" content="<?= $escaper->escapeHtmlAttr($openGraph->getSiteName()) ?>">
<?php foreach ($openGraph->getImages() as $image): ?>
<meta property="og:image" content="<?= $escaper->escapeUrl($image->getUrl()) ?>">
<meta property="og:image:width" content="<?= (int) $image->getWidth() ?>">
<meta property="og:image:height" content="<?= (int) $image->getHeight() ?>">
<meta property="og:image:alt" content="<?= $escaper->escapeHtmlAttr($image->getAlt()) ?>">
<?php endforeach; ?>
8. Fallback-Strategie für Kategorie- und Produktseiten
Eine robuste Fallback-Strategie für Open-Graph-Tags folgt einer klaren Prioritätenkette: zuerst ein redaktionell gepflegtes, seitenspezifisches Bild, dann das primäre Produkt- oder Kategoriebild in der richtigen Auflösung, dann ein themenspezifisches Standardbild und erst zuletzt ein generisches Marken-og:image auf Store-Ebene. Diese Kette sollte serverseitig im ViewModel abgebildet werden, damit im Template selbst keine Fallback-Logik verstreut ist und jede Seite garantiert ein gültiges og:image ausgibt, auch wenn redaktionelle Daten fehlen.
Besonders bei Produktvarianten mit vielen Farboptionen lohnt sich eine dynamische Bildauswahl: Statt für jede Variante ein neues og:image zu generieren, reicht in der Regel ein repräsentatives Bild der Standardvariante, ergänzt um og:title mit dem konkreten Variantennamen. Das reduziert den Bildverwaltungsaufwand erheblich, ohne die Qualität der Vorschau spürbar zu verschlechtern, da die meisten Nutzer beim Teilen ohnehin nicht jede einzelne Variante im Detail vergleichen.
Für internationale Shops mit mehreren Store-Views gilt zusätzlich: Die Fallback-Kette muss pro Sprache und Store separat konfigurierbar sein, da ein deutsches Standardbild mit deutschem Text auf einer englischen Store-View fehl am Platz ist. In Hyvä lässt sich das über store-spezifische Konfigurationswerte lösen, die im ViewModel anhand der aktuellen Store-ID aufgelöst werden, bevor die Fallback-Kette überhaupt greift.
Mironsoft
Open-Graph-Integration und Social-SEO für Hyvä/Magento-Shops
Fehlerhafte Share-Vorschauen kosten Klicks und Vertrauen?
Wir implementieren vollständige, plattformkonforme Open-Graph-Tags in eurem Hyvä-Theme, inklusive Fallback-Strategie, Bild-Presets und Validierung über alle wichtigen Sharing-Plattformen hinweg.
og-Tag-Audit
Bestehende Open-Graph-Tags prüfen und Lücken identifizieren
ViewModel-Implementierung
Saubere og-Tag-Ausgabe mit Fallback-Kette pro Seitentyp
Bild-Presets
1200x630-Bildvarianten automatisiert aus Produktbildern erzeugen
9. Testen, validieren und Cache-Probleme lösen
Vor jedem Rollout gehört das Testen der Open-Graph-Tags zum Pflichtprogramm. Der Facebook Sharing Debugger, der LinkedIn Post Inspector und Tools wie Twitter Card Validator oder generische Open-Graph-Checker zeigen, welche Werte die jeweilige Plattform tatsächlich ausliest, nicht nur, was im Quellcode steht. Unterschiede zwischen beiden entstehen oft durch fehlerhafte Escaping-Regeln, doppelte Meta-Tags mit widersprüchlichen Werten oder ein og:image, das per robots.txt oder Referrer-Policy blockiert wird und deshalb vom Crawler nicht geladen werden kann.
Ein häufiges, schwer zu diagnostizierendes Problem ist eine zu restriktive Content-Security-Policy oder ein Hotlink-Schutz, der Bildanfragen ohne passenden Referrer blockiert. Da Social-Crawler oft ohne Standard-Browser-Header anfragen, kann ein serverseitiger Bot-Schutz das og:image versehentlich mit aussperren. Der zuverlässigste Weg, das zu erkennen, ist ein direkter Blick in die Server-Logs nach User-Agents wie facebookexternalhit, LinkedInBot oder WhatsApp und die Prüfung, ob diese Anfragen tatsächlich mit Statuscode 200 beantwortet werden.
Ein regelmäßiger Check lohnt sich auch nach Infrastruktur-Änderungen wie einem CDN-Wechsel oder einer neuen WAF-Regel, da diese Systeme Social-Crawler ohne erkennbaren Browser-Fingerprint fälschlicherweise als Bots blockieren können, die eigentlich unerwünscht sind. Ein monatlicher Durchlauf der wichtigsten Landingpages durch den Facebook Sharing Debugger deckt solche Regressionen zuverlässig auf, bevor eine Marketing-Kampagne mit fehlerhaften Vorschauen startet.
Open-Graph-Tags optimal konfigurieren: Das Wichtigste auf einen Blick
Pflicht-Properties
og:title, og:type, og:image und og:url sind Minimum. og:description und og:site_name gehören in jede solide Implementierung.
Bildgröße
1200x630 Pixel, Seitenverhältnis 1,91:1, unter 300 KB komprimiert, immer als absolute URL angegeben.
Cache-Management
Facebook Sharing Debugger und LinkedIn Post Inspector nach jeder Änderung nutzen, um veraltete Vorschauen zu erneuern.
Hyvä-Implementierung
Zentrales ViewModel mit Fallback-Kette pro Seitentyp, Bild-Presets in korrekter Auflösung statt Originalbildern.
10. Zusammenfassung
Open-Graph-Tags entscheiden darüber, ob ein geteilter Link professionell aussieht oder als leere Vorschau ohne Bild und mit abgeschnittenem Titel im Feed landet. Die Basis aus og:title, og:type, og:image und og:url muss auf jeder Seite vorhanden sein, ergänzt um og:description, og:site_name und präzise Bild-Metadaten wie og:image:width und og:image:height. Plattformspezifische Eigenheiten bei Facebook, LinkedIn und WhatsApp, insbesondere unterschiedliche Cache-Zeiten und Bildgrößenlimits, erfordern eine bewusste Teststrategie statt einer einmaligen Konfiguration.
In Hyvä-Themes gehört die og-Tag-Ausgabe in ein zentrales ViewModel mit klarer Fallback-Kette, damit jede Seite garantiert gültige Open-Graph-Tags ausgibt, auch ohne redaktionell gepflegtes Bild. Wer diese Struktur einmal sauber aufbaut, spart sich wiederkehrende Debugging-Sessions mit dem Facebook Sharing Debugger und sorgt dafür, dass jeder geteilte Link tatsächlich die gewünschte Wirkung erzielt.