Open-Graph-Bilder: Beim Teilen zählt Lesbarkeit, nicht Schönheit
TL;DR: Open-Graph-Bilder erhöhen die Klickrate nicht einfach, weil sie hübsch sind – sie wirken, wenn sie die geteilte URL lesbar, vertrauenswürdig und schnell erfassbar machen. Die meisten Teams behandeln sie immer noch als Canva-Export statt als festen Bestandteil des Seitenvertrags.
Dein Open-Graph-Bild ist kein Dekoelement. Es ist die Seite vor dem Klick.
Die falsche Frage lautet meist: „Welche Größe sollten meine Open-Graph-Bilder haben?“ Größe ist wichtig – aber die Frage ist zu klein gedacht. Social-Previews sind oft die erste Darstellung deiner Seite in fremden Feeds, Postfächern, Slack-Kanälen, Discord-Servern, iMessage-Threads oder privaten Gruppen.
Schlechte Teams liefern diese Oberfläche blind aus.
Bevor jemand klickt, sieht er eine Mischung aus Titel, Domain, Beschreibung und Bild. Dieses Bündel entscheidet, ob die URL sicher, relevant, aktuell und die Aufmerksamkeit wert wirkt. Ein fehlendes Bild signalisiert geringes Vertrauen. Ein generisches Stockfoto sagt „generischer Artikel“. Ein abgeschnittenes Logo zeigt, dass niemand die Share-Card vorm Launch geprüft hat.
Bild, Titel, Domain und Beschreibung sind die Seite vor der Seite – sie entscheiden, ob die URL Aufmerksamkeit verdient. Nur unter diesem Blickwinkel lohnt sich Entwicklungszeit für Open-Graph-Bilder.
„Tweets mit eingebetteter Card haben eine 40 % höhere Engagement-Rate.“
Vercel Engineering Blog, Einführung von @vercel/og
Die Zahl ist nützlich, darf aber kein falsches Versprechen werden. Sie bedeutet nicht, dass jede Website nach einem hübscheren Thumbnail 40 % mehr CTR bekommt. Sie zeigt: Cards verändern Verhalten. Die Vorschau gehört zur Distribution, nicht zur Kosmetik.
Bei mindnow sah ich Kunden, die Wochenlang Landingpages polierten, während ihre Previews abgeschnittene Logos, alte Kampagnen oder gar kein Bild zeigten. Ich habe denselben Fehler auf vadimkravcenko.com gemacht. seojuice.com löste das Problem, indem Social-Cards Teil des Seitentemplates wurden und nicht mehr Marketing-Nachgedanke waren (jahrelang lag ich da falsch).
Was die Top-3-Suchtreffer sagen – und was sie auslassen
Die aktuellen Suchresultate teilen das Thema in drei Antworten auf: Protokoll-Docs, Design-Tipps und Dev-Tooling. Alles hilfreich, aber keiner erklärt das komplette Betriebsmodell.
| SERP-Treffer | Was er erklärt | Was fehlt |
|---|---|---|
| ogp.me, offizielles Open-Graph-Protokoll | Definiert das Protokoll und die Kern-Tags: og:title, og:type, og:image, og:url u. a. |
Erklärt, was der Tag ist, nicht, wie er Klicks verdient. Keine Design-Hierarchie, QA-Workflow, CTR-Rahmen oder Caching-Hinweise. |
| Buffer, Open Graph Image Best Practices | Praktische Design-Hinweise: Dimensionen, Kontrast, Branding, lesbarer Text, Plattform-Previews, Komposition. | Stark bei Creative Direction, schwächer bei Umsetzung. Geht nicht tief genug auf dynamische Bildgenerierung, Templates oder Crawler-Speed ein. |
| Vercel, OG-Image-Generation-Docs | Zeigt, wie man dynamische OG-Bilder mit @vercel/og, Templates, Route-Handlern und 1200×630-Ausgabe erzeugt. |
Perfekt für Entwickler, die Generation schon wollen. Weniger hilfreich für Marketer und Gründer, die entscheiden müssen, welche Seiten eigene Cards brauchen und wie man Erfolg misst. |
Die Lücke ist der Workflow: Botschaft, Markup, Generierung, QA, Messung. OG-Bilder heben die CTR, wenn sie vor dem Klick Unsicherheit abbauen. Dafür reicht kein exportiertes Rechteck.
Was ein Open-Graph-Bild wirklich ist (und welche Tags es steuern)
Ein Open-Graph-Bild ist das Bild, das eine Plattform nutzt, um eine Vorschaukarte für deine URL zu bauen. Die Seite enthält Metadaten im <head>. Ein Crawler ruft die Seite ab, liest die Metadaten, holt das Bild-URL und rendert die Card.
„og:image – Eine Bild-URL, die dein Objekt im Graph repräsentiert.“
Open-Graph-Protokoll-Spezifikation, ogp.me
Der Satz ist kurz, trägt aber alles. Das Bild repräsentiert das Objekt: Beim Artikel den Artikel, bei der Produktseite das Produkt/Ergebnis, bei der Marketplace-Anzeige das Listing, bei der Doku die Dokument-Kontext.
Eine Basis-Implementierung sieht so aus:
<meta property="og:title" content="Open-Graph-Bilder steigern deine Klickrate">
<meta property="og:description" content="So designst, generierst und testest du Social-Preview-Bilder, die Klicks verdienen.">
<meta property="og:image" content="https://example.com/og/open-graph-images.png">
<meta property="og:url" content="https://example.com/open-graph-images-boost-your-click-through-rates">
<meta property="og:type" content="article">
Die Kern-Tags sind simpel. og:title benennt das Objekt. og:description erklärt den Wert. og:image liefert das Visuelle. og:url gibt die kanonische Adresse. og:type sagt der Plattform, welchen Objekttyp sie rendert.
Twitter/X hat eigene Card-Tags, aber Open Graph übernimmt viel Arbeit.
„Twitter erlaubt es, Open-Graph-<meta>-Tags als Ersatz zu nutzen.“
Adam Coti, CSS-Tricks
Eigene twitter:image- und twitter:card-Tags sind sinnvoll, wenn die Plattform anderen Zuschnitt, Card-Stil oder Text braucht. Behandle sie als Overrides, nicht als separate Strategie.
Die 1200×630-Regel existiert, weil Feeds gnadenlos beschneiden
Leute platzieren Logos, Gesichter oder wichtigen Text immer noch am Rand und wundern sich, wenn LinkedIn sie abschneidet. Facebook komprimiert, Slack zeigt kleiner, Discord meint, der Titel reicht. Feeds sind keine höflichen Layout-Engines.
Der praktische Standard ist aus gutem Grund langweilig:
- Empfohlene Größe: 1200×630 px.
- Seitenverhältnis: etwa 1,91:1.
- Minimales Fallback: 600×315 – aber nicht dafür designen.
- Wichtige Elemente weg von den Rändern.
- Dateigröße klein halten.
„Verwende Bilder mit mindestens 1200 × 630 px für die beste Darstellung auf hochauflösenden Geräten.“
Meta-Sharing-Dokumentation
Meta formuliert die Crop-Regel klar:
„Halte das Seitenverhältnis möglichst bei 1,91:1, damit das Bild im Feed ohne Beschnitt angezeigt wird.“
Meta-Sharing-Dokumentation
CSS-Tricks liefert die Designer-Version:
„Mindestens 600 × 315 px, aber 1200 × 630 oder größer ist besser (bis 5 MB).“
Adam Coti, CSS-Tricks
Die dahinterliegende Regel: Gestalte eine zentrale Safe-Zone. Überschrift, Produkt-UI, Gesicht, Chart oder Logo müssen Zuschnitt, Kompression und kleine Previews überleben. Wenn deine Card auf einem Miniecken-Label basiert, scheitert sie genau dort, wo Links geteilt werden.
Der Safe-Zone-Test
Öffne das Bild. Bedecke 10 % jeder Kante mit Händen oder Browser-Overlay. Ergibt die Card noch Sinn, überlebt sie echte Feeds. Verschwindet Logo, Titel, Gesicht oder CTA, bau neu.
Der Test wirkt albern, bis er das Problem findet, das live gegangen wäre. Dann wird er Workflow-Pflicht.
Die Card soll den Klick verkaufen, nicht den Titel wiederholen
Die meisten OG-Bilder scheitern, weil sie das H1 auf einen farbigen Hintergrund kopieren. Nicht immer schlimm, aber vergeudete Fläche.
Der Titel steht ohnehin in der Preview. Ihn im Bild zu wiederholen kann helfen, wenn Plattformen Text kürzen, sollte aber nicht alles sein. Ein gutes OG-Bild tut eines von vier Dingen:
- Macht das Versprechen konkret. Zeigt, was der Leser versteht, löst, vergleicht oder vermeidet.
- Zeigt Beweis. Chart, Zahl, Screenshot, Vorher-Nachher oder sichtbares Ergebnis.
- Schafft Emotion. Gründer-Essays, Meinungsstücke, Stories brauchen oft menschliches Signal.
- Erzeugt Wiedererkennung. Serien, Reports, Produkt-Updates profitieren von konsistentem Visual-System.
Für technischen SEO-Artikel: Vorher-/Nachher-Card oder Crawler-Diagramm. Für Produktseite: Outcome statt nur Logo. Für Datenstudie: überraschendste Zahl. Für Gründer-Essay: Person oder prägender Satz.
Keine Fake-Buttons ins OG-Bild. Ein scheinbarer „Read more“-Button ist nicht klickbar und untergräbt Vertrauen. Das Bild soll Sicherheit schaffen, nicht Verwirrung.
Eine gute Card beantwortet schnell die Vor-Klick-Frage: „Was ist das und warum interessiert mich das?“ Wenn die Antwort in einer Sekunde sichtbar ist, tut die Card ihren Job.
Statische Templates reichen, bis deine Site mehr als einen Seitentyp hat
Ein statisches Default-Bild genügt für kleine Firmen-Sites. Nutze eine saubere Marken-Card und erstelle individuelle Cards für Homepage, Pricing, Kern-Landings und große Kampagnen. Für viele Teams reicht das.
Das Problem beginnt, wenn jeder Seitentyp andere Intention hat. Blogs, Marketplaces, SaaS-Apps, Doku-Sites und programmatic SEO brauchen Templates; sonst driften die Previews von der Seite weg.
| Site-Typ | Gute OG-Vorgehensweise |
|---|---|
| Kleine Firmen-Site | Ein Default-Bild plus individuelle Bilder für Kern-Landings. |
| Blog | Template mit Post-Titel, Kategorie, Brand-Marke. |
| SaaS-Feature-Seiten | Benefit-Template mit Produkt-UI oder Icon-System. |
| Marketplace | Dynamische Card mit Item-Name, Foto, Ort oder Preis. |
| Dokumentation | Template mit Doku-Titel, Produktbereich und ggf. Version. |
„Empfohlene OG-Bildgröße: 1200×630 px“
Vercel @vercel/og Dokumentation
Dynamische Generierung ist kein Dev-Ego-Move. Sie verhindert veraltete Cards, vergessene Kampagnen-Grafiken, unpassende Artikel-Titel und manuellen Export-Aufwand, den nach dem Launch niemand übernimmt.
Die besten Template-Systeme ziehen aus derselben Quelle wie die Seite: Titel, Kategorie, Autor, Hero-Bild, Produktname, Ort, Preis oder Version. So bleibt die Preview an die echte URL gebunden (nicht nur an die Homepage).
Dynamische OG-Generierung hat eine Pflicht: schnelle First Response
Sie kann Skalierung lösen, aber auch langsamere, fragilere Previews schaffen. Social-Bots sind ungeduldig – Caches klebrig – Debugger lassen Produktionsschmerz harmlos wirken.
Das übliche schlechte Setup: Headless-Browser startet, lädt Remote-Fonts und Assets, braucht Sekunden, Crawler läuft in Timeout oder cached Fehler. Team gibt LinkedIn/Facebook die Schuld. Manchmal spinnt die Plattform, oft war der Generator langsam.
„Vercel OG ist im P99 5× schneller (4,96 s → 0,99 s) und im P90 5,3× schneller (4 s → 0,75 s).“
Vercel Engineering Blog, Einführung von @vercel/og
Das ist keine Vercel-Werbung. Die Regel gilt unabhängig vom Anbieter: Der Stack, der die Card erzeugt, muss deterministisch, gecacht und schnell genug für Crawler sein.
- Generierte Bilder nach erstem Render cachen.
- Stabile Bild-URLs nutzen, außer gezieltes Cache-Busting.
- Keine auth-geschützten Assets, kurzlebigen Signed-URLs oder blockierten Fonts.
- Absolute HTTPS-URLs in
og:imageliefern. - Korrekten Content-Type zurückgeben.
- Preview-Bots nicht in
robots.txt, WAF oder Hotlink-Schutz blockieren. - Templates robust gestalten bei langem Titel oder fehlendem Bild.
Wenn die erste Crawler-Anfrage scheitert, sehen alle stunden- oder tagelang die kaputte Card. Geschwindigkeit gehört also zur CTR-Diskussion.
Die QA-Checkliste, die 90 % der OG-Fehler abfängt
Hier verbessern sich Teams am schnellsten. Du brauchst kein Komitee, nur eine Checkliste und Verantwortung vor dem Go-Live.
- Quelltext prüfen und sicherstellen, dass die Tags serverseitig gerendert werden. Verlass dich nicht auf den Inspector nach JavaScript-Änderungen.
- Sicherstellen, dass
og:imageeine absolute HTTPS-URL ist. Relative Pfade und HTTP-Bilder verursachen Fehler. - Bild-URL in privatem Fenster öffnen. Wenn Cookies nötig sind, sehen Crawler es nicht.
- Dimensionen prüfen. Ziel: 1200×630 oder nahe 1,91:1.
- Datei muss ohne Redirect-Ketten schnell laden. Schönes Bild mit 4 s Antwortzeit ist unzuverlässig.
- Seite im Facebook Sharing Debugger testen. Nach Fixes neu scrapen.
- LinkedIn Post Inspector testen. LinkedIn-Cache wirkt oft unsterblich.
- URL in Slack oder Discord einfügen. Private Shares starten viele echte Klicks.
- Bild nach Cache-Busting erneut prüfen. Hat sich das Template geändert, muss die Plattform das neue Asset holen können.
- Nach Titel-, Template-, CMS- oder Routing-Änderungen re-testen. Previews brechen leise.
Punkt 1 ist entscheidender als gedacht. Wenn Meta-Tags erst nach Client-JS erscheinen, sehen manche Crawler die Card nie. Gleiches Problem wie im SPA-SEO-Artikel: Was Menschen nach Hydration sehen ≠ was Crawler beim ersten Byte erhalten.
seojuice.com behandelt Metadaten und Preview-Readiness als Teil der Seiten-Health, weil Menschen vergessen, jede URL nach jedem Template-Change zu prüfen. Manuelles QA fängt Kampagnen-Risiken ab. Automatisiertes QA fängt schleichende Drift.
So misst du, ob OG-Bilder die CTR verbessert haben
Messen ist chaotisch. Social-CTR wird von privaten Shares, Dark Social, Plattform-Lücken, Copy-Changes, Timing, Audience-Qualität und Referrer-Weitergabe verzerrt.
Tu nicht so, als wäre das ein Labortest, es sei denn, du kontrollierst die Share-Oberfläche. Verfolge stattdessen Richtungstrends.
- Klicks aus Social- und Messaging-Referrern vor/nach Template-Rollout vergleichen.
- UTM-getaggte Kampagnen nutzen, wo Copy und Ziel feststehen.
- Landing-Page-Sessions aus LinkedIn, Facebook, X, Reddit, Slack und Communities beobachten.
- Share-zu-Klick-Ratio in Newslettern oder Communities messen, wenn Post-Copy stabil bleibt.
- Qualitatives Signal: Weniger „Link-Preview kaputt“-Meldungen von Sales, Support, Partnern oder Community.
OG-Bild ist selten die einzige Variable. Headline, Thema, Audience, Timing, Post-Copy, Absender, Plattform zählen ebenfalls. Doch kaputte Previews bremsen Distribution, bevor Analytics verlorene Klicks sieht. Fixen entfernt Reibung für jeden künftigen Share.
Der langweilige Standard, der die meisten OG-Bilder schlägt
Wenn du nichts anderes tust, liefere eine Default-Card, die schwer kaputtgeht.
- 1200×630 px.
- Eine klare visuelle Idee.
- Sechs bis zehn gut lesbare Wörter.
- Kleines, aber sichtbares Logo.
- Hoher Kontrast.
- Zentrale Safe-Zone.
- Template an Seitentyp gebunden.
- Schnelle statische oder gecachte URL.
Dieses Rezept schlägt die meisten OG-Bilder, weil viele Karten zu generisch, zu voll, zu langsam oder ungetestet sind. Frage nicht „Ist das Bild hübsch?“ Frage: Macht es die URL klickwürdig?
Open-Graph-Bilder heben die CTR, wenn sie die Vor-Klick-Frage schneller beantworten als der umgebende Feed.
FAQ
Beeinflussen OG-Bilder direkt das Google-Ranking?
Nein. OG-Bilder dienen vor allem Social- und Messaging-Previews, sie sind kein direkter Google-Ranking-Faktor. Sie beeinflussen aber Distribution: Bessere Previews bringen mehr Klicks und Shares, was entscheidet, wie weit eine URL reist, bevor Suche ins Spiel kommt.
Welche Größe sollten OG-Bilder haben?
Nutze 1200×630 px als Standard. Das entspricht der gängigen 1,91:1-Card und bietet genug Auflösung für High-DPI-Screens. 600×315 kann als Fallback funktionieren, doch fürs Minimum zu designen heißt hässliche Previews riskieren.
Soll jede Seite ein eigenes OG-Bild haben?
Nicht jede Seite braucht handgezeichnete Kunst. Jede indexier- oder teilbare Seite braucht aber eine relevante Preview. Für kleine Sites reicht ein starkes Default plus wenige Custom-Cards. Für Blogs, Marketplaces, SaaS-Seiten und Doku: Templates nach Seitentyp.
Kann ich dasselbe Bild für Open Graph und Twitter/X verwenden?
Oft ja. OG-Tags können als Fallback für Twitter-Cards dienen. Nutze dedizierte Twitter-Tags, wenn du anderen Zuschnitt, Card-Stil oder Text brauchst. Beide testen, da Plattformen unterschiedlich rendern.
Warum zeigt meine aktualisierte OG-Grafik noch die alte Version?
Plattform-Caches sind hartnäckig. Facebook, LinkedIn, Slack, Discord & Co. speichern das erste geladene Bild. Nutze Debugger/Inspector der Plattform, prüfe, ob die neue Bild-URL korrekt liefert, und erwäge Cache-Bust, wenn das Visual sofort wechseln muss.
Automatisierte Checks für kaputte Social-Previews gefällig?
seojuice.com prüft Seiten-Health-Signale, die Teams manuell vergessen, inklusive Metadaten-Fehlern, die Previews zerstören. Wenn du willst, dass OG-Bilder Teil des Seitenvertrags und kein Launch-Tag-Dekor sind, starte mit automatisierten Checks und repariere die URLs, die dich in fremden Feeds blamieren würden.
Read More
- Optimierung für Zero-Click-Suchen: Zitiert werden statt nur geklickt
- Welche SEO-Optimierungen Sie automatisieren sollten (und welche Sie besser manuell belassen)
- So findest du deine ersten Kunden als SEO-Freelancer
- Wie schlecht gestaltete Exit-Umfragen Ihre SaaS-Churn-Daten verfälschen
- SEO-Berichtsvorlage (2026): Kostenloser Google-Sheets- & PDF-Download
- So verfolgen Sie, wann ChatGPT, Perplexity und Claude Ihre Marke zitieren
no credit card required