Cache-Fallen nach dem Deploy: veraltete Seiten finden

Warum die neue Version live ist und Besucher die alte sehen

Ein Deploy fühlt sich an wie ein Schalter: vorher alt, nachher neu. Technisch beschreibt er aber nur den Zustand des Ursprungsservers. Alles, was zwischen diesem Server und dem Browser liegt, arbeitet nach eigenen Regeln weiter - und diese Regeln sind darauf ausgelegt, eine einmal gespeicherte Antwort möglichst lange wiederzuverwenden. Genau das ist der Zweck eines Caches. In einer Auswertung von Millionen Antworten trugen am Desktop 62,2 Prozent eine max-age-Angabe, 16,5 Prozent no-cache und 9,6 Prozent no-store (HTTP Archive Web Almanac 2021). Die Mehrheit der Antworten im Web sagt also aktiv: Behalte mich eine Weile.

Der entscheidende Punkt steht in der Spezifikation selbst. Der HTTP-Caching-Standard kennt keinen Weg, mit dem ein Server eine bereits gespeicherte Antwort aus einem fremden Cache entfernen könnte (RFC 9111). Vorgesehen ist eine Entwertung nur als Nebenwirkung: Eine erfolgreiche Anfrage mit einer verändernden Methode auf dieselbe Adresse macht die gespeicherte Antwort ungültig (RFC 9111). Ein Deploy ist aber keine solche Anfrage. Er verändert Dateien auf dem Server, nicht den Speicher im Browser eines Besuchers, der die Seite vor zwei Stunden geöffnet hat. Wer einen Deploy als abgeschlossen betrachtet, sobald der Ursprungsserver umgestellt ist, hat die zweite Hälfte der Strecke übersehen.

Die fünf Schichten zwischen Deploy und Besucher

Zwischen dem Moment, in dem die neue Version auf dem Ursprungsserver liegt, und dem Moment, in dem ein Mensch sie sieht, liegen typischerweise fünf Speicherorte. Sie unterscheiden sich nicht nur technisch, sondern vor allem darin, wer sie räumen kann und wie lange sie sich sonst halten. Diese Zuständigkeit ist der eigentliche Kern des Problems: Der Betrieb kann den Reverse Proxy neu starten und im CDN eine Purge-Anfrage auslösen, aber niemand im Unternehmen kann den Speicher eines fremden Geräts anfassen.

Die Tabelle erklärt, warum sich Cache-Fehler so schwer nachstellen lassen. Ein Kollege im Büro sieht die neue Fassung, weil sein CDN-Knoten bereits aktualisiert wurde; eine Kundin in einer anderen Region sieht die alte, weil ihr Knoten noch eine gültige Kopie hält. Beide Beobachtungen sind für sich korrekt. Wer solche Unterschiede systematisch erfassen möchte, braucht Prüfpunkte an mehreren Orten - der Beitrag zum Monitoring von mehreren Standorten aus beschreibt das Vorgehen. Und weil das Räumen der Schichten auf mehrere Personen verteilt ist, gehört die Frage, wer welchen Cache leeren darf, in dieselbe Ordnung wie die übrigen Zugriffsrechte im Monitoring-Team.

Was die Zahlen über Cache-Header im Web sagen

Die Verteilung der Cache-Direktiven im offenen Web zeigt, wie unterschiedlich die Praxis aussieht. Neben max-age mit 62,2 Prozent kamen am Desktop public auf 29,7 Prozent, must-revalidate auf 12,2 Prozent, private auf 9,5 Prozent und immutable auf lediglich 3,5 Prozent der Antworten (HTTP Archive Web Almanac 2021). Auch die Direktiven, die für Deploys besonders nützlich wären, bleiben selten: s-maxage, mit der sich die Gültigkeit im CDN getrennt von der im Browser steuern lässt, stand auf 1,6 Prozent der Antworten, stale-while-revalidate auf 2,3 Prozent (HTTP Archive Web Almanac 2021). Letztere erlaubt es, eine abgelaufene Antwort noch auszuliefern und im Hintergrund zu erneuern (RFC 5861) - hilfreich für die Ladezeit, aber ein zusätzlicher Grund dafür, dass alte Inhalte länger sichtbar bleiben als erwartet.

Der zweite Befund betrifft die Länge der Gültigkeit. In einer Auswertung mobiler Seiten aus dem Jahr 2020 hatten 60,2 Prozent der Ressourcen eine Gültigkeitsdauer, die im Verhältnis zum tatsächlichen Alter des Inhalts zu kurz angesetzt war; der mittlere Abstand zwischen Gültigkeit und Alter lag bei 25 Tagen (HTTP Archive Web Almanac 2020). Zu kurze Gültigkeiten kosten Ladezeit, zu lange kosten Aktualität. Die Gegenrichtung ist ebenfalls belegt: In der Auswertung von 2019 trugen 1,1 Prozent der Antworten max-age=0 ohne no-store (HTTP Archive Web Almanac) - sie dürfen gespeichert werden, aber vor jeder Wiederverwendung erneut geprüft. Und der Vary-Header, der festlegt, welche Merkmale einer Anfrage eine eigene Variante ergeben, stand nur auf 46,25 Prozent der geprüften Anfragen (HTTP Archive Web Almanac 2021). Fehlt er, kann ein gemeinsamer Cache die falsche Sprach- oder Formatvariante an den nächsten Besucher weiterreichen.

immutable: der Dateiname ist die eigentliche Invalidierung

Für versionierte Dateien - also solche, deren Name einen Fingerabdruck des Inhalts enthält - gilt die verbreitete Empfehlung, sie ein Jahr lang gültig zu halten und zusätzlich als unveränderlich zu kennzeichnen: Cache-Control: max-age=31536000, immutable. Für HTML dagegen wird no-cache empfohlen, damit der Browser vor jeder Wiederverwendung nachfragt (web.dev). Diese Trennung ist sinnvoll und weit verbreitet. Sie hat aber eine Bedingung, die im Alltag gern verloren geht: Sie trägt nur, solange sich der Dateiname bei jeder inhaltlichen Änderung tatsächlich ändert.

Was immutable bedeutet, steht ausdrücklich in der zugehörigen Spezifikation: Die Antwort wird sich während ihrer Gültigkeitsdauer nicht ändern, und der Client soll auch dann keine bedingte Anfrage stellen, wenn die Nutzerin die Seite neu lädt (RFC 8246). Genau das ist der Zweck der Direktive - und genau deshalb ist sie die unversöhnlichste Schicht im Stapel. Wird eine Datei unter demselben Namen mit neuem Inhalt ausgeliefert, hilft weder gewöhnliches noch hartes Neuladen. Die alte Fassung bleibt bis zum Ablauf der Gültigkeit auf dem Gerät, im ungünstigen Fall ein Jahr lang.

Dieselbe Logik gilt außerhalb des Browsers. Der Rendering-Dienst der Google-Suche hält Ressourcen in einem eigenen Speicher und richtet sich dabei nicht nach den üblichen Cache-Headern; die Dokumentation empfiehlt deshalb ausdrücklich, Dateinamen mit einem Inhalts-Fingerabdruck zu versehen (Google Search Central). Eine veraltete Skript- oder Stildatei kann dort also weiterwirken, lange nachdem sie im Browser ersetzt wurde. Wie folgenreich ein einzelner falsch ausgelieferter Bestandteil für die Sichtbarkeit werden kann, zeigt der Beitrag zu einem versehentlich mitgelieferten noindex im Deploy.

Der Service Worker, der eine tote Datei behält

Ein Service Worker ist ein Skript, das der Browser zwischen Seite und Netz stellt. Er beantwortet Anfragen aus einem eigenen Speicher und ist damit die einzige Schicht, die dem Netz vollständig ausweichen kann. Lange war das ein Randthema; in einer Erhebung von 2025 stieg der Anteil der Websites mit Service Worker jedoch auf 19,2 Prozent, bei den 10.000 meistbesuchten Domains auf 29,4 Prozent am Desktop und 27,5 Prozent mobil (HTTP Archive Web Almanac 2025). Ein erheblicher Teil dieses Zuwachses geht auf Skripte zurück, die über Tag-Verwaltungen mitgeliefert werden - also auf eine Schicht, die im Betrieb häufig gar nicht als Cache wahrgenommen wird.

Entscheidend für Deploys ist der Lebenszyklus. Findet der Browser eine geänderte Service-Worker-Datei, installiert er sie, lässt sie danach aber warten, bis keine Seite mehr vom bisherigen Worker gesteuert wird (W3C Service Workers). Ein einziger offener Tab genügt, damit die alte Fassung weiterläuft. Die Anweisung, diesen Wartezustand zu überspringen, ist inzwischen weit verbreitet: In einer Auswertung von 2025 setzten sie 68 Prozent der Desktop-Seiten mit Service Worker und 63 Prozent der mobilen ein (HTTP Archive Web Almanac). Verlassen kann sich der Betrieb darauf im Einzelfall trotzdem nicht - fehlt die Anweisung, bleibt es beim Warten, bis der letzte Tab geschlossen wird. Immerhin holt der Browser die Worker-Datei beim nächsten Aufruf am Zwischenspeicher vorbei, sobald die letzte Prüfung mehr als 24 Stunden zurückliegt, weil längere Gültigkeitsangaben für dieses eine Skript nach Spezifikation nicht wirksam werden (W3C Service Workers).

Auch die gewählte Laufzeitstrategie entscheidet mit. In einer Auswertung der am Desktop eingesetzten Laufzeitstrategien entfielen 31,72 Prozent auf den Ansatz, zuerst den Speicher zu befragen, fast gleichauf mit dem netzzuerst-Ansatz mit 31,52 Prozent, gefolgt von der Kombination aus abgelaufener Auslieferung und Nacherneuerung mit 27,03 Prozent (HTTP Archive Web Almanac 2021). Wer zuerst den Speicher befragt, liefert die gespeicherte Antwort aus, ohne das Netz überhaupt zu fragen - für Schriftarten sinnvoll, für Inhalte, die sich mit dem Deploy ändern, riskant.

HTML mit langer Gültigkeit: veraltete Preise und Rechtstexte

HTML ist der Einstiegspunkt. Es entscheidet, auf welche Dateinamen verwiesen wird, welche Preise sichtbar sind und welcher Rechtstext gilt. In der Auswertung von 2021 galten 23,4 Prozent der HTML-Antworten als nicht zwischenspeicherbar (HTTP Archive Web Almanac) - der weitaus größere Teil landet also im Speicher. Wo HTML mit einer Gültigkeit von einem Tag ausgeliefert wird, sieht ein wiederkehrender Besucher bis zu 24 Stunden nach dem Deploy die alte Seite, ohne dass ein einziger Fehler protokolliert würde. Die empfohlene Einstellung für Adressen ohne Fingerabdruck lautet deshalb no-cache: gespeichert werden darf, wiederverwendet erst nach Rückfrage (web.dev). Bei einem Relaunch verschärft sich das, weil viele Adressen gleichzeitig wechseln - den Ablauf ordnet der Beitrag zur Überwachung einer Website-Migration ein.

Wirtschaftlich und rechtlich sind veraltete Seiten mehr als ein Schönheitsfehler. Die Preisangabenverordnung verlangt, dass der Gesamtpreis richtig und vollständig angegeben wird (PAngV); ein alter Preis aus dem Cache ist eine unrichtige Angabe über den Preis und damit als irreführende geschäftliche Handlung angreifbar (UWG). Ebenso müssen die Informationen zur Datenverarbeitung dem tatsächlichen Stand entsprechen (Art. 13 DSGVO) - eine Datenschutzerklärung, die seit dem letzten Deploy überholt ist, aber weiter aus dem Cache ausgeliefert wird, erfüllt diese Pflicht nur auf dem Papier. Dasselbe gilt für Angaben im Impressum, für Widerrufsbelehrungen und für Versandkosten.

Cache leeren ist nicht Cache umgehen

Bei der Fehlersuche werden zwei Dinge gern verwechselt. Einen Cache zu leeren heißt, gespeicherte Antworten zu verwerfen, sodass die nächste Anfrage neu beantwortet wird. Einen Cache zu umgehen heißt, für die eigene Prüfung an ihm vorbeizugehen, ohne seinen Inhalt anzutasten. Für die Diagnose ist der Unterschied entscheidend: Wer leert, zerstört den Beweis. Nach einem harten Neuladen sieht die Seite korrekt aus - die Frage, was der nächste Besucher bekommt, ist damit aber nicht beantwortet, sondern nur unbeantwortbar geworden.

Für die Diagnose lohnt der Blick auf zwei Angaben in der Antwort. Der Age-Header schätzt die Zeit in Sekunden, die seit der Erzeugung oder letzten Bestätigung der Antwort am Ursprungsserver vergangen ist (RFC 9111); ein Wert nahe der eingestellten Gültigkeit deutet auf einen Knoten hin, der kurz vor der Erneuerung steht. Und viele Zwischenschichten setzen einen eigenen Statushinweis, aus dem hervorgeht, ob die Antwort aus dem Speicher kam. Beides zusammen trennt zuverlässiger zwischen einem hängenden CDN-Knoten und einem falsch gebauten Artefakt als jedes wiederholte Neuladen. Ergänzend gehört geprüft, ob die Seite überhaupt den erwarteten Statuscode meldet - eine als Fehlerseite ausgelieferte Antwort mit Status 200 ist ein eigenes Fehlerbild, das der Beitrag zu Soft 404 und falschen Statuscodes beschreibt.

Nach jedem Deploy prüfen: ein Vorgehen in sieben Schritten

Aus den beschriebenen Fehlerbildern lässt sich ein Ablauf ableiten, der ohne großen Aufwand nach jeder Auslieferung greift. Er setzt an einer einfachen Idee an: Die Seite soll selbst sagen, welche Version sie ist. Alles Weitere ist der Abgleich dieser Aussage über alle Schichten und Standorte hinweg.

1. Versionsangabe ausliefern: Schreiben Sie die Bau-Kennung in das HTML - als Meta-Angabe im Kopf oder als eigenen Antwort-Header. Erst damit wird aus der weichen Frage, ob die Seite richtig aussieht, die überprüfbare Frage, ob die Seite Version 42 enthält.
2. Mit echtem Browser prüfen: Ein reiner Abruf holt das HTML und beurteilt Header, führt aber keine Skripte aus und kennt keinen Service Worker. Erst eine Prüfung im echten Browser zeigt, was Besucher tatsächlich sehen - das gilt für Cache-Stände ebenso wie für die im Browser-Monitoring hinterlegten Klickstrecken.
3. Von mehreren Standorten aus prüfen: Ein CDN hält je Knoten eine eigene Kopie. Eine einzelne Prüfstelle beantwortet deshalb nur, wie es an genau diesem Ort aussieht. Mehrere Standorte machen den Unterschied zwischen einem flächendeckenden Fehler und einem einzelnen hängenden Knoten sichtbar.
4. Darstellung vergleichen: Ein Bildvergleich vor und nach dem Deploy zeigt Abweichungen, die kein Statuscode meldet - fehlende Stile, alte Preise, verschwundene Bereiche. Das Verfahren beschreibt der Beitrag zum Erkennen von Änderungen per Bildvergleich.
5. Antwortzeit im Blick behalten: Fällt ein Cache aus oder wird er nach dem Deploy vollständig geräumt, schlägt jede Anfrage bis zum Ursprungsserver durch. Die Antwortzeit steigt dann sprunghaft, oft bevor Besucher etwas melden - die Zusammenhänge beschreibt der Beitrag zur Server-Antwortzeit.
6. Service-Worker-Pfad gesondert prüfen: Kontrollieren Sie, ob die Worker-Datei den erwarteten Stand hat und ob das Verzeichnis der vorgehaltenen Dateien auf existierende Namen zeigt. Beides lässt sich als eigener Prüfpunkt einrichten und nach jedem Deploy wiederholen.
7. Alarm auf die fehlende Versionsangabe legen: Enthält eine Seite die erwartete Kennung nicht mehr, liegt entweder ein alter Cache-Stand oder ein unvollständiger Deploy vor. Beides ist ein Fall für die Benachrichtigungswege des Teams, nicht für einen Zufallsfund im Kundengespräch.

Dieses Vorgehen greift in andere Prüfungen ein, die ohnehin nach einem Deploy anstehen. Wer die Kampagnenparameter mitprüft, erkennt früh, wenn eine zwischengespeicherte Seite den Verweis auf die neue Zielseite verloren hat - die Grundlagen dazu stehen im Beitrag zur sauberen Auszeichnung von Kampagnen. Und bei mehrsprachigen Auftritten kann ein Cache-Knoten eine Sprachvariante an der falschen Adresse festhalten, was die im Beitrag zu hreflang-Fehlern beschriebenen Signale durcheinanderbringt.

Cache-Fallen dauerhaft sichtbar machen

Cache-Fehler sind unangenehm, weil sie sich nicht wie Fehler verhalten. Es gibt keinen Ausfall, keinen roten Statuscode und keinen Eintrag im Fehlerprotokoll. Es gibt nur eine Seite, die etwas anderes zeigt als beabsichtigt - und die Wahrscheinlichkeit, dass jemand das meldet, hängt davon ab, wie sichtbar die betroffene Stelle ist. Ein falscher Preis fällt schnell auf, ein überholter Rechtstext in der Fußzeile über Monate hinweg häufig nicht.

Deshalb lohnt es sich, die Kontrolle an den Deploy zu koppeln statt an den Zufall. XICTRAQ ruft Ihre Seiten mit einem echten Browser ab, führt die Skripte aus und sieht damit dieselbe Fassung wie ein Besucher. Die Abrufe erfolgen von mehreren Standorten, sodass ein einzelner hängender CDN-Knoten auffällt, statt unterzugehen. Der Screenshot-Changelog hält fest, wie die Seite vor und nach der Auslieferung aussah, und der Bildvergleich zeigt Abweichungen, für die es keinen Statuscode gibt. Bleibt die erwartete Versionsangabe aus, meldet die Überwachung von Erreichbarkeit und Inhalt das als Abweichung - unabhängig davon, ob der Ursprungsserver längst umgestellt ist.

Aus den Ergebnissen entsteht ein Verlauf, der sich in Berichten und Statusseiten festhalten lässt - hilfreich für Agenturen, die den Zustand mehrerer Kundenauftritte nach einer Auslieferungsrunde belegen möchten. Sehen Sie sich die Prüfung in der Produktdemonstration an oder richten Sie den ersten Prüfpunkt im kostenlosen Zugang ein und lassen Sie den nächsten Deploy von außen bestätigen, statt ihn nur zu vermuten.