Du hast og:image gefixt, Facebook zeigt noch das alte Bild. Re-Scraping half nicht, weil die Bild-URL gleich blieb. Cache Busting heißt: die URL ändern, damit Plattformen neuen Content sehen.
Kurzantwort
Zwei zuverlässige Methoden: Versions-Query an die Bild-URL (og.jpg?v=2) oder Datei umbenennen (og-v2.jpg). Für Page-Level-Cache: https://beispiel.de/seite?ref=launch statt nackter URL teilen. og:image in den Meta-Tags anpassen. Dann im Facebook Sharing Debugger neu scrapen.
Zwei Cache-Schichten
Veraltete Vorschauen betreffen zwei getrennte Caches:
| Schicht | Was gecached wird | Fix |
|---|---|---|
| Plattform-Cache (Facebook, LinkedIn) | Extrahierte OG-Tags und Bild | Re-Scrape oder URL cache-busten |
| Dein CDN / Server | HTML und Bilddateien | CDN purgen, Datei umbenennen |
Cache Busting zielt auf die Plattform-Schicht. Liefert dein CDN unter derselben URL noch die alte Datei, cachen Plattformen das alte Bild neu - trotz Scrape.
Methode 1: Versions-Query an der Bild-URL
Von:
<meta property="og:image" content="https://beispiel.de/og.jpg">Zu:
<meta property="og:image" content="https://beispiel.de/og.jpg?v=2">?v=2 lässt Plattformen das Bild neu laden. Der Server liefert weiter og.jpg, die URL ist technisch neu.
Wann Query-Strings gut passen
- Schneller Fix nach In-Place-Bildtausch
- CMS erschwert Dateinamen-Änderung
- Test, ob Cache das Problem ist
Wann Query-Strings Probleme machen
- Analytics zählt
?v=2als separate Seite (Traffic-Split) - Bei jedem Deploy neue Query erzeugt viele Cache-Einträge
- Wenige alte Crawler strippen Queries (heute selten)
Version bei jedem Bild-Update erhöhen: ?v=3, ?v=4.
Methode 2: Bilddatei umbenennen
Von:
https://beispiel.de/images/og.jpg
Zu:
https://beispiel.de/images/og-v2.jpg
og:image und twitter:image auf neuen Pfad setzen.
Warum Dateinamen langfristig besser sind
- Saubere kanonische URLs ohne Query-Rauschen
- CDN-Invalidierung explizit (neue Datei = neues Objekt)
- Keine Analytics-Fragmentierung
- Klare Versionshistorie im Asset-Ordner
Empfohlenes Muster für Production:
og-home-v1.jpg → og-home-v2.jpg → og-home-v3.jpg
Methode 3: Page-Level URL Busting für Shares
Debugger zeigt korrekte Daten, ein Share aber nicht? Modifizierte Seiten-URL teilen:
https://beispiel.de/blog/post?utm_campaign=linkedin
https://beispiel.de/blog/post?share=2026-06
Plattformen cachen nach vollem URL-String. Neue Query = neuer Cache-Eintrag.
Nachteile Page-Level Busting
- Splittet Social Proof über URL-Varianten
og:urlsoll weiter auf kanonische URL ohne Query zeigen- Kein Ersatz für sauberes
og:imageauf der kanonischen Seite
Für einmalige Marketing-Posts, nicht als Default-OG-Strategie.
Was beim Cache Busting aktualisieren
Bei Bild-URL-Änderung alle Referenzen anpassen:
<meta property="og:image" content="https://beispiel.de/og-v2.jpg"><meta name="twitter:image" content="https://beispiel.de/og-v2.jpg">Optional hilfreich:
<meta property="og:image:width" content="1200"><meta property="og:image:height" content="630">Danach mit OpenGraph Check testen.
Cache-Bust-Workflow Schritt für Schritt
- Bilddatei ersetzen oder URL mit Version aktualisieren
- Deployen, neue URL im Browser laden lassen
- Tag im Quelltext bestätigen
- Im Facebook Sharing Debugger scrapen
- Im LinkedIn Post Inspector refreshen
- Im Twitter Card Validator validieren
- In neuem Post oder Chat teilen und bestätigen
Wann Cache Busting NICHT nötig ist
- Erstes Teilen einer URL (noch kein Cache)
- Nur
og:titleoderog:descriptiongeändert (Text-Updates reichen oft mit Re-Scrape) - Debugger zeigt nach einem Scrape schon das neue Bild
Wann Cache Busting nötig ist
- Gleiche Bild-URL, anderer Dateiinhalt auf dem Server
- CDN liefert alte Bildbytes trotz HTML-Tag-Update
- Re-Scrape zeigt korrekte URL, aber altes Thumbnail
- Bild war beim ersten Scrape kaputt und ist jetzt gefixt (frische URL hilft)
Cache Busting pro Plattform
| Plattform | Bild-URL Bust | Page-URL Bust | Re-Scrape-Tool |
|---|---|---|---|
| Facebook / WhatsApp | Ja | Ja | Sharing Debugger |
| Ja | Ja | Post Inspector | |
| X (Twitter) | Ja | Ja | Card Validator |
| Slack | Ja | Ja | Kein Tool (neue Nachricht) |
| Discord | Ja | Ja | Kein Tool |
| iMessage | Ja | Ja | Kein Tool (neuer Chat) |
Meta-Plattformen teilen einen Cache. Bust auf Facebook deckt WhatsApp und Messenger ab.
Typische Fehler
Page-URL gebustet, og:image nicht
Seiten-URL ändert sich, og:image zeigt noch auf altes gecachtes Bild. Bild-URL in Meta-Tags anpassen.
twitter:image vergessen
X cached kaputtes twitter:image separat von og:image. Beides aktualisieren.
Zufällige Query pro User
?v=random bei jedem Request verhindert stabiles Caching und schadet Performance. Bewusste Versionsnummern nutzen.
Cache Busting statt Root Cause
Bild liefert 403 oder Tags fehlen? Kein URL-Trick hilft. Zuerst Zugriff und Tags fixen.
FAQ
Schadet ?v=2 dem SEO?
Nicht an der Bild-URL selbst. Query-Busting auf der kanonischen Seiten-URL in og:url vermeiden.
Timestamp als Version?
Technisch möglich (?t=1718123456), aber unschöne URLs und schwer trackbar. Inkrementelle Zahlen sind sauberer.
Bei jedem Deploy cache busten?
Nur bei OG-Bild- oder Titel-Änderungen. Routine-Deploys ohne Social-Tag-Änderung brauchen es nicht.
Hilft og:image:secure_url beim Cache?
Nein. Invalidiert Cache nicht. Neue URL schon.
CDN leeren = Plattform-Cache weg?
Nein. Beides nötig: CDN purgen und pro Plattform re-scrapen. Siehe Warum Plattformen Link-Vorschauen cachen.
Hash-basierte Namen besser als ?v=2?
Ja für Production. Beispiel: og-a8f3c2.jpg. Eindeutiger Dateiname, keine Query, klarer Cache-Break.
Fazit
Cache Busting fixt veraltete Vorschauen, wenn sich die Bilddatei änderte, die URL aber nicht. Datei umbenennen oder Versions-Query an og:image, alle Meta-Referenzen updaten, pro Plattform re-scrapen, frischen Share testen. Dateinamen-Versionierung für Production, Query-Strings für schnelle Fixes.
