Warum Plattformen Link-Vorschauen cachen

Du aktualisierst og:image und deployst. Facebook zeigt noch das alte Thumbnail. Jede große Plattform cached Link-Preview-Daten. Sie holen deine Seite nicht bei jedem Share neu. Wer versteht warum, fixt veraltete Vorschauen schneller.

Kurzantwort

Social Plattformen cachen Open-Graph-Tags und Bilder, damit Shares schnell sind und dein Server entlastet wird. Cache-Dauer variiert je Plattform und URL. Cache-Einträge löscht man nicht direkt - man überschreibt sie, indem man Tags fixt und pro Plattform ein Re-Scrape über das Debugger-Tool auslöst.

Was gecached wird

Beim ersten Teilen einer URL holt der Plattform-Crawler dein HTML und speichert:

• og:title (oder Fallback-Titel)
• og:description
• og:image-URL und die heruntergeladene Bilddatei
• Kanonische URL und Redirect-Pfad
• Response-Metadaten (letzter Fetch-Zeitpunkt)

Dieser Snapshot wird bei jedem weiteren Share derselben URL ausgeliefert, bis ein neuer Crawl ihn ersetzt.

Deine Website kontrolliert diesen Cache nicht. Er liegt auf den Servern und dem CDN der Plattform.

Warum Plattformen Vorschauen cachen

Geschwindigkeit

Preview bei jedem Share neu zu bauen, kostet 1-5 Sekunden pro Nachricht. Gecachte Vorschauen erscheinen sofort.

Serverlast

Beliebte URLs, tausendfach geteilt, würden deinen Server fluten, wenn jeder Share einen Crawl auslöst. Caching schützt deine Infrastruktur.

Konsistenz

Alle, die denselben Link teilen, sehen dieselbe Vorschau. Ohne Cache könnten parallele Shares während eines Crawls unterschiedliche Bilder zeigen.

Kosten

Crawler im großen Maßstab sind teuer. Caching reduziert redundante Abrufe.

Der Tradeoff: Live-Site und Social-Vorschau können stunden- oder tagelang auseinanderlaufen.

Wie lange hält der Cache?

Kein universelles TTL. Plattformen veröffentlichen keine exakten Ablaufzeiten.

High-Traffic-URLs können länger gecached bleiben, weil Plattformen selten neu crawlen.

Getrennte Caches pro Plattform

Caches werden nicht zwischen Plattformen geteilt. Facebook-Cache-Update aktualisiert nicht LinkedIn oder X.

Dein Seiten-Update
    ├── Facebook-Cache (separat) → Sharing Debugger
    ├── LinkedIn-Cache (separat) → Post Inspector
    ├── X-Cache (separat) → Card Validator
    ├── Slack-Cache (separat) → kein Tool
    └── iMessage-Cache (separat) → kein Tool

Nach OG-Bild-Änderung: Refresh-Tool jeder Plattform oder OpenGraph Check für alle Plattformen.

Was einen Cache-Refresh auslöst

Manueller Re-Scrape

Zuverlässigste Methode. Jede Plattform hat Debugger oder Inspector für neuen Crawl.

URL-Änderung

Plattformen behandeln https://beispiel.de/seite und https://beispiel.de/seite?v=2 als verschiedene Cache-Keys. Query-String = frische Vorschau. Siehe Open-Graph Cache Busting.

Bild-URL-Änderung

Neuer Dateiname oder versionierte URL für og:image erzwingt neuen Bild-Download, auch wenn die Seiten-URL gleich bleibt.

Gescheiterter erster Scrape

Scheiterte der erste Crawl (Timeout, 403), ersetzt ein späterer erfolgreicher Scrape den leeren Cache-Eintrag.

Was KEINEN Refresh auslöst

• Bearbeiten eines bestehenden Social-Media-Posts
• Tag-Änderung ohne Re-Scrape
• og:updated_time setzen (Plattformen ignorieren das für Cache-Invalidierung)
• Passives Warten (kein garantiertes Auto-Refresh)

Veröffentlichte Posts behalten alte Vorschauen

Cache-Updates betreffen nur künftige Shares. Ein Facebook-Post von letzter Woche behält seine Vorschau, auch wenn du heute scrapst.

Neue Vorschau in bestehender Unterhaltung zeigen:

• URL mit Cache-Buster teilen (?v=2)
• Neuen Post mit refreshtem URL erstellen
• Akzeptieren, dass alte Nachrichten nicht rückwirkend updaten

Als Publisher mit Cache arbeiten

Bilddateinamen versionieren

Statt og.jpg zu überschreiben: og-v2.jpg publishen und og:image anpassen. Plattformen holen die neue Datei beim Re-Scrape sofort.

Vor dem Teilen testen

URLs durch Plattform-Debugger und OpenGraph Check vor Kampagnen-Start. Cache-Probleme nach viralem Share sind härter zu fixen.

OG-Deploy-Prozess dokumentieren

Einfache Checkliste nach jedem Deploy:

1. Tags im Quelltext prüfen
2. Facebook Sharing Debugger scrapen
3. LinkedIn Post Inspector refreshen
4. X Card Validator validieren
5. Einen Test-Share pro Plattform

Cache-Lag in Launches einplanen

Kampagnen-Bild zum Launch-Zeitpunkt tauschen? Alle Plattformen 24 Stunden vor Go-Live scrapen.

FAQ

Social-Preview-Caching abschalten?

Nein. Caching ist in Link-Previews jeder großen Plattform eingebaut.

Aktualisiert eine Sitemap den Social-Cache?

Nein. Sitemaps betreffen Suchmaschinen-Indexierung, nicht Social-Preview-Caches.

Dev-Site OK, Production nicht?

Production-URL wurde früher mit alten oder fehlenden Tags gecached. Genau die Production-URL scrapen.

Cachen Plattformen 404-Seiten?

Ja. War die URL beim Teilen down, kann der Fehler gecached sein. Nach Live-Gang erneut scrapen.

Ist Cache der einzige Grund für falsche Vorschauen?

Nein. Fehlende Tags, blockierte Crawler und kaputte Bilder verursachen falsche Vorschauen auch ohne Cache. Cache-Probleme gelten, wenn Tags auf der Live-Seite stimmen, die Vorschau aber alt ist.

Zusammenhang mit CDN-Cache auf meiner Site?

Zwei Schichten: Dein CDN cached HTML (Fix: CDN purgen), die Plattform cached die extrahierte Vorschau (Fix: Re-Scrape). Beides kann unabhängig veralten.

Fazit

Social-Preview-Caching ist Absicht. Plattformen speichern deine OG-Daten für schnelles, günstiges Teilen. Veralteten Cache überschreibst du mit korrekten Live-Tags, versionierten Bild-URLs und Re-Scrape pro Plattform. Cache-Lag einplanen, vor dem Teilen testen, alte Posts erwarten nicht automatisch zu updaten.