Beispiel: Das CMS ist korrigiert, der Audit sieht weiterhin den alten Fehler
Die Redaktion entfernt ein noindex, aber Besucher ohne Anmeldung erhalten weiterhin die alte HTML-Fassung. Häufig sehen eingeloggte Redakteure eine ungecachte Vorschau, während der öffentliche Abruf aus einem Seiten- oder CDN-Cache stammt. Dadurch wirkt die Änderung im Backend erfolgreicher, als sie öffentlich ist.
Die auslösende Stelle finden
Vergleichen Sie einen frischen öffentlichen Abruf mit der Vorschau und kontrollieren Sie Cache-Hit-, Age- oder herstellerspezifische Header. Prüfen Sie dabei dieselbe URL, Sprache und Gerätekonfiguration. Abweichende Parameter können einen anderen Cacheeintrag treffen und dadurch eine scheinbare Korrektur vortäuschen.
Einen begrenzten Fix prüfen
Leeren Sie gezielt die betroffene Seite und gegebenenfalls die dazugehörige CDN-Variante. Korrigieren Sie anschließend die Invalidierung beim Veröffentlichen, wenn Änderungen regelmäßig zu spät sichtbar werden. Bei sprachabhängigen oder personalisierten Antworten muss der Cache-Schlüssel die tatsächlich relevante Unterscheidung berücksichtigen.
Prüfen Sie die Ausgabe nach dem ersten Abruf und nach einem weiteren Cachetreffer. Beide müssen dieselben gewünschten Meta-Daten liefern. Bleibt nur der erste Aufruf korrekt, liegt die Ursache eher im gespeicherten Objekt oder Cache-Schlüssel als im Seiteninhalt.
Symptome im Audit
- Crawler sieht andere Header als Browser
- alte Canonicals oder Sitemaps bleiben sichtbar
- Fehler verschwindet nach Cache-Bypass
So prüfen Sie die Ursache
- 1. Header mit und ohne Cache prüfen
- 2. CDN-Regeln für HTML, XML und Assets vergleichen
- 3. nach Deploy gezielt Purge auslösen
Fix-Route
- Cache-Regeln nach Dateityp trennen
- HTML nicht unkontrolliert minifizieren
- Sitemap/robots.txt vom aggressiven Cache ausnehmen