WordPress-Cache leeren — warum die Änderung nicht ankommt.

Kurz gesagt

Es gibt bis zu sechs Caches hintereinander: Browser, Page-Builder-Dateien, Cache-Plugin, Server-Cache beim Hoster, CDN und Objekt-Cache. Leeren immer von hinten nach vorn: erst Builder und Plugin, dann Server, dann CDN, zuletzt der eigene Browser. Sehen nur Besucher den alten Stand, ist es fast immer der Seiten-Cache. Siehst nur du ihn, ist es dein Browser.

Die Kette der Zwischenspeicher.

Die richtige Reihenfolge.

1. Page-Builder: CSS und Daten neu erzeugen lassen.
2. Cache-Plugin: kompletten Cache leeren, nicht nur eine Seite.
3. Server-Cache beim Hoster leeren.
4. CDN leeren.
5. Objekt-Cache leeren, falls vorhanden.
6. Eigener Browser: hart neu laden mit Strg+Umschalt+R, auf dem Mac Cmd+Umschalt+R.
7. Im privaten Fenster prüfen — so siehst du, was Besucher sehen.

Wer die Reihenfolge umdreht, leert den vorderen Cache und füllt ihn sofort wieder mit dem alten Inhalt aus dem hinteren. Das ist der Grund, warum „ich hab doch geleert“ so oft nicht stimmt.

Wer sieht den alten Stand?

Cache-Plugins.

Verbreitet sind WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache und die eingebauten Lösungen mancher Hoster. Die meisten leeren ihren Cache automatisch, wenn du einen Beitrag speicherst — aber nur für diesen Beitrag, nicht für Übersichtsseiten, Menüs oder Widgets, die ihn erwähnen. Deshalb bei Änderungen an Menü, Footer oder globalen Elementen immer komplett leeren. Wichtig außerdem: Nie zwei Caching-Plugins gleichzeitig. Das führt zu widersprüchlichen Zuständen, die stundenlange Fehlersuche kosten.

Server-Cache und CDN.

Viele Hoster betreiben einen eigenen Cache vor WordPress, etwa mit Varnish oder einem LiteSpeed-Server. Der wird nicht automatisch geleert, wenn dein Plugin leert. Im Kundenmenü gibt es dafür meist einen Button. Steht zusätzlich ein CDN wie Cloudflare davor, kommt dessen Cache dazu — dort reicht bei Änderungen am Layout oft das gezielte Leeren einzelner Adressen, bei größeren Umbauten der komplette Durchlauf. Nach einem Relaunch oder einer Umstellung immer alles leeren (Staging auf Live übertragen).

Page-Builder und CSS.

Elementor, Divi und andere Builder erzeugen für jede Seite eigene CSS-Dateien. Ändert sich eine globale Einstellung, müssen diese Dateien neu geschrieben werden. Unter Elementor gibt es dafür Werkzeuge mit der Funktion, Dateien und Daten neu zu generieren. Bleibt das Layout danach kaputt, liegt es meist an fehlenden Schreibrechten im Uploads-Ordner oder an einem Optimierer, der auf gelöschte Dateien verweist (Layout kaputt, CSS lädt nicht).

Browser-Cache.

Der einfachste Test ist das private Fenster. Siehst du dort den neuen Stand, war es dein Browser. Hartes Neuladen mit Strg+Umschalt+R holt HTML und Dateien neu. Hilft das nicht, kann ein Service Worker im Spiel sein, wie ihn manche Performance-Plugins installieren — der lässt sich in den Entwicklertools unter Anwendung abmelden. Bei Kunden, die den alten Stand sehen, hilft der Hinweis auf hartes Neuladen, oft ist es aber doch der Seiten-Cache.

Wenn es ständig passiert.

• Cache-Laufzeit zu lang: Bei Seiten, die sich oft ändern, eine kürzere Gültigkeit einstellen.
• Automatisches Leeren einrichten: Gute Plugins leeren bei jeder Aktualisierung die betroffenen Seiten plus Startseite und Archive.
• Vorwärmen: Nach dem Leeren die wichtigsten Seiten automatisch neu aufbauen lassen, damit der erste Besucher keine langsame Seite sieht.
• Einheitlich arbeiten: Ein Cache-Plugin, ein Server-Cache, ein CDN — nicht drei Lösungen, die sich überschneiden (WordPress langsam).

Was nicht gecacht werden darf.

Warenkorb, Kasse, Kundenkonto, Anmeldeseite und alle Seiten mit persönlichen Inhalten gehören nie in den Seiten-Cache. Passiert es doch, sehen Besucher fremde Warenkörbe oder leere Kassen — einer der häufigsten Shop-Fehler überhaupt (Checkout funktioniert nicht). Ebenso wenig gecacht werden dürfen Seiten mit Formular-Sicherheitsschlüsseln, sonst laufen Anfragen ins Leere.

Wenn du nicht weiterkommst.

Wenn Änderungen dauerhaft nicht ankommen oder mehrere Caches sich in die Quere kommen, räume ich die Kette auf. Ich richte das ein, prüfe die Einbindung und erkläre dir, worauf es ankommt: WordPress-Hilfe. Damit es dauerhaft sauber bleibt: WordPress-Wartung.

Wer hilft.

Ich bin Manuel Killert, WordPress-Entwickler aus Quakenbrück. Seit 2020 baue und betreue ich WordPress-Websites — für Handwerksbetriebe, Industrie, Gastronomie, Start-ups und Vereine —, entwickle eigene Plugins und unterrichte WordPress als Dozent an der KW Design Akademie. Das heißt: Ich kenne die typischen Fehler nicht nur aus Foren, sondern aus eigenen Projekten, und ich kann sie so erklären, dass du sie beim nächsten Mal selbst erkennst. Du erreichst mich direkt, ohne Ticketsystem.