Open Graph Checker
Open-Graph-Tags sind die Meta-Tags, die entscheiden, wie eine Seite aussieht, wenn ihr Link in Facebook, X, LinkedIn, Slack oder eine Chat-App eingefügt wird. Geben Sie eine URL ein, und dieser Checker ruft die Seite einmal ab, zeigt genau, welche Tags und Fallbacks jede Plattform verwenden wird, rendert die vier Share Cards und prüft die echten Maße des Vorschaubilds. Der Begleitartikel prüfen Sie Ihre Share Cards, bevor Sie posten führt durch die Behebung der Befunde; für die breitere Routineprüfung nutzen Sie stattdessen den Website-Gesundheitscheck.
Zuletzt aktualisiert:
Soll das laufend überwacht werden? Kostenlos mit myeventwatch überwachen — Ablauf- und Ausfallwarnungen, keine Karte nötig.
So läuft die Prüfung
Der Checker macht einen einzigen geschützten Serverabruf der eingegebenen URL, folgt Weiterleitungen und liest das statische HTML der finalen Seite — dasselbe HTML, das ein Plattform-Scraper sieht. Er parst die Meta-Tags og: und twitter:, den <title> der Seite und die Meta-Beschreibung und rechnet dann Plattform für Plattform aus, welchen Wert jede Share Card tatsächlich zeigen wird und woher dieser Wert stammt. Werte, die aus einem Fallback kommen, sind als Fallback beschriftet, damit eine vollständig wirkende Card kein fehlendes Tag darunter verbirgt.
Eine Grenze prägt alles andere: Das hier ist ein einfacher HTTP-Abruf, kein Browser, und Plattform-Scraper sind ebenfalls keine Browser — keiner von beiden führt JavaScript aus. Tags, die per Skript injiziert, clientseitig gerendert oder nur nach einer Anmeldung hinzugefügt werden, sind hier unsichtbar und bei Facebook, X, LinkedIn und Slack auf genau dieselbe Weise unsichtbar. Wenn ein Tag nur in Ihrem JavaScript-Bundle existiert, existiert es fürs Teilen nicht. Was Sie im Ergebnis sehen — finale URL, HTTP-Status, die rohe Tag-Tabelle und die vier gerenderten Cards — ist die statische Wahrheit, mit der die Scraper arbeiten müssen.
Fallbacks, die Falle des relativen Bilds und Scraper-Caches
Jede Plattform fällt anders zurück, weshalb dieselbe Seite in einer App richtig und in einer anderen kaputt aussehen kann. Facebook liest die og:-Tags direkt. X liest zuerst seine eigenen twitter:-Tags und fällt auf die passenden og:-Tags zurück, wenn sie fehlen. LinkedIn liest nur die og:-Tags, sodass ein perfektes Twitter-Card-Setup dort nichts hilft. Slack liest zuerst die og:-Tags und dann die twitter:-Tags. Die Checkliste unten markiert jedes fehlende Feld, jedes leere Feld und jedes Feld, das eine Plattform aus einem Fallback füllen würde, und nennt die Quelle, auf die sie zurückfallen würde.
Der häufigste stille Fehler ist ein relatives og:image: Ein Wert wie /images/share.jpg sieht in Ihrer Vorlage und in Ihrem Browser gut aus, aber die meisten Scraper können ihn gegen nichts auflösen, sodass die Card einfach kein Bild zeigt. Die Behebung ist immer eine absolute URL, inklusive Schema. Die zweite Falle ist das Caching: Jede Plattform cached, was ihr Scraper abgerufen hat, sodass das Beheben der Tags bereits veröffentlichte Beiträge nicht aktualisiert, und selbst eine frische Vorschau kann die alte Card weiter ausliefern, bis Sie die Plattform bitten, die URL erneut zu scrapen. Beheben Sie zuerst die Tags, verifizieren Sie sie hier und scrapen Sie dann erneut — in dieser Reihenfolge, sonst cachen Sie die kaputte Version gleich wieder.
Ehrlichkeitsgrenzen: Eine Vorschau hier ist eine Simulation des dokumentierten Verhaltens jeder Plattform, kein Screenshot eines echten Beitrags. Plattformen beschneiden, runden und kürzen unterschiedlich, ändern ihre Card-Layouts ohne Ankündigung und behandeln angemeldete und abgemeldete Betrachter möglicherweise unterschiedlich — behandeln Sie die Cards also als treues Modell, nicht als Garantie. Eines wird nicht simuliert: Die Maße des Vorschaubilds werden aus den Headern der echten Bilddatei gelesen, nicht aus den Werten og:image:width und og:image:height, die die Seite deklariert — deklarierte Werte sind Behauptungen, und dieser Checker prüft sie an der Datei selbst.
Was geprüft wird — und die Regeln dahinter
| Geprüfte Tags | og:title, og:description, og:image, og:url, og:type und og:site_name, plus twitter:card, twitter:title, twitter:description und twitter:image — und als Fallback-Quellen der <title> der Seite und die Meta-Beschreibung. |
| Empfohlene Bildgröße — 1200 × 630 px | 1200 × 630 ist Plattform-Empfehlung, kein formaler Standard: Es ist die Größe, die Facebook empfiehlt, und die Größe für große Cards, mit der X, LinkedIn und Slack am besten umgehen. Kleinere Bilder werden trotzdem angezeigt, aber Cards können sie beschneiden oder auf ein kleines Vorschaubild zurückfallen. |
| Liest die og:-Tags direkt — og:title, og:description und og:image — und fällt nur dann auf den <title> der Seite und die Meta-Beschreibung zurück, wenn die og:-Tags fehlen. | |
| X (Twitter) | Liest zuerst twitter:title, twitter:description und twitter:image; jedes fällt auf das passende og:-Tag zurück, wenn es fehlt. twitter:card wählt das Card-Layout, und ohne es rät X aus dem, was es findet. |
| LinkedIn und Slack | LinkedIn liest nur die og:-Tags — twitter:-Tags helfen dort nicht. Slack liest zuerst die og:-Tags und dann die twitter:-Tags und ist damit der nachsichtigste der vier. |
| Relative Bild-URLs | og:image und twitter:image müssen absolute URLs sein, Schema inklusive. Die meisten Scraper können einen relativen Pfad nicht auflösen, und das Ergebnis ist eine Card ohne Bild und ohne Fehlermeldung an irgendeiner Stelle. |
| Bildmaße | Gelesen aus der echten Bilddatei — ihren PNG-, JPEG-, GIF- oder WebP-Headern — zusammen mit ihrer Byte-Größe und ihrem Format. Die deklarierten og:image:width und og:image:height werden zum Vergleich gezeigt, aber ihnen wird nie allein vertraut. |
| Maße unbekannt | Bedeutet, der Checker konnte die Bilddatei nicht abrufen oder parsen — sie lief in ein Timeout, verweigerte die Anfrage oder hat ein Format, dessen Header er nicht lesen kann. Die deklarierten Maße der Seite, falls vorhanden, sind dann alles, was irgendjemand hat, Scraper eingeschlossen. |
Häufige Fragen
Warum zeigt mein geteilter Link kein Bild?
Die üblichen Ursachen, in dieser Reihenfolge: Es gibt überhaupt kein og:image; das og:image ist eine relative URL, die Scraper nicht auflösen können; das Bild ist zu klein oder liegt an einem Ort, den der Scraper nicht abrufen kann (hinter einer Anmeldung, durch robots-Regeln blockiert oder mit einem Fehler antwortend); oder die Plattform zeigt noch ihren gecachten Scrape von vor der Existenz des Bilds. Führen Sie die Prüfung oben aus — sie benennt, welche davon zutrifft —, beheben Sie das Tag und bitten Sie die Plattform dann um einen erneuten Scrape.
Open-Graph- oder Twitter-Tags — brauche ich beide?
In der Praxis: ja. Facebook und LinkedIn lesen nur die og:-Tags, während X seine eigenen twitter:-Tags bevorzugt und die og:-Tags als Fallback nutzt. Ein vollständiger og:-Satz plus ein twitter:card-Tag deckt die meisten Fälle ab, aber ein explizites twitter:title, twitter:description und twitter:image ist die einzige Möglichkeit, die X-Card von der Facebook-Card unterscheiden zu lassen — und Slack liest beide Sätze, og: zuerst.
Warum sieht der echte Beitrag anders aus als diese Vorschau?
Fast immer: Caching. Der Scraper jeder Plattform cached, was er für eine URL abgerufen hat, und das Bearbeiten Ihrer Tags macht diesen Cache nicht ungültig. Ein Beitrag, der vor der Behebung erstellt wurde, behält die alte Card, und selbst der Debugger der Plattform kann die gecachte Version weiter zeigen, bis ein erneuter Scrape erzwungen wird. Seltener ist der Unterschied der Zuschnitt: Plattformen beschneiden und kürzen auf ihr aktuelles Layout, und diese Vorschau ist eine Simulation dokumentierten Verhaltens, kein Screenshot.
Führt dieser Checker JavaScript aus?
Nein — und das ist Absicht. Der Checker ruft das statische HTML einmal ab, genau wie ein Plattform-Scraper, und Scraper führen ebenfalls kein JavaScript aus. Ein Tag, das ein Skript oder ein clientseitiges Framework hinzufügt, fehlt hier also aus demselben Grund, aus dem es bei Facebook, X, LinkedIn und Slack fehlen würde. Wenn Ihre Tags per JavaScript gerendert werden, müssen sie im serverseitig gerenderten HTML stehen, um fürs Teilen zu zählen.
Wie groß sollte og:image sein?
Verwenden Sie nach Möglichkeit 1200 × 630 px. Das ist Plattform-Empfehlung, kein formaler Standard — es ist das, was Facebook empfiehlt, und die Größe, um die herum die großen Cards bei X, LinkedIn und Slack gebaut sind. Halten Sie die Datei angemessen klein, verwenden Sie PNG oder JPEG (WebP-Unterstützung variiert je nach Scraper) und referenzieren Sie sie immer mit einer absoluten URL. Dieser Checker markiert Bilder unter 1200 × 630 und nennt Ihnen die echten Maße, die er aus der Datei gemessen hat.