Wissen / Hosting und Auslieferung

Website geändert, aber alter Inhalt sichtbar: Caches verstehen

Kurz gesagt: Wenn eine Website nach einer Änderung alte Inhalte zeigt, kann eine zwischengespeicherte Antwort beteiligt sein. Browser, vorgeschaltete Dienste und das eigene System besitzen unterschiedliche Speicher. Entscheidend ist, wo der aktuelle Stand liegt, welche Antwort wiederverwendet wird und wie sie erneuert werden soll. Pauschales Löschen aller Caches ersetzt diese Zuordnung nicht.

Veröffentlicht am 9. Oktober 2026 / Aktualisiert am 29. Oktober 2026 / Redaktion: Ruhrstack / 10 Minuten Lesezeit

01 / BEOBACHTUNG

Zuerst festhalten, was genau noch alt ist.

Die gleiche sichtbare Abweichung kann aus unterschiedlichen Teilen der Auslieferung stammen.

Ein geänderter Text erscheint auf dem eigenen Rechner, beim Kollegen aber weiterhin in der alten Fassung. Ein neues Logo ist sichtbar, doch sein Abstand entspricht noch dem vorherigen Layout. Solche Beobachtungen sind ein Anlass zur gezielten Prüfung. Sie beweisen allein weder einen Browserfehler noch einen fehlgeschlagenen Upload.

Notieren Sie die genaue Adresse, den betroffenen Inhalt, den vorgesehenen Stand und die Beobachtungszeit. Wichtig ist auch, ob die Seite neu geöffnet, nur über die Zurücktaste erreicht oder in einem bereits lange offenen Tab betrachtet wurde. Eine fertige Serveränderung verändert nicht rückwirkend jede schon geladene Ansicht.

Vergleichen Sie anschließend zwei kontrollierte Abrufe. Ist bereits die Antwort am zuständigen Ursprung veraltet, muss zunächst die Veröffentlichung untersucht werden. Liefert dieser die neue Fassung, während ein anderer Weg die alte zeigt, werden die dazwischenliegenden Speicher interessant. Wer sofort alle Einstellungen ändert, verliert diesen Vergleich.

Die MDN-Einführung zum HTTP-Caching beschreibt gespeicherte Antworten, die für spätere Anfragen wiederverwendet werden. Das erklärt, warum „Datei aktualisiert“ und „überall neue Antwort gesehen“ verschiedene Feststellungen sind. Dieser Beitrag behandelt diese Auslieferung; die Bewertung von Ladezeit und Interaktion steht separat bei den Core Web Vitals.

02 / CACHE-EBENEN

Browser, Vermittler und Anwendung getrennt betrachten.

Ein Löschknopf erreicht meist nur einen bestimmten Speicher.

Der Browser kann Antworten lokal wiederverwenden. Ein vorgeschalteter Proxy oder ein Content Delivery Network kann Antworten für mehrere Besucher bereithalten. Ein Redaktionssystem kann zusätzlich fertig erzeugte Seiten oder Abfrageergebnisse speichern. Diese Ebenen müssen nicht gleichzeitig vorhanden sein. Sie müssen aber bekannt sein, bevor eine Störung sinnvoll eingegrenzt wird.

Der Standard RFC 9111 zum HTTP-Caching unterscheidet unter anderem private und gemeinsam genutzte HTTP-Caches. Ein interner Seitenspeicher im CMS hat daneben eigene Regeln. Eine Aufforderung zum erneuten HTTP-Abruf baut deshalb nicht automatisch einen intern veralteten Seitenstand neu auf.

Erstellen Sie eine einfache Wegskizze: Besucher, gegebenenfalls vorgeschalteter Dienst, Webserver, Anwendung und Veröffentlichung. Schreiben Sie neben jede vorhandene Schicht, wer sie verwaltet. Die gleiche Organisation kann mehrere Schichten betreuen; unterschiedliche Anbieter können wiederum nur jeweils einen Teil beeinflussen. Der tatsächlich konfigurierte Weg zählt.

Auch ein erfolgreicher privater Browserstart ist nur ein Vergleichspunkt. Er kann zeigen, dass eine lokale Sitzung oder ein lokaler Speicher beteiligt war. Er beweist nicht, dass ein vorgeschalteter Speicher für alle Besucher den richtigen Stand liefert. Umgekehrt leert eine Erneuerung beim vorgeschalteten Dienst keine bereits gespeicherte Browserantwort auf fremden Geräten.

03 / WIEDERVERWENDUNG

Aktualität und Speichern sind verschiedene Entscheidungen.

Eine technische Cache-Regel sollte in eine verständliche Inhaltsanforderung übersetzt werden.

Für jede Antwort wird zunächst geklärt, wie lange eine unveränderte Fassung ohne erneute Rückfrage verwendbar sein darf. Eine selten wechselnde Illustration und eine aktuelle Betriebsmeldung stellen unterschiedliche Anforderungen. Diese fachliche Unterscheidung gehört vor die Wahl einzelner Headerwerte. Eine pauschale lange Speicherdauer für die gesamte Website ist selten eine begründete Antwort.

Die Cache-Control-Referenz von MDN trennt die Direktiven: no-cache verlangt vor Wiederverwendung eine Validierung, verbietet das Speichern aber nicht. no-store untersagt das Speichern dieser Antwort. private begrenzt die Ablage auf private Caches. Diese Begriffe sind nicht austauschbar und auch keine vollständige Zugriffskontrolle.

Eine Validierung kann Übertragung sparen, ohne einen erkennbar veralteten Inhalt zu akzeptieren. Ein ETag kennzeichnet nach MDN eine bestimmte Ressourcenfassung. Stimmt der bekannte Stand noch, kann der Server das bestätigen; bei Änderung muss die Kennzeichnung zur neuen Fassung passen. Ein falsch unverändert gebliebener Vergleichswert würde die beabsichtigte Prüfung unterlaufen.

Vereinbaren Sie daher eine nachvollziehbare Regel pro Inhaltsart und prüfen Sie die tatsächlich ausgelieferte Antwort. Eine gespeicherte Konfiguration im Hostingmenü ist noch kein Nachweis dafür, dass jede vorgelagerte Schicht dieselbe Regel beachtet.

04 / VARIANTEN

Öffentliche und persönliche Antworten sauber trennen.

Eine richtige Fassung für eine Person kann für eine andere Person unzulässig sein.

Bei einer öffentlichen Leistungsseite sollen Besucher in der Regel denselben freigegebenen Inhalt sehen. Eine persönliche Übersicht nach der Anmeldung hat eine andere Aufgabe. Sie darf nicht versehentlich als gemeinsame Antwort an andere Sitzungen gelangen. Ob und wie solche Antworten gespeichert werden, wird deshalb vor der Aktivierung einer umfassenden Cache-Regel entschieden.

Zusätzlich können Antworten unter derselben Adresse von bestimmten Anfrageeigenschaften abhängen. Die MDN-Dokumentation zu Vary erklärt, wie relevante Anfrageheader für getrennte Cache-Varianten benannt werden. Das ist ein Mechanismus für die passende Variantenauswahl, kein Ersatz für Rechteprüfung oder eine vollständige Regel für persönliche Daten.

Ein fiktives Kundenportal illustriert die Frage: Ein Kunde sieht seine eigenen Dokumente, ein anderer seine. Eine allgemeine Beschleunigungsregel für sämtliche HTML-Antworten müsste diesen Unterschied ausdrücklich berücksichtigen. Als Abnahmefall werden zwei kontrollierte Testkonten und ein abgemeldeter Abruf verglichen. Reale Kundendokumente werden dafür nicht verwendet.

Die technische Betreuung klärt außerdem Formularantworten, Fehlerseiten und den Übergang nach Anmeldung oder Abmeldung. Nicht jede öffentlich erreichbare Adresse liefert ausschließlich öffentlichen Inhalt. Sobald private Informationen oder Sitzungszustände beteiligt sind, gehört die Cache-Entscheidung in die gezielte Sicherheitsprüfung. Für den ersten Austausch genügt eine Beschreibung dieser Inhaltsarten; vertrauliche Daten sind kein notwendiges Anschauungsmaterial.

05 / VERÖFFENTLICHUNG

Inhalt, Abhängigkeiten und Erneuerung gemeinsam planen.

Eine neue HTML-Fassung kann weiterhin auf eine alte Datei verweisen.

Die Freigabe einer Änderung sollte benennen, welche Bestandteile zusammengehören. Bei einem geänderten Formular können Dokument, Stylesheet und Skript betroffen sein. Erscheint nur ein Teil neu, kann ein widersprüchlicher Zwischenstand entstehen. Deshalb ist zu prüfen, wie die Veröffentlichung und die Cache-Erneuerung diese zusammenhängende Änderung behandeln.

Für geeignete statische Dateien lässt sich eine neue Fassung über eine neue Ressourcenadresse unterscheiden. Das ist etwa bei einem Stylesheet sinnvoll, dessen Inhalt sich ändert. Die redaktionelle Seitenadresse sollte deshalb nicht bei jeder Textkorrektur wechseln. Trennen Sie die dauerhaft gewünschte Inhaltsadresse von einer technischen Fassung ihrer Hilfsdateien.

Ein vorgeschalteter Dienst bietet möglicherweise eine gezielte Erneuerung nach URL oder Gruppenmerkmalen. Die Cloudflare-Dokumentation zum Purge beschreibt verschiedene Verfahren und empfiehlt eine gezielte Erneuerung einzelner Dateien. Sie weist außerdem darauf hin, dass die Annahme eines Purge-Auftrags noch keine vollständige Ergebnisprüfung ersetzt. Die Quelle erläutert einen möglichen Dienst, nicht eine notwendige Ruhrstack-Abhängigkeit.

Schreiben Sie für die eigene Umgebung auf, welche Änderung welchen Speicher betrifft. „Nach jeder Bearbeitung alles leeren“ kann als kurzfristige Diagnose dienen, ist aber kein präziser Veröffentlichungsprozess. Ein geplanter Weg benennt die betroffenen Antworten und prüft sie anschließend über die öffentliche Adresse.

06 / DIAGNOSEKARTE

Mit einem kontrollierten Vergleich zur betroffenen Ebene.

Diese eigene Matrix ordnet Beobachtungen ein, ohne bereits eine Ursache zu behaupten.

Das folgende fiktive Beispiel betrifft eine Firma, die ihre Telefonnummer auf einer Kontaktseite geändert hat. Im Redaktionssystem steht die neue Nummer, ein Teil der Abrufe zeigt noch die alte. Die Tabelle dient als Gesprächsgrundlage mit der Betreuung und ersetzt keine Untersuchung der tatsächlichen Antwortheader.

Alter Inhalt nach einer Veröffentlichung
Beobachtung	Nächste Prüfung	Noch nicht bewiesen
Ursprung liefert alte Nummer	Veröffentlichung, Zielverzeichnis und internen Seitenspeicher vergleichen	Ein Fehler des Besucherbrowsers
Ursprung neu, öffentliche Antwort alt	Vorgeschaltete Speicher und passende Varianten untersuchen	Dass jeder Besucher dieselbe alte Antwort erhält
Nur ein bereits offener Tab bleibt alt	Neuabruf und vorherige Ansicht unterscheiden	Eine fehlgeschlagene Veröffentlichung
Text neu, Darstellung alt	Zugehörige CSS- und Skriptfassungen vergleichen	Dass der neue Inhalt selbst fehlerhaft ist

Halten Sie beim Vergleich jeweils denselben Inhalt und dieselbe Adresse fest. Unterschiedliche Sprachpfade, Parameter oder Anmeldestände können sonst den Eindruck widersprüchlicher Ergebnisse erzeugen. Dokumentieren Sie, welcher gezielte Eingriff die Abweichung verändert hat. So bleibt die Korrektur nachvollziehbar und lässt sich beim nächsten Mal schneller wiederholen.

07 / NACHKONTROLLE

Den freigegebenen Stand über den echten Weg prüfen.

Eine lokale Vorschau und ein erfolgreicher Löschauftrag reichen als Abschluss nicht aus.

Nach der Korrektur wird die ursprüngliche Beobachtung erneut geprüft. Im Telefonnummernbeispiel muss die richtige Nummer über die öffentliche Kontaktseite erscheinen und der zugehörige Telefonlink stimmen. Eine Prüfung einer anderen Seite würde die ursprüngliche Aufgabe verfehlen. Die Abnahme nennt den tatsächlich beobachteten Weg und Zeitpunkt.

Bei Änderungen an gemeinsam verwendeten Dateien werden außerdem passende Bestandsseiten betrachtet. Eine neue CSS-Fassung darf den bearbeiteten Abschnitt verbessern und zugleich keine benötigte Darstellung einer anderen betroffenen Seite beschädigen. Der Umfang folgt den geänderten Abhängigkeiten; er muss nicht bei jeder kleinen Textkorrektur die gesamte Website umfassen.

Kontrollieren Sie gegebenenfalls auch die Rücknahme einer Veröffentlichung. Wenn die Website zur vorherigen Fassung zurückkehrt, müssen Verweise und Speicher erneut dazu passen. Eine alte Serverdatei und ein neuer lange gespeicherter Helfer ergeben sonst einen dritten, nie freigegebenen Zustand. Dieser Fall wird vor einer kritischen Änderung besprochen.

Das Ergebnis ist eine kurze Betriebsnotiz: betroffene Inhalte, verantwortliche Ebene, ausgeführte Erneuerung und beobachteter neuer Stand. Die Erklärung „Sie müssen Ihren Cache leeren“ sollte eine konkrete Diagnose beschreiben. Als dauerhafte Erwartung an alle Besucher wäre sie eine Schwäche des Veröffentlichungswegs, denn neue Kunden kennen diese Anleitung nicht.

08 / RUHRSTACK

Hosting und Veröffentlichung aufeinander abstimmen.

Der Vorteil entsteht durch bekannte Abhängigkeiten und eine überprüfte Änderung.

Ruhrstack betrachtet bei Hosting und Betrieb die vorhandene Umgebung, beteiligte Systeme und die vereinbarten Funktionen nach Änderungen. Bei einer Cache-Frage beginnt die Arbeit daher mit dem tatsächlichen Auslieferungsweg. Ein zusätzlicher externer Dienst ist keine Voraussetzung für eine passende Lösung.

Hilfreich für die erste Einordnung sind die betroffene URL, ein kurzer Hinweis auf den alten und neuen Inhalt sowie der Zeitpunkt der Veröffentlichung. Nennen Sie auch, ob das Problem nur angemeldet, nur auf einem Gerät oder bei mehreren Abrufen auftritt. Passwörter oder vollständige persönliche Antworten brauchen wir für diese Beschreibung nicht.

Eine individuelle Abstimmung berücksichtigt, wer Inhalte bearbeitet und wie häufig zeitkritische Angaben wechseln. Ein Unternehmen mit täglichen Meldungen braucht einen anderen Ablauf als eine selten veränderte Präsentationsseite. Das Ziel ist nicht möglichst wenig oder möglichst viel Speicherung, sondern ein begründeter Umgang mit Aktualität, geschützten Antworten und nachvollziehbaren Veröffentlichungen.

Wenn Änderungen künftig intern vorgenommen werden, gehört die passende Erneuerung in die Anleitung. Der Beitrag Website-Inhalte selbst pflegen vertieft die Rollen und redaktionellen Voraussetzungen. Damit wird aus einer einmal behobenen Abweichung ein verständlicher Arbeitsschritt für die nächste Veröffentlichung.

09 / QUELLEN

Quellen und redaktioneller Stand.

Die Quellen wurden am 22. Oktober 2026 geprüft. Die verlinkten Primärquellen wurden am 22. Oktober 2026 geprüft. Diagnosekarte und Beispiele sind eigene redaktionelle Arbeitshilfen. Konkrete Regeln müssen zur tatsächlichen Server-, Anwendungs- und Proxykonfiguration passen.

Redaktion: Ruhrstack, Dortmund
Veröffentlicht: 9. Oktober 2026
Aktualisiert: 29. Oktober 2026
Quellen geprüft: 22. Oktober 2026

MDN: HTTP caching: Arten von HTTP-Caches, Wiederverwendung und Aktualisierung. Abgerufen am 22. Oktober 2026.
IETF: RFC 9111, HTTP Caching: Normative Grundlage für HTTP-Caches und ihre Regeln. Abgerufen am 22. Oktober 2026.
MDN: Cache-Control: Bedeutung von no-cache, no-store und private. Abgerufen am 22. Oktober 2026.
MDN: ETag: Kennzeichnung einer Ressourcenfassung für Vergleiche. Abgerufen am 22. Oktober 2026.
MDN: Vary: Unterscheidung von Antworten anhand relevanter Anfrageheader. Abgerufen am 22. Oktober 2026.
Cloudflare: Purge cache: Beispiel für gezielte Erneuerung und anschließende Kontrolle. Abgerufen am 22. Oktober 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Website geändert, aber alter Inhalt sichtbar: Caches verstehen

Zeigt Ihre Website noch den alten Stand?