Ein Team leert nach jeder kleinen Änderung alle WordPress-Caches. Danach steigen CPU-Last und Antwortzeiten, weil Tausende Seiten gleichzeitig neu aufgebaut werden. Bei einem globalen Menüwechsel vergisst es die Löschung dagegen ganz, und das CDN zeigt stundenlang die alte Navigation.
Cache-Löschung ist weder Routineknopf noch Reparatur für jeden Fehler. Sie sollte auf eine bekannte Änderung und den kleinsten betroffenen Bereich zielen.
Was darunter zu verstehen ist
Beim Leeren beziehungsweise Invalidieren werden gespeicherte Einträge vor Ablauf ihrer normalen Frische ungültig. Der Umfang kann eine URL, eine Gruppe, ein Objekt-Namensraum, die gesamte Website oder eine CDN-Zone betreffen.
Das ist sinnvoll, wenn Inhalt, Code oder Konfiguration geändert wurden und die automatische Invalidierung nicht alle abhängigen Einträge erreicht. Einen falschen Datenbankwert oder defekten Ursprung behebt die Löschung nicht.
Praxisbeispiel
Eine Änderung am globalen Header betrifft viele Seiten. Nachdem neue Dateien und Templates vollständig bereitstehen, werden die zugehörigen Seiten- und Edge-Einträge invalidiert. Ein einzelner korrigierter Beitrag benötigt dagegen nur eine gezielte URL-Löschung.
So bleibt der Cache größtenteils warm, während die betroffenen Besucher sofort den neuen Stand erhalten.
Warum die Unterscheidung wichtig ist
Zu seltenes Leeren liefert veraltete Inhalte. Zu häufiges vollständiges Leeren erzeugt Kaltstartspitzen und verdeckt eine kaputte Invalidierung. Die Wahl von Zeitpunkt und Umfang ist daher Teil der Bereitstellung.
Wiederholtes „Purge All“ nach normalen Veröffentlichungen ist ein Hinweis darauf, dass Schlüssel, Tags oder Versionierung repariert werden sollten.
Ein einfacher und sicherer Einstieg
- Benennen Sie die Änderung und die tatsächlich betroffenen Seiten oder Objekte.
- Bestätigen Sie mit einer sauberen Anfrage, welche Cache-Ebene den alten Stand liefert.
- Nutzen Sie URL-, Tag-, Gruppen- oder Komponenten-Löschung, wenn verfügbar.
- Löschen Sie erst, wenn der neue Ursprungscode und alle Dateien bereitstehen.
- Prüfen Sie anschließend Inhalt, Cache-Status und Fehlerquote.
Technische Prüfung
In mehrschichtigen Systemen wird nur dort invalidiert, wo alte Einträge liegen. Arbeiten Sie von der datenliefernden Ebene nach außen und vermeiden Sie, dass eine Edge den alten Ursprung direkt nach der Löschung erneut speichert.
Bei einer breiten Änderung kann ein begrenztes Vorwärmen kritischer Seiten Lastspitzen abfangen. Dokumentieren Sie Auslöser, Umfang, Löschkennung, Dauer und Auswirkung auf den Ursprung.
Risiken, häufige Fehler, Backup und Rollback
Eine Gesamtlöschung kann bei hohem Verkehr den Ursprung überlasten. Sie kann außerdem den Eindruck erwecken, ein Fehler sei behoben, obwohl er nach dem nächsten Ablauf zurückkehrt.
- Löschen Sie nicht vor Abschluss des Deployments.
- Planen Sie breite Purges nur mit ausreichender Ursprungskapazität.
- Bewahren Sie die bisherige Invalidierungsregel und einen Bypass für Störungen auf.
So unterstützt AIOWS:
AIOWS Cache Manager
AIOWS Cache Manager bietet eine zentrale WordPress-seitige Stelle, um Cache-Einträge im passenden Umfang zu verwalten. Das ist vor allem bei redaktionellen Änderungen hilfreicher als eine pauschale Löschung aller Ebenen.
Vor dem Leeren sollte klar sein, ob der alte Inhalt aus WordPress, dem Hosting-Cache oder einem CDN stammt. AIOWS kann externe Edge-Einträge nicht automatisch als Ursache bestätigen. Kontrollieren Sie deshalb die öffentlichen Header und verwenden Sie beim jeweiligen Anbieter dessen gezielte Löschfunktion.
Ist eine breite WordPress-seitige Invalidierung notwendig, beobachten Sie danach Antwortzeit und Fehlerquote. Wiederholt sich das Problem, korrigieren Sie die zugrunde liegende Regel, statt das Leeren zum Dauerprozess zu machen. Der vorherige Zustand und die Kapazitätsgrenzen des Ursprungs bleiben dokumentiert.
Passende AIOWS-Artikel
- WordPress-Cache leeren: Seiten-, Objekt-, Browser- und CDN-Cache
- WordPress-Seiten-Cache sicher aktivieren
- Cache-Control-Header in WordPress erklärt
Fazit und Empfehlung
Leeren Sie den Cache nach einer bekannten Änderung, wenn tatsächlich alte Einträge übrig sind. Wählen Sie den kleinsten wirksamen Umfang, stimmen Sie die Löschung auf das Deployment ab und beobachten Sie den Kaltstart. Regelmäßige Komplettlöschungen sind ein Fehlerbild, keine Strategie.
