Prüfen Sie Ihre Share Cards, bevor Sie posten
Zuletzt aktualisiert:
Eine Share Card ist die kleine Vorschau — ein Titel, eine Beschreibung und ein Bild —, die ein soziales Netzwerk oder eine Chat-App erstellt, wenn jemand einen Link zu Ihrer Seite einfügt. Für die meisten Menschen, die dieser Seite je begegnen, ist die Card die einzige Version, die sie sehen werden: Sie treffen sie mitten im Scrollen, beurteilen sie in etwa einer Sekunde und entscheiden, ob die Seite dahinter einen Tipp wert ist. Das Unangenehme daran: Card-Fehler sind still. Ihre Seite kann in Ihrem eigenen Browser perfekt aussehen, während ihre Card kein Bild zeigt, eine Schlagzeile vom letzten Monat oder eine Beschreibung, die mitten im Wort abgeschnitten ist — denn die Card wird nicht aus dem gebaut, was Sie auf dem Bildschirm sehen, sondern aus einer Handvoll Meta-Tags im Kopf der Seite, einmalig abgerufen von einem Scraper, den Sie nie beobachten. Führen Sie also, bevor Sie irgendetwas veröffentlichen, das Sie teilen wollen, die Entwurfs-URL durch den Open-Graph-Checker und betrachten Sie Ihre Seite so, wie Ihre Leser sie sehen werden: als vier kleine Cards.
Der Link ist die Werbung
Wenn ein Link in einen sozialen Feed oder einen Chatverlauf eingefügt wird, besucht kein Mensch zuerst Ihre Seite. Die Plattform schickt einen Scraper los — einen kleinen, ungeduldigen Crawler —, der die Seite einmal abruft und die Card aus den Meta-Tags baut, die er im Kopf findet. Niemand in dieser Kette sieht Ihr Layout, Ihre Typografie, Ihre sorgfältig abgestimmte Hero-Sektion oder den Screenshot, den Sie über der Falz platziert haben. Sie sehen genau drei Felder und ein Bild: og:title, og:description und og:image. Sind diese drei falsch, fehlen sie oder sind sie veraltet, dann ist Ihre Seite, soweit es Ihr Publikum betrifft, falsch, fehlend oder veraltet — die schöne Seite hinter der Card bekommt nie die Chance, den Eindruck zu korrigieren.
Die Card ist auch stur. Plattformen cachen diesen Abruf, meist an die exakte URL gebunden, sodass die erste Version, die ein Scraper baut, oft die Version ist, die wochen- oder monatelang weitergeteilt wird, lange nachdem Sie die Seite bearbeitet haben. Darum verdient eine Share Card denselben Respekt wie Werbemittel: Bei einem Beitrag, dessen ganzer Zweck das Teilen ist, ist der Link die Werbung, und die Meta-Tags sind der Text. Sie als Nachgedanken zu schreiben — oder einen Site-Generator sie mit dem Text füllen zu lassen, der zufällig in der Nähe steht — heißt, eine Kampagne zu fahren, deren Werbemittel niemand geprüft hat.
Was jede Plattform tatsächlich liest
Beginnen Sie mit der Basis. Facebook und LinkedIn lesen Open Graph: og:title, og:description, og:image, og:url und og:type, wie sie das Open-Graph-Protokoll definiert. Sind diese fünf vorhanden und vernünftig, sind die zwei größten beruflichen Teilen-Flächen abgedeckt. X liest zuerst seine eigenen Twitter-Card-Tags — twitter:card, twitter:title, twitter:description, twitter:image — und fällt auf die Open-Graph-Entsprechungen zurück, wenn die Twitter-Tags fehlen. Slack liest zuerst Open Graph, mit den Twitter-Card-Tags als Rückfall. Anders gesagt: Die Plattformen sind sich über die Zutaten einig und leicht uneins darüber, zu welchem Regal sie zuerst greifen.
Überall ist der letzte Ausweg derselbe: das schlichte <title>-Element und die Meta-Beschreibung, eingezogen, wenn weder Open Graph noch Twitter-Tags existieren. Dieser Rückfall ist wichtig dafür, wie Sie jeden Checker lesen, auch unseren. Wenn Ihnen ein Werkzeug einen Card-Titel zeigt, lautet die ehrliche Frage, woher der Wert stammt — aus einem dedizierten Tag, das Sie absichtlich geschrieben haben, oder aus einem Rückfall, gerettet aus einem Title-Element, das für eine Suchergebnisseite und ein Zeichenbudget geschrieben wurde, das Ihre Card nicht teilt. Ein Checker, der Rückfälle still ersetzt und sie als Tags präsentiert, lügt Sie durch Weglassen an — darum kennzeichnet der Open-Graph-Checker jeden Rückfall als Rückfall, statt vorzutäuschen, das Tag existiere.
Die Fehler, die Cards kaputt aussehen lassen
Der Klassiker ist das relative og:image. Das Tag sagt content="/images/share.png" — ein Pfad, keine URL —, und es funktioniert in Ihrem Browser, weil der Browser weiß, auf welcher Site er ist. Ein Scraper wird ihn nicht auflösen: Er will eine vollständige, absolute URL, die mit https:// beginnt, und wenn er sie nicht bekommt, baut er einfach eine Card ohne Bild, an der die Leser vorbeiscrollen, ohne je zu erfahren, was sie verpasst haben. Knapp dahinter folgt das Bild, das existiert, aber nicht passt: viel kleiner als die von den Plattformen empfohlenen 1200×630 Pixel, oder in einem Seitenverhältnis, das der mittige Zuschnitt in Unsinn verwandelt. Behandeln Sie 1200×630 als das, was es ist — weit verbreitete Plattformempfehlung, kein von irgendjemandem ratifizierter Standard —, aber ignorierte Empfehlung bedeutet trotzdem eine Card mit aus dem Bild herausgeschnittener Schlagzeile.
Der Rest ist leiser. Ein fehlendes twitter:card-Tag bedeutet, dass X auf eine kleine Summary Card zurückfällt — ein Vorschaubild neben dem Text —, selbst wenn Sie ein großes, schönes Bild geliefert und die volle summary_large_image-Behandlung erwartet haben. Leere Tag-Werte sind schlimmer als fehlende Tags: Ein og:title mit content="" löst den Rückfall nicht aus, es überschreibt ihn mit nichts. Und eine falsche og:url — die auf die Staging-Domain, die Startseite oder den Artikel von letzter Woche zeigt, wie es kopierte Vorlagen so oft tun — sagt jeder Plattform, die kanonische Seite sei woanders, und spaltet Shares, Zähler und Cache-Einträge von der Seite weg, die Sie tatsächlich veröffentlicht haben.
Warum die alte Card nach Ihrer Korrektur der Tags weiter erscheint
Sie haben die Tags korrigiert, neu deployt, den Link wieder eingefügt — und der alte Titel ist immer noch da und lächelt Sie an. Nichts ist kaputt. Jede Plattform cached die Card, die sie für Ihre URL gebaut hat, und dieser Cache beobachtet Ihre Site nicht auf Änderungen; aus Sicht der Plattform weiß sie bereits, wie Ihre Seite aussieht, und jede URL bei jedem Teilen erneut abzurufen wäre eine enorme Menge Crawling für sehr wenig Nutzen. Die veraltete Card ist kein Beweis dafür, dass Ihre Korrektur fehlgeschlagen ist. Sie ist der Beweis dafür, dass dem Cache noch nicht gesagt wurde, erneut hinzusehen — und bis dahin serviert jeder Kollege und jeder Leser, der den Link teilt, den alten Abruf erneut.
Also sagen Sie es ihm. Jede große Plattform bietet eine Möglichkeit, einen frischen Abruf einer einzelnen URL zu erzwingen: Der Facebook Sharing Debugger und der LinkedIn Post Inspector rufen die Seite erneut ab und zeigen Ihnen die Card, die sie neu gebaut haben — X bot historisch einen Card Validator für dieselbe Aufgabe an. Führen Sie Ihre URL nach jeder Tag-Korrektur durch das jeweils passende Werkzeug und bestätigen Sie die neue Card, bevor Sie den Beitrag ankündigen. Wo es kein Re-Scrape-Werkzeug gibt, ändert eine geänderte URL den Cache-Schlüssel: Ein angehängter Query-String wie ?v=2 lässt die Plattform den Link als einen behandeln, den sie noch nie gesehen hat — ein völlig respektabler Trick für ein einmaliges Teilen. Und behalten Sie etwas Geduld in Reserve — Caches können selbst nach einem Re-Scrape eine Weile brauchen, bis sie loslassen, also prüfen Sie, warten Sie und prüfen Sie noch einmal, bevor Sie anfangen, Tags zu bearbeiten, die schon korrekt waren.
Eine Zwei-Minuten-Routine vor dem Veröffentlichen
Machen Sie es zur Routine, nicht zur Untersuchung. Eins: Fügen Sie die Entwurfs-URL in den Open-Graph-Checker ein — die Staging- oder Vorschau-URL genügt, solange es die Seite ist, die die Scraper abrufen werden. Zwei: Bestätigen Sie, dass alle vier Cards — Facebook, X, LinkedIn und Slack — den Titel, die Beschreibung und das Bild zeigen, die Sie beabsichtigt haben, und notieren Sie alles, was als Rückfall gekennzeichnet ist, denn ein gewählter Rückfall ist in Ordnung und ein gestolperter Rückfall ist ein Tag, das darauf wartet, geschrieben zu werden. Drei: Bestätigen Sie, dass die Bild-URL absolut ist und das Bild selbst mindestens 1200×630 misst. Vier: Bestätigen Sie, dass twitter:card überall dort summary_large_image ist, wo Sie das große Format auf X wollen, und dass og:url die kanonische Seite nennt, die Sie gleich veröffentlichen.
Fünf: Veröffentlichen — und dann fügen Sie den Link einmal selbst irgendwo ein, um den ersten Abruf zu erzwingen, während Sie noch hinschauen, und sehen Sie sich die Card an, die zurückkommt. Ist sie veraltet oder falsch, lassen Sie sie mit dem plattformeigenen Werkzeug erneut scrapen, statt in Panik zu editieren. Zwei Minuten, fünf Schritte, und die Version Ihrer Seite, die die meisten Menschen je sehen werden, ist eine Version, die Sie tatsächlich freigegeben haben. Für die breitere Prüfung vor dem Veröffentlichen — TLS, Security Header, Weiterleitungen, der Rest der Routineprüfungen, die eine Seite vor dem Livegang verdient — führen Sie daneben den Website Health Check aus; die Cards sind die Haustür, aber nicht das ganze Haus.