Warum zeigt meine Website noch die alte Version?

Ihre Website ist in Ordnung. Die Kopie davor ist alt.

Veröffentlichen schreibt eine neue Version der Seite in Ihren Origin, also auf den Server oder in den Speicher-Bucket, aus dem Ihr Hoster tatsächlich liest. Nichts an diesem Schritt garantiert, dass Ihre Besucher mit Ihrem Origin sprechen. Zwischen beiden liegen Ihr Browser, meist ein Content Delivery Network, manchmal ein Service Worker, den Ihr Framework installiert hat, und gelegentlich ein Proxy im Netz des Besuchers selbst. Jede dieser Stellen hält eine Kopie und eine Regel dazu, wie lange sie ihr vertraut, und jede von ihnen beantwortet eine Anfrage, ohne irgendwen zu fragen.

Das Kennzeichen dieses Problems ist Widersprüchlichkeit. Sie sehen die neue Seite, Ihre Kundin nicht. Zwei Menschen erhalten unterschiedliche Versionen derselben Adresse. Eine Stunde später ist es ohne jedes Deployment behoben. Dieses Muster lohnt sich zu lernen, denn ein wirklich kaputtes Release ist für alle gleichzeitig kaputt: Wenn es bei einigen funktioniert, hören Sie auf, das Build-Log zu lesen, und finden Sie stattdessen heraus, wer die Anfrage beantwortet. Die Regel unter der ersten überrascht die meisten: Viele Caches halten eine Kopie nicht nur bis zum Ablauf, sie liefern die abgelaufene Kopie weiter aus, während sie im Hintergrund eine frische holen. Abgelaufen bedeutet nicht außer Betrieb, und genau so überlebt eine Seite ihre eigene Haltbarkeit mit großem Abstand.

Finden Sie die Schicht, bevor Sie etwas reparieren

Jeder Schritt unten schließt einen Cache aus, in der Reihenfolge des geringsten Aufwands. Arbeiten Sie die Liste ab und halten Sie beim ersten Schritt an, der die neue Seite zeigt: Das ist Ihre Antwort, und die Lösung ist ein Purge auf dieser Schicht, nicht ein weiteres Deployment.

1. Öffnen Sie sie in einem privaten Fenster. Erscheint dort die neue Version, lag die alte Kopie nur in Ihrem eigenen Browser und kein Besucher war betroffen. Ein harter Reload im normalen Fenster, und Sie sind fertig. Das ist das häufigste Ergebnis und der am häufigsten übersprungene Schritt, weshalb die Aufregung meist länger dauert als der Fehler.
2. Hängen Sie einen bedeutungslosen Query-Parameter an. Laden Sie dieselbe Adresse mit etwas wie ?x=1 am Ende. Die meisten geteilten Caches behandeln das als andere URL und holen sie beim Origin. Eine frische Seite hier bedeutet also: Ihr Origin ist korrekt, und etwas zwischen Ihnen und ihm liefert unter der sauberen Adresse weiterhin die alte Kopie aus.
3. Öffnen Sie sie in einem anderen Netz. Ein Telefon im Mobilfunknetz statt im Büro-WLAN. Ein Content Delivery Network hält getrennte Kopien an getrennten Standorten, dieser Schritt trennt also einen veralteten Standort von etwas, das alle Besucher erhalten. Und er ist die einzige Variante des Tests, die widerspiegelt, was ein Fremder tatsächlich sieht.
4. Fragen Sie den Origin direkt. Rufen Sie die Seite über das Dashboard Ihres Hosters, eine serverseitige Vorschau oder eine Anfrage direkt an den Origin statt an die öffentliche Adresse ab. Ist der Origin richtig und die öffentliche URL falsch, liegt das Problem vollständig in der Auslieferung, und nichts in Ihrem Code oder Ihrem Build wird daran etwas ändern.

Wenn Sie die Schicht kennen, purgen oder invalidieren Sie dort und wiederholen dann den dritten Schritt aus einem Netz, das Sie nicht kontrollieren. Eine Korrektur vom eigenen Rechner aus zu bestätigen ist der Weg, auf dem Leute sicher sind, ein Purge habe gewirkt, obwohl er es nicht tat.

Die Variante, die uns eine Stunde gekostet hat

Wir hosten Seiten für unsere eigenen Kunden, das ist also unser Problem und nicht nur das unserer Leser. Am 11. September 2026 fanden wir eine Seite, die wir offline genommen hatten und die zweiundfünfzig Minuten nach der Abschaltung immer noch an jeden ausgeliefert wurde, der sie öffnete. Alles, was wir auf unserer Seite sehen konnten, war korrekt: Die Datei war aus dem Speicher verschwunden, und unsere eigenen Einträge sagten, die Seite sei nicht mehr veröffentlicht. Das davorliegende Content Delivery Network war so eingestellt, dass es bis zu einen Tag lang mit seiner letzten guten Kopie antwortete, während es im Hintergrund revalidierte. Gelöscht beschrieb also unseren Speicher und sagte nichts darüber, was ein Besucher erhielt. Wir haben es bewusst an zwei Stellen behoben: einmal in der Konfiguration des Netzes, damit abgelaufene Kopien überhaupt nicht mehr ausgeliefert werden, und einmal in den Cache-Anweisungen der Seite selbst, damit die Grenze nicht länger von einer Einstellung abhängt, die ein neu aufgebautes Backend stillschweigend auf den Standardwert zurücksetzen würde.

Die Regel, die wir daraus gezogen haben, ist der übertragbare Teil: Veröffentlicht, aktualisiert und gelöscht sind Aussagen über Ihren Origin. Was ein Besucher erhält, ist eine davon getrennte Tatsache, und der einzige ehrliche Weg, sie zu erfahren, ist, die Seite so abzurufen, wie es ein Fremder täte. Dieselbe Schicht hat außerdem verändert, was wir messen konnten. Die Aufrufe der Seiten, die wir hosten, erfassen wir als Untergrenze und nicht als Gesamtzahl, denn eine am Rand des Netzes beantwortete Anfrage erreicht den zählenden Origin nie. Und solange die Auslieferung abgelaufener Kopien aktiv war, stammte der größte Teil dieser Zahl aus den Cache-Aktualisierungen unseres eigenen Netzes, bis wir sie namentlich ausgeschlossen haben. Ein Cache verändert nicht nur, was Menschen sehen. Er verändert, was Sie darüber beweisen können, was sie gesehen haben.

Er hat auch verändert, wie wir die beiden Vorgänge schreiben. Veröffentlichen lädt zuerst die Datei hoch und schreibt danach den Eintrag, denn die umgekehrte Reihenfolge verzeichnet eine lebende Seite, während nichts ausgeliefert wird. Offline nehmen löscht zuerst die Datei und markiert danach den Eintrag, denn die umgekehrte Reihenfolge verzeichnet eine Seite als entfernt, während sie noch steht. Scheitert die zweite Hälfte, ist der Zustand, den wir melden, in der Richtung falsch, in der falsch zu liegen sicher ist. Sich vorher zu fragen, welchen Fehlschlag man lieber hätte, ist der größte Teil davon, eine Website sorgfältig zu betreiben. Und es ist dieselbe Disziplin, die wir in AgentCeres einbauen, den AI Growth Officer auf agentceres.com: Ein Team aus Fachrollen entwirft die Seiten, Beiträge und Ansprachen, und was nach außen geht, wartet standardmäßig auf die Freigabe durch einen Menschen. Wenn Sie gerade zum ersten Mal eine Website veröffentlicht haben, sind die Prüfungen in Soll ich meine Website mit KI bauen? die andere Hälfte dieser Seite.