Kostenlose Open-Graph- und Social-Card-Vorschau

Was ist Link-Unfurling und warum ist es wichtig?

Wenn du eine URL in Facebook, Twitter, LinkedIn, Slack, Discord, iMessage oder WhatsApp einfügst, schickt die Plattform einen Crawler zu dieser URL, liest die Meta-Tags im Seiten-Head und rendert eine Vorschaukarte mit Titel, Beschreibung und Bild. Diese Vorschau wird je nach Plattform Unfurl, Link-Karte oder Social Card genannt. Sie ist das Erste, was jeder Betrachter sieht, bevor er entscheidet, ob er klickt. Eine gut gerenderte Karte erhöht die Klickrate deutlich im Vergleich zu einem schlichten blauen Link, und eine kaputte Karte tötet das Engagement vollständig.

Das System basiert auf dem Open-Graph-Protokoll, das Facebook 2010 veröffentlichte, um Sharing-Plattformen eine Standardmethode zur Extraktion sauberer Vorschauen zu geben. Open Graph definiert einen Namespace von Meta-Tags mit dem Präfix og: — og:title, og:description, og:image, og:url, og:type und eine lange Liste optionaler Felder für Video, Audio, Artikel und Produkte. Twitter baute 2012 sein eigenes Twitter-Card-Protokoll darauf auf, mit einem twitter:-Namespace, der Open Graph überschreibt, wenn beide vorhanden sind. LinkedIn, Slack, Discord und die meisten Messaging-Apps lesen Open Graph direkt und fügen eigene Besonderheiten hinzu.

Jede Plattform wendet ihre eigene Rendering-Logik an. Facebook und LinkedIn rendern ein Hero-Bild mit Titel und Beschreibung darunter, das etwa vier Zeilen Feed-Platz einnimmt. Twitters summary_large_image-Karte rendert ein Hero-Bild mit dem URL-Host darunter. Slack rendert ein kompaktes Attachment mit einem kleinen Inline-Thumbnail. Discord rendert eine Karte, die Video- oder Audio-Embeds einbindet, wenn der Typ entsprechend gesetzt ist. iMessage rendert eine vertikale Karte mit einem quadratischen Bild. Derselbe Satz Meta-Tags steuert sie alle, aber das visuelle Ergebnis variiert genug, dass das separate Testen auf jeder Oberfläche der einzige Weg ist, Probleme zu erkennen.

Die Kosten eines kaputten Unfurls sind real. Ein Kampagnen-Tweet ohne Bild erhält einen Bruchteil des Engagements eines Tweets mit Karte. Ein LinkedIn-Post, der auf ein generisches Globus-Icon statt auf das Artikel-Hero-Bild unfurlt, wirkt unfertig. Ein Slack-Kanal, in dem ein Link auf ein 404-Bild unfurlt, untergräbt das Vertrauen in den Link selbst. Jedes dieser Probleme ist für sich genommen nicht katastrophal, aber für ein Marketing- oder Content-Team, das dutzende Links pro Woche veröffentlicht, ist der kumulative Verlust erheblich.

So nutzt du dieses Vorschau-Tool

Der Previewer rendert eine URL gleichzeitig auf allen wichtigen Plattformen, sodass du plattformspezifische Probleme erkennst, ohne jede einzeln testen zu müssen.

Schritt 1 — Füge deine URL ein. Gib eine vollständige URL in das Eingabefeld ein. Der Crawler ruft die Seite ab, liest den Head und extrahiert alle relevanten Open-Graph- und Twitter-Card-Tags. Wenn die Seite eine Authentifizierung erfordert oder hinter Cloudflares Bot-Challenge liegt, schlägt der Fetch fehl und der Previewer zeigt den Fehler an, damit du weißt, dass der Unfurl auch auf echten Plattformen fehlschlagen wird.

Schritt 2 — Scanne alle fünf Plattform-Karten. Facebook, LinkedIn, Twitter, Slack und Discord rendern nebeneinander. Achte auf fehlende Bilder, abgeschnittenen Text und Seitenverhältnis-Zuschnitte, die dein Hero-Artwork beschneiden. Der Previewer markiert fehlende erforderliche Tags in Rot und suboptimale Abmessungen in Gelb.

Schritt 3 — Bearbeiten und erneut vorschauen. Aktualisiere deine Meta-Tags in der Quellseite und klicke auf Aktualisieren. Der Previewer ruft eine frische Kopie ohne Cache ab, sodass du den neuen Stand sofort siehst. Sobald es hier richtig aussieht, stimmen die Live-Shares auf den tatsächlichen Plattformen überein — vorausgesetzt, du denkst daran, Facebooks und LinkedIns Caches nach der Aktualisierung zu invalidieren.

Plattformspezifische Rendering-Besonderheiten

Dieselben Meta-Tags erzeugen auf verschiedenen Plattformen unterschiedliche Karten, weil jede ihren eigenen Renderer hat. Die Unterschiede zu kennen spart Zeit, wenn etwas auf einer Plattform falsch aussieht, auf anderen aber korrekt ist.

Facebook

Facebook liest og:title, og:description, og:image und og:url und rendert eine Hero-Karte mit dem Bild oben, dem Titel fett darunter, der Beschreibung in Grau und der Host-Domain in Kapitälchen unten. Das Bild wird auf ein Seitenverhältnis von 1,91:1 zugeschnitten, wenn es nicht passt. Facebook cached das Ergebnis aggressiv — beim ersten Teilen einer URL scraped der Crawler die Tags, und nachfolgende Shares verwenden die gecachte Karte für Stunden oder Tage. Zur Aktualisierung füge die URL in den Sharing Debugger ein und klicke auf Scrape Again. Es gibt keinen anderen zuverlässigen Weg, den Cache zu invalidieren. Der Open-Graph-Crawler identifiziert sich mit dem User-Agent facebookexternalhit.

Twitter

Twitter liest zuerst twitter:card, twitter:title, twitter:description, twitter:image und twitter:site und fällt auf og:-Entsprechungen zurück, wenn der twitter:-Tag fehlt. Der Wert von twitter:card bestimmt das Layout: summary erzeugt ein kleines quadratisches Thumbnail links neben Titel und Beschreibung, das etwa einen Tweet Vertikalraum einnimmt; summary_large_image erzeugt ein großes Hero-Bild über dem Titel mit dem URL-Host darunter, was den visuellen Raum verdoppelt. Die Twitter-Card-Validierung wurde 2022 in Twitter Ads integriert, sodass der eigenständige Card Validator nicht mehr existiert, aber die Plattform respektiert das Protokoll noch genauso wie zuvor.

LinkedIn

LinkedIn liest Open Graph identisch zu Facebook und rendert eine ähnliche Hero-Karte. Der Crawler heißt LinkedInBot und cached Ergebnisse für etwa sieben Tage, sofern du nicht über den Post Inspector unter linkedin.com/post-inspector invalidierst. LinkedIn verlangt, dass og:image mindestens 1200 mal 627 Pixel groß (beachte die leicht abweichende Untergrenze) und unter 5 MB ist. Über HTTP ausgelieferte Bilder werden stillschweigend verworfen. LinkedIn ignoriert bei der Validierung auch die Hinweise og:image:width und og:image:height, also teste immer mit einem echten Fetch.

Slack

Slack liest Open Graph, rendert aber standardmäßig ein kompakteres Attachment. og:title wird zum Link-Titel, og:description zum Inhalt, und og:image wird als kleines Inline-Thumbnail daneben angezeigt. Workspaces können das Unfurl-Verhalten pro Kanal und pro App konfigurieren, was bedeutet, dass derselbe Link in einem Kanal als vollständige Karte und in einem anderen als einfache Text-URL erscheinen kann. Slack dedupliziert Unfurls auch innerhalb eines kurzen Zeitfensters, sodass das erneute Einfügen derselben URL nach dem Bearbeiten von Meta-Tags oft die gecachte Version anzeigt. Bot-Konten und Incoming Webhooks haben separate Unfurl-Einstellungen, die möglicherweise explizit aktiviert werden müssen.

Discord

Discord rendert Open-Graph-Karten als Embeds innerhalb der Nachricht, wobei das Bild inline als Hero dargestellt wird. Es respektiert auch og:video und bettet Video-Player direkt ein, wenn vorhanden – das macht Discord zu einer der wenigen Mainstream-Plattformen, auf denen sich Video-Open-Graph-Tags lohnen. Kartenfarben stammen aus theme-color im Meta-Head, wenn keine andere Farbe angegeben ist. Der Crawler ist Discordbot und im Gegensatz zu Facebook oder LinkedIn cached Discord nicht aggressiv – die meisten Änderungen sind innerhalb von Minuten sichtbar.

Bildgrößenanforderungen pro Plattform

Der häufigste Grund, warum eine Karte auf ein Thumbnail herabgestuft wird oder nicht rendert, ist das Bild. Jede Plattform hat eigene bevorzugte Abmessungen und Mindestgrößen.

Facebook und LinkedIn bevorzugen 1200 mal 630 Pixel im Seitenverhältnis 1,91:1. Beide rendern eine Karte mit Bildern bis hinunter zu 600 Pixel auf der langen Seite, stufen darunter aber auf ein kleines Thumbnail-Layout herab. Die Dateigröße sollte unter 5 MB bleiben. PNG und JPG funktionieren beide; WebP wird von Facebook unterstützt, aber nicht konsistent von LinkedIn – verwende daher PNG oder JPG für og:image.

Twitter bevorzugt 1200 mal 675 Pixel für summary_large_image, ein leicht breiteres 16:9-Verhältnis. Das Minimum liegt bei 300 mal 157, aber alles unter 600 Pixel Breite erzeugt einen sichtbaren Qualitätsverlust. Für summary-Karten ist das Bild quadratisch und wird im Feed auf 144 mal 144 zugeschnitten; gestalte das Bild so, dass die Mitte die Aussage trägt.

Slack akzeptiert fast jede Größe und skaliert das Bild auf ein kleines Thumbnail herunter. Das Thumbnail ist im Seiten-Rendering etwa 80 mal 80 Pixel groß. Details in einem 1200 Pixel breiten Bild sind in diesem Layout verschwendet, aber dasselbe Bild funktioniert problemlos, weil Slack skaliert statt zuschneidet.

Discord rendert das vollständige Bild inline bis zur größten Dimension, die die Chat-Oberfläche unterstützt – typischerweise bis zu 1280 Pixel Breite auf dem Desktop. Größere Bilder werden mit erhaltener Qualität verkleinert. Discord schneidet hohe Bilder auf ein maximales Seitenverhältnis zu, also vermeide hochformatige Bilder für Hero-Karten.

Die Tags og:image:width und og:image:height sind Abmessungshinweise, die Crawler nutzen, um Layout-Platz zu reservieren, bevor das Bild fertig geladen ist. Sie verändern das Bild nicht, helfen aber, die Vorschau ohne Layout-Shift zu rendern. Füge sie immer ein, wenn sie stabil sind, und verwende die tatsächlichen Pixelabmessungen der ausgelieferten Datei.

Häufige Fehler, die das Sharing beeinträchtigen

Relative og:image-URLs. Open Graph und Twitter Card verlangen beide absolute URLs. Ein Pfad wie /og.png wird von jeder großen Plattform stillschweigend abgelehnt. Verwende immer die vollständige Form https://example.com/og.png.

HTTP og:image auf einer HTTPS-Seite. Das Mischen von HTTP-Bild-URLs in einer HTTPS-Seite führt dazu, dass die meisten Plattformen das Bild verwerfen. Die Karte wird auf ein Thumbnail herabgestuft oder rendert ganz ohne Bild. Alle Open-Graph-URLs sollten HTTPS sein, unabhängig vom Seiten-Protokoll.

Fehlende og:image:width und og:image:height. Ohne Abmessungshinweise warten Crawler, bis das Bild geladen ist, bevor sie das Karten-Layout festlegen. Bei langsamen Bild-Hosts überschreitet die Plattform das Timeout und fällt auf eine kleinere Karte zurück. Füge die Hinweise immer ein, wenn du ein Bild mit bekannter Größe auslieferst.

Identisches og:image auf tausenden von Seiten. Ein einzelnes gemeinsames Bild funktioniert für die Homepage, macht aber jeden Artikel beim Teilen identisch. Vorlagenbasierte dynamische OG-Bilder, serverseitig aus Titel und Hintergrund generiert, geben jeder Seite eine unverwechselbare Karte ohne manuellen Aufwand.

Vergessen, Facebooks Cache nach Änderungen zu aktualisieren. Änderungen, die nach dem ersten Teilen einer URL vorgenommen wurden, sind unsichtbar, bis du über den Sharing Debugger erneut scrapesd. Teams, die Meta-Tags aktualisieren, ohne den Cache zu invalidieren, denken oft, ihre Änderungen hätten nicht funktioniert, obwohl die Plattformen tatsächlich gecachte alte Versionen anzeigen.

Falscher twitter:card-Wert. summary zu setzen, wenn du ein 1200 Pixel breites Hero-Bild hast, erzeugt eine kleine Thumbnail-Karte und verschwendet das Asset. summary_large_image zu setzen, ohne ein tatsächlich großes Bild zu haben, erzeugt eine Karte mit leerem Platz, wo das Hero sein sollte. Passe den Kartentyp an die Bildgröße an, die du auslieferst.

Beschreibung wörtlich aus dem Seiteninhalt kopiert. Ein abgeschnittener Einleitungsabsatz als og:description verkauft selten den Klick. Sharing-Vorschauen sind Werbetext in 200 Zeichen; behandle sie entsprechend und schreibe Beschreibungstext, der den Link rahmt, statt die Seite zusammenzufassen.

Randfälle, die niemand erwähnt

Open-Graph-Crawler sehen eine andere Version deiner Seite als Browser. Sie führen typischerweise kein JavaScript aus, speichern keine Cookies und haben schnellere Timeouts als ein normaler Fetch. Single-Page-Apps, die Meta-Tags clientseitig über React Helmet oder document.head injizieren, erzeugen leere Karten, weil der Crawler das initiale server-gerenderte HTML liest, bevor JavaScript ausgeführt wird. Die Lösung ist, Meta-Tags serverseitig über Next.js Metadata, Nuxts useHead oder Ähnliches zu rendern. Einige CDN-Konfigurationen blockieren auch Bot-User-Agents am Edge und geben facebookexternalhit eine 403 zurück, während Menschen normal bedient werden – ein Fehler, der unsichtbar bleibt, bis jemand den Link teilt und die Karte nicht rendert.