Sie bearbeiten eine Seite in WordPress, klicken auf Aktualisieren und öffnen die Website. Der alte Text ist immer noch da. Sie versuchen es in einem privaten Fenster, dann auf dem Handy. Wieder die alte Version. Im Editor sieht alles richtig aus, also wirkt es, als würde die Website Sie ignorieren.
Das tut sie so gut wie nie. Irgendwo zwischen Ihrem Editor und Ihren Besuchern liegt ein Cache, der die vorherige Version der Seite gespeichert hat und sie ausliefert, bis sie abläuft oder jemand sie verwirft. Auf einer aktuellen WordPress- oder WooCommerce-Website kann es vier oder fünf solcher Caches geben, und jeder wird auf andere Weise geleert.
Im Folgenden gehen wir die Ebenen in der Reihenfolge durch, in der eine Anfrage sie erreicht, zeigen, wie Sie herausfinden, welche Ihre Seite festhält, und beschreiben das Setup, mit dem gespeicherte Änderungen von selbst online gehen.
Warum Websites Seiten überhaupt zwischenspeichern
Für eine WordPress-Seite müssen PHP und mehrere Datenbankabfragen laufen. In einem gut besuchten Shop kann das pro Anfrage einige hundert Millisekunden dauern. Ein Cache speichert das fertige HTML und gibt dieselbe Kopie in wenigen Millisekunden an den nächsten Besucher aus. Deshalb fühlt sich eine Website mit Cache schnell an und übersteht Lastspitzen.
Der Preis dafür ist Aktualität. Ein Cache, der Seiten eine Woche lang hält, ist sehr schnell und, wenn ihn nichts leert, eine Woche veraltet. Gute Setups behalten die lange Laufzeit und leeren genau die Seiten, die sich geändert haben, in dem Moment, in dem sie sich ändern.
Die Ebenen zwischen Ihrem Editor und Ihren Besuchern
1. Der Browser des Besuchers
Browser speichern Bilder, CSS und JavaScript und manchmal auch HTML, je nachdem, welche Header der Server sendet. Diese Ebene betrifft nur Personen, die schon einmal da waren. Deshalb ist "im privaten Fenster sieht es gut aus" ein sinnvoller erster Test.
2. Das CDN
Dienste wie Cloudflare sitzen vor dem Server und speichern Dateien in Rechenzentren in der Nähe der Besucher. Standardmäßig speichert Cloudflare kein HTML, sondern nur statische Dateien wie Bilder, CSS und JavaScript. Wenn Ihr Seitentext veraltet ist und niemand eine Regel wie "alles cachen" angelegt hat, ist das CDN wahrscheinlich nicht schuld. Gibt es eine solche Regel, ist es der erste Verdächtige.
3. Der Server-Cache (Varnish, Nginx, LiteSpeed)
Viele Hosting-Panels setzen einen Ganzseiten-Cache vor PHP. CloudPanel zum Beispiel bringt Varnish Cache mit, dessen Laufzeit sich einstellen lässt und in den Installationen, mit denen wir arbeiten, auf sieben Tage steht. Hinter den meisten Meldungen wie "meine Änderung erscheint nicht" steckt diese Ebene, aus zwei Gründen:
- Sie muss ausdrücklich geleert werden. Varnish behält die gespeicherte Seite bis zum Ende ihrer Laufzeit oder bis zu einer PURGE-Anfrage. In der Version des CloudPanel-Plugins für WordPress, die wir im September 2026 geprüft haben (1.1.1), wurde bei Updates von Plugins und Core sowie beim Theme-Wechsel geleert, aber nicht beim Speichern einer Seite, eines Produkts oder eines Page-Builder-Blocks.
- Sie kann noch einmal eine veraltete Kopie ausliefern. Das liegt am Grace-Modus: Der erste Besucher nach Ablauf kann noch die alte Seite bekommen, während Varnish im Hintergrund die neue holt. Die zweite Anfrage erhält die aktuelle Version.
Bei mehrsprachigen oder nicht englischen Websites gibt es eine zweite Falle: Die Liste der ausgeschlossenen Pfade im Panel nutzt englische Slugs wie /my-account/ und /cart/. Ein deutscher Shop mit /mein-konto/ oder /warenkorb/ muss diese Pfade von Hand ergänzen, sonst landen persönliche Seiten im gemeinsamen Cache.
4. WordPress-Cache-Plugins
Plugins wie LiteSpeed Cache, WP Rocket oder W3 Total Cache legen ihre eigene Kopie jeder Seite an. Die meisten leeren beim Speichern, kennen aber nur die Inhalte, die sie selbst verwalten. Zieht eine Website auf einen Server um, auf dem eine andere Ebene (zum Beispiel Varnish) zuständig ist, laufen die Leerungsbefehle des Plugins möglicherweise ins Leere.
5. Objekt-Cache und Caches von Theme oder Page Builder
Redis oder Memcached speichern Datenbankergebnisse, und manche Themes und Page Builder halten eigenes kompiliertes CSS oder Fragmente vor. Eine Textänderung verstecken sie selten lange, aber sie erklären, warum eine Stiländerung manchmal einen Button wie "CSS neu erzeugen" braucht.
Finden Sie die Ebene, die Ihre Seite festhält
Für die Eingrenzung brauchen Sie keinen Serverzugang. Die Antwort-Header verraten, wer geantwortet hat und wie alt die Kopie ist. Öffnen Sie die Seite, drücken Sie F12, wechseln Sie zum Tab Netzwerk, laden Sie neu, klicken Sie auf die erste Anfrage und lesen Sie die Antwort-Header. Im Terminal zeigt curl -sI https://ihreseite.de/seite/ dieselben Informationen.
| Header | Was er Ihnen sagt |
|---|---|
cf-cache-status | HIT bedeutet, dass Cloudflare seine Kopie ausgeliefert hat. DYNAMIC bedeutet, dass die Anfrage durchgereicht und das HTML nicht gespeichert wurde. |
age oder x-cache-age | Sekunden, seit die Kopie gespeichert wurde. Ist der Wert größer als die Zeit seit Ihrem Speichern, sehen Sie die alte Version. Siehe die Referenz zum Age-Header. |
x-varnish, via | Varnish oder ein anderer Proxy war an der Antwort beteiligt. |
x-litespeed-cache, x-cache | Ein Plugin oder Server-Cache hat geantwortet, mit hit oder miss. |
cache-control | Wie lange Browser und gemeinsame Caches die Seite behalten dürfen. |
Kurz gelesen: Ist cf-cache-status gleich DYNAMIC und wird das Alter in Stunden oder Tagen gemessen, ist das CDN in Ordnung und der Server-Cache hält die Seite fest.
Jetzt beheben und dann dauerhaft lösen
Sofort
- Leeren Sie den Server-Cache der Website im Hosting-Panel. In CloudPanel ist das die Option Purge Cache in den Varnish-Einstellungen der Website, die sich auch auf eine einzelne URL beschränken lässt.
- Leeren Sie das WordPress-Cache-Plugin, falls eines installiert ist.
- Leeren Sie das CDN nur, wenn es HTML speichert. Statische Dateien zu leeren, die Sie nicht geändert haben, macht die nächsten Besuche nur langsamer.
- Laden Sie zweimal neu und prüfen Sie den Age-Header erneut. Wegen des Grace-Modus kann der erste Aufruf noch die alte Seite zeigen.
Dauerhaft
Einmal von Hand zu leeren ist in Ordnung. Als Routine heißt das aber, dass sich jeder, der die Website bearbeitet, an einen Schritt erinnern muss, den ihm niemand erklärt hat. Besser ist ein Setup, das automatisch leert, wenn sich Inhalte ändern. Auf den WordPress- und WooCommerce-Websites, die wir betreuen, ergänzen wir ein kleines Must-Use-Plugin, das die Leerung auslöst, sobald sich etwas Sichtbares ändert:
- Veröffentlichen, Bearbeiten oder Zurückziehen von Seiten, Beiträgen und Produkten
- Page-Builder-Blöcke, die in anderen Seiten wiederverwendet werden, etwa Footer
- Menüs, Customizer-Einstellungen, Kategorien und Schlagwörter
- Lagerbestandsänderungen und neu freigegebene Bewertungen
Zwei Details sind wichtig. Die Leerung läuft einmal am Ende der Anfrage, sodass eine Massenbearbeitung nicht hundert Leerungen auslöst. Und sie läuft nie bei neuen Bestellungen oder Entwürfen, die nichts an dem ändern, was Besucher sehen. Inhalte, die sich nach Zeitplan ändern, etwa Öffnungszeiten oder Veranstaltungslisten, bekommen nur für diese Seite oder dieses Fragment eine kürzere Laufzeit, statt den Cache der ganzen Website zu verkürzen.
Die Seiten bleiben tagelang im Cache, und eine Änderung erreicht alle Besucher wenige Sekunden nach dem Klick auf Aktualisieren.
Kurze Checkliste
- Die Änderung sieht im Editor richtig aus, aber nicht auf der Website: Prüfen Sie zuerst den Header
age. - Kennen Sie die Cache-Ebenen Ihrer Website. Wenn niemand sie aufzählen kann, ist das die erste Aufgabe.
- Stellen Sie sicher, dass beim Speichern von Inhalten geleert wird, nicht nur bei Plugin-Updates.
- Prüfen Sie, ob die Cache-Ausnahmen zu Ihren echten URLs passen, besonders bei Konto-, Warenkorb- und Kassenseiten in anderen Sprachen.
- Prüfen Sie nach einem Serverumzug, ob das alte Cache-Plugin noch einen Gesprächspartner hat.
Cache-Probleme gehören zu unserer Arbeit an Performance und Wartung für WordPress-Websites und Onlineshops.
Ihre Änderungen sind immer noch nicht sichtbar?
Nennen Sie uns die Adresse der Seite und was Sie geändert haben. Wir finden die Ebene, die sie festhält, und richten die Leerung so ein, dass die nächste Änderung von selbst online geht.