Zusammenfassung: „Ich habe etwas geändert, aber auf der Seite tut sich nichts” — fast immer ist ein Cache schuld. Der Haken: In WordPress gibt es mehrere Cache-Ebenen übereinander, und wer nur eine leert, sieht die Änderung trotzdem nicht. Die richtige Reihenfolge lautet: Caching-Plugin → Server/Hosting → CDN → Browser. Dieser Artikel zeigt jede Ebene einzeln, wie du sie leerst — inklusive Divis statischer CSS-Dateien — und wie du in 30 Sekunden herausfindest, welche Ebene bei dir klemmt.
Inhaltsverzeichnis
- Warum „Cache leeren” so oft nicht wirkt
- Ebene 1: Caching-Plugin
- Ebene 2: Server- und Hosting-Cache
- Ebene 3: CDN-Cache (Cloudflare & Co.)
- Ebene 4: Browser-Cache
- Sonderfall Divi: statische CSS-Dateien
- Schnelltest: Welche Ebene klemmt?
Warum „Cache leeren” so oft nicht wirkt
Ein Cache speichert eine fertige Version deiner Seite zwischen, damit sie beim nächsten Aufruf blitzschnell ausgeliefert wird, statt jedes Mal neu erzeugt zu werden. Das ist gut für die Performance — aber genau deshalb siehst du Änderungen nicht sofort: Dein Besucher (und oft auch du selbst) bekommt die gespeicherte alte Version.
Der entscheidende Punkt, den fast alle Anleitungen verschweigen: Auf einer typischen WordPress-Seite liegen mehrere Caches übereinander. Leerst du nur den Browser-Cache, aber der Server liefert weiter die alte Seite aus, ändert sich nichts. Deshalb gehst du die Ebenen von innen nach außen durch.
Ebene 1: Caching-Plugin
Die häufigste Ebene. Wenn auf deiner Seite ein Caching-Plugin läuft, hat es fast immer einen „Cache leeren”-Button — oft direkt in der schwarzen WordPress-Adminleiste oben, sonst in den Plugin-Einstellungen. So findest du ihn bei den verbreiteten Plugins:
- WP Rocket: Adminleiste → „WP Rocket” → „Cache leeren”, oder Einstellungen → Dashboard → „Cache leeren”.
- LiteSpeed Cache: Adminleiste → „LiteSpeed Cache” → „Alles leeren” (Purge All).
- W3 Total Cache: Adminleiste → „Performance” → „Purge All Caches”.
- WP Super Cache: Einstellungen → WP Super Cache → „Cache löschen”.
- WP Fastest Cache: Einstellungen → WP Fastest Cache → Reiter „Cache löschen”.
Weißt du nicht, ob ein Caching-Plugin läuft? Schau unter Plugins → Installierte Plugins nach einem Namen mit „Cache” oder „Rocket”. Achtung: Aggressive Minify-/Combine-Optionen dieser Plugins können nach dem Leeren kurz das Layout durcheinanderbringen — das ist normal und legt sich beim nächsten Seitenaufbau.
Ebene 2: Server- und Hosting-Cache
Viele Hoster cachen zusätzlich auf Serverebene — unabhängig von deinem Plugin. Das ist die Ebene, die am häufigsten übersehen wird. Typische Fälle:
- SiteGround: Plugin „SiteGround Optimizer” → „Purge SG Cache” (auch in der Adminleiste).
- Kinsta / WP Engine / Cloudways: eigenes MU-Plugin bzw. Button im Hosting-Panel („Clear Cache” / „Purge”).
- Server mit LiteSpeed oder NGINX FastCGI: wird meist über das LiteSpeed-Cache-Plugin bzw. das Hoster-Panel geleert.
- Object-Cache (Redis/Memcached): auf dynamischen Seiten aktiv — leerst du über das jeweilige Object-Cache-Plugin oder das Hosting-Panel.
Wenn du nach dem Plugin-Cache immer noch die alte Version siehst, ist fast immer diese Ebene dran. Im Zweifel hilft der Blick ins Hosting-Panel oder eine kurze Frage an den Hoster-Support: „Läuft bei euch ein Server-Cache, und wie leere ich ihn?”
Ebene 3: CDN-Cache (Cloudflare & Co.)
Läuft deine Seite über ein CDN wie Cloudflare, bunny.net oder KeyCDN, liegt dort noch eine Kopie deiner Dateien — geografisch verteilt, damit sie überall schnell laden. Diese Ebene leerst du im CDN-Dashboard, nicht in WordPress:
- Cloudflare: Dashboard → Caching → Configuration → „Purge Everything” (oder gezielt einzelne URLs purgen).
- Andere CDNs: Menüpunkt „Purge” / „Cache leeren” im jeweiligen Dashboard.
Tipp: Cloudflares „Entwicklermodus” (Development Mode) schaltet das CDN-Caching für drei Stunden komplett ab — praktisch, während du aktiv an der Seite arbeitest.
Ebene 4: Browser-Cache
Erst ganz zum Schluss dein eigener Browser. Er speichert CSS, Bilder und Skripte lokal, damit die Seite bei dir schneller lädt — zeigt dir dadurch aber gerne die alte Version:
- Hartes Neuladen: Strg + F5 (Windows) bzw. Cmd + Shift + R (Mac). Lädt die Seite ohne Browser-Cache.
- Sicher testen: ein privates/Inkognito-Fenster öffnen — dort ist der Browser-Cache leer und keine Erweiterungen stören.
Wichtig: Der Browser-Cache betrifft nur dich, nicht deine Besucher. Wenn du die Änderung im Inkognito-Fenster siehst, im normalen aber nicht, war es nur dein Browser — dann musst du an den Server-Ebenen gar nichts machen.
Sonderfall Divi: statische CSS-Dateien
Nutzt du das Divi-Theme, kommt eine eigene Ebene dazu: Divi schreibt das berechnete CSS in statische Dateien, statt es bei jedem Aufruf neu zu erzeugen (gut für die Performance). Nach Design-Änderungen, die „nicht durchschlagen”, leerst du diesen Cache separat — in Divi 5 mit einem Klick:
Divi → Theme-Optionen öffnen und oben rechts auf „CSS-Cache leeren” klicken.
Genau dieser Schritt fehlt vielen Divi-Nutzern und sorgt für stundenlange Fehlersuche. Er taucht auch in unseren Divi-Anleitungen immer wieder auf — etwa beim Übersetzen der Divi-Oberfläche oder bei Performance-Optimierung. Den kompletten Überblick gibt der Divi-5-Tutorial-Hub.
Schnelltest: Welche Ebene klemmt?
Bevor du dich durch alle Ebenen arbeitest, grenze in 30 Sekunden ein, wo das Problem sitzt:
- Öffne die Seite im Inkognito-Fenster. Siehst du die Änderung? → Es war nur dein Browser-Cache, fertig.
- Immer noch alt? Dann liegt es an einer Server-Ebene. Leere in dieser Reihenfolge: Caching-Plugin → Server/Hosting → CDN. Nach jedem Schritt im Inkognito-Fenster neu prüfen.
- Divi-Design-Änderung betroffen? Zusätzlich die statische CSS-Generierung leeren.
Diese Reihenfolge — von innen nach außen, nach jedem Schritt prüfen — spart dir das planlose „alles leeren und hoffen”. Und sie zeigt dir, welche Ebene beim nächsten Mal zuerst dran ist.
Meine Einschätzung als Agenturinhaber: Caching ist mit Abstand der häufigste Grund für „Ich hab’s geändert, aber es passiert nichts”-Anfragen. Der Denkfehler ist fast immer derselbe: Man denkt an einen Cache, dabei sind es mehrere. Wer das Schichten-Modell einmal verstanden hat, löst 90 % dieser Fälle in einer Minute selbst — und ruft nicht mehr in Panik die Agentur an.
Was in den Top-10-Google-Ergebnissen zu „WordPress Cache leeren” steht
Die Suchergebnisse zu diesem Keyword haben eine auffällige Lücke:
1. Fokus auf genau ein Plugin. Die meisten Treffer (überwiegend Hosting- und Plugin-Blogs) zeigen den „Cache leeren”-Button ihres Plugins und lassen es dabei bewenden — als gäbe es nur eine Cache-Ebene. Genau das führt in die Irre, wenn zusätzlich ein Server- oder CDN-Cache aktiv ist.
2. Server- und CDN-Ebene fehlen oder kommen zu kurz. Der häufigste Grund, warum „Cache leeren” scheinbar nicht wirkt — ein Server- oder Cloudflare-Cache dahinter — wird selten sauber erklärt. Dabei ist das in der Praxis die Ebene, an der die meisten hängenbleiben.
3. Kein Diagnose-Ansatz. Kaum ein Tutorial zeigt, wie man mit einem simplen Inkognito-Test herausfindet, welche Ebene überhaupt das Problem ist. Ohne diesen Test leert man planlos alles.
4. Divi/Theme-Static-CSS wird übergangen. Für die große Zahl an Divi-Seiten fehlt der entscheidende Extra-Schritt fast immer — und kostet Nutzer regelmäßig Stunden.
Deshalb dieser Artikel: nicht ein Button, sondern das vollständige Schichten-Modell — plus der Schnelltest, der dir sagt, wo du überhaupt ansetzen musst.
FAQ
Warum werden meine WordPress-Änderungen nicht angezeigt?
Fast immer liefert ein Cache die alte Version aus. Prüfe zuerst im Inkognito-Fenster: Siehst du die Änderung dort, war es nur dein Browser-Cache. Wenn nicht, leere Caching-Plugin, Server-/Hosting-Cache und ggf. CDN — in dieser Reihenfolge.
In welcher Reihenfolge sollte ich Caches leeren?
Von innen nach außen: 1. Caching-Plugin, 2. Server-/Hosting-Cache, 3. CDN (z. B. Cloudflare), 4. Browser. Sonst füllt eine äußere Ebene die innere sofort wieder mit der alten Version — und du drehst dich im Kreis.
Wie leere ich den Cache, wenn ich kein Caching-Plugin habe?
Dann kommt der Cache von einer anderen Ebene: entweder vom Hosting (viele Hoster cachen serverseitig), von einem CDN wie Cloudflare oder nur von deinem Browser. Der Inkognito-Test zeigt dir in Sekunden, welche davon es ist.
Wie leere ich den Divi-Cache?
Divi speichert CSS in statischen Dateien. In Divi 5 leerst du sie mit dem Button „CSS-Cache leeren” oben rechts unter Divi → Theme-Optionen. Danach zusätzlich dein normales Caching-Plugin und den Browser-Cache leeren.
Muss ich den Cache nach jeder Änderung leeren?
Nein. Die meisten Caching-Plugins erkennen Änderungen an Seiten/Beiträgen und leeren den betroffenen Cache automatisch. Manuell leeren musst du vor allem bei Änderungen an Theme, CSS, Menüs oder Widgets — also dort, wo das Plugin die Änderung nicht selbst mitbekommt.
Ist Caching schlecht für meine Website?
Im Gegenteil — richtig eingesetzt ist Caching einer der wirksamsten Performance-Hebel. Es sorgt nur gelegentlich für Verwirrung, wenn Änderungen nicht sofort sichtbar sind. Das Schichten-Modell aus diesem Artikel löst genau dieses Problem.
Verwandte Ratgeber
- → Divi 5 langsam? Performance & PageSpeed optimieren
- → WordPress Seite duplizieren
- → WordPress Menü erstellen
- → WordPress Login – sicher anmelden
- → Divi 5 Tutorial-Hub
Brauchst du Hilfe?
Kostet dich WordPress-Technik wie Caching regelmäßig Nerven – oder willst du eine Website, um die du dich technisch gar nicht kümmern musst? Im kostenlosen Erstgespräch schauen wir uns deinen Fall an.
Über den Autor: Moritz Lehmann ist Geschäftsführer von Adfera (M.Sc. Wirtschaftsinformatik) und hat seit 2019 hunderte WordPress-Websites für KMU gebaut, gewartet und migriert.