Cloudflare-Cache steuern
MCP Abilities – Cloudflare: erst die veraltete Kopie finden, dann den Cache leeren
Sie haben eine Seite korrigiert, doch ein Besucher sieht noch die Fassung von gestern. Möglicherweise hält Cloudflare eine eigene Kopie vor. Mit dieser MCP-Erweiterung für WordPress prüfen Sie die öffentliche Antwort, wählen den Löschumfang und kontrollieren die Seite erneut.
Eine Seite kann in mehreren Caches liegen
Auf einer WordPress-Website wurde die Anfangszeit eines Kurses geändert. Besucher sehen trotzdem noch die alte Uhrzeit. Prüfen Sie zuerst den gespeicherten Seiteninhalt. Unterscheiden Sie anschließend zwischen dem Cache des WordPress-Servers, dem Edge-Cache von Cloudflare und dem Browser-Cache.
Ein Cloudflare-Purge entfernt die dort gespeicherten Objekte. Er speichert keine noch ungesicherten Inhalte und leert keinen Browser-Cache. Liefert der Ursprungsserver weiterhin eine alte Kopie, kann Cloudflare dieselbe alte Kopie erneut abrufen.
Die URL-Prüfung meldet Header wie CF-Cache-Status, Age und Cache-Control. Den Seitentext vergleicht sie nicht. Lesen Sie deshalb auch die eigentliche Antwort: Der Cache-Status allein belegt nicht, dass die Uhrzeit stimmt.
Die türkis markierte Kopie am Ursprung wurde geändert. Die gelb markierten Kopien im Edge-Cache und Browser sind älter. Jede Ebene braucht eine eigene Prüfung.
Eine Seitenadresse kann einen ganzen Zweig erfassen
Seiten-URLs ohne Dateiendung oder mit .html wandelt die Erweiterung in Präfix-Purges um, sofern sie keine Abfragezeichenfolge enthalten. Ressourcen-URLs und URLs mit Abfragezeichenfolge bleiben exakte URL-Purges. Das Ergebnis führt die automatischen Präfixumwandlungen auf.
Ein Präfix wie example.com/classes/ erfasst auch zwischengespeicherte Ressourcen unterhalb dieses Pfads. Gemeint ist ein Zweig der Website, keine einzelne Datei. Prüfen Sie Hostname, Sprachpfad und abschließenden Schrägstrich vor der Auswahl.
Purges nach Host, Cache-Tag oder ganzer Zone erfassen größere Gruppen. Cloudflare unterstützt diese Verfahren in allen Tarifen, mit kontobezogenen Limits. Eigene Cache-Schlüssel können zusätzliche Header erfordern, die das reine Zeichenfolgenformat der Dateieingabe dieser Erweiterung nicht liefern kann. Wählen Sie einen geeigneten unterstützten Umfang.
Der hervorgehobene Zweig zeigt den Löschumfang. Untergeordnete Ressourcen gehören dazu; der andere Zweig liegt außerhalb.
Prüfen, eingrenzen, leeren und nachkontrollieren
1. Quelle und Zone bestätigen
Prüfen Sie den gespeicherten WordPress-Inhalt und die genaue öffentliche URL. Lesen Sie vor einer Änderung aus, welche Cloudflare-Zone verbunden ist. Auch eine erfolgreich authentifizierte Verbindung zur falschen Zone bleibt das falsche Ziel.
2. Antwort auswerten
Prüfen Sie Cache-Einstellungen, Regeln und Header der betroffenen URL. Die Prüfung verarbeitet höchstens 20 URLs und ruft jede standardmäßig zweimal ab. Kontrollieren Sie jeden Versuch samt HTTP-Status. Der übergeordnete Erfolgswert bedeutet lediglich, dass die Prüfung abgeschlossen wurde.
3. Den kleinsten geeigneten Umfang wählen
Setzen Sie für einen gezielten Purge ausdrücklich purge_everything: false und übergeben Sie geprüfte URLs oder Präfixe. Lesen Sie die gemeldeten Vorgänge, einschließlich bereits abgeschlossener Vorgänge, wenn eine spätere Anfrage scheitert.
4. Die ausgelieferte Seite kontrollieren
Rufen Sie die öffentliche Seite erneut ab und prüfen Sie den geänderten Text oder das Bild. Ein erfolgreicher Cloudflare-Purge bestätigt die Annahme der Anfrage, nicht den korrekten Inhalt vom Ursprungsserver. Prüfen Sie Browser-Cache und lokale Caches getrennt, falls die alte Fassung weiterhin erscheint.
Cache-Einstellungen gesondert beurteilen
Der Entwicklungsmodus umgeht das Cloudflare-Caching vorübergehend, löscht aber keine gespeicherten Dateien. Cloudflare deaktiviert ihn normalerweise nach drei Stunden. Lesen Sie vor einer Änderung seinen Zustand aus. Wenn eine gespeicherte Kopie entfernt werden soll, verwenden Sie einen Purge.
Die Aktion für HTML-Cache-Regeln zeigt standardmäßig eine Vorschau der Änderung. Die Regel gilt für den gewählten Host und nimmt mehrere übliche WordPress-Pfade und Cookies aus. Sie kann die Cache-Anweisungen des Ursprungsservers überschreiben. Eine Vorschau beweist deshalb nicht, dass private Seiten geschützt sind.
Prüfen Sie eigene Anmelde-, Konto-, Kassen- und personalisierte Routen, bevor Sie HTML-Caching aktivieren. Eigene Ausnahmen erfassen den gewählten Pfad und seine Unterpfade. Prüfen Sie den erzeugten Ausdruck und testen Sie die tatsächlichen Routen und Cookies, bevor Sie die Regel anwenden.
Nach einer abgeschlossenen Plugin-Installation oder -Aktualisierung versucht die Erweiterung außerdem, das Wurzelpräfix des öffentlichen Hosts zu leeren. Berücksichtigen Sie diesen Automatismus bei Änderungen: Er reicht weiter als das Leeren einer einzelnen Seite.
Die richtige WordPress-Website und Cloudflare-Zone verbinden
Die angegebenen Mindestversionen sind WordPress 6.9 und PHP 8.0. WordPress 6.9 enthält die Abilities API. Verwenden Sie eine gepflegte PHP-Version, eine authentifizierte MCP-Adapter-Verbindung und ein WordPress-Konto mit Berechtigung zur Verwaltung der Website-Optionen.
Der Cloudflare-API-Zugriff benötigt ein geeignetes Token oder einen Schlüssel für die vorgesehene Zone und die gewünschten Aktionen. Das offizielle Cloudflare-Plugin für WordPress kann die Zugangsdaten bereitstellen. Unterstützte WordPress-Konstanten sind eine weitere Möglichkeit.
Die Aktion zur Einrichtung der Zugangsdaten setzt das offizielle Plugin und eine exakt vorgegebene Bestätigung voraus. Sie prüft den Zonenzugriff vor dem Speichern und gibt die Zugangsdaten nicht zurück. Das belegt nicht, dass das Token sämtliche Cache- und Regelberechtigungen besitzt. Prüfen Sie, ob die benötigten Aktionen in der MCP-Funktionserkennung erscheinen.
Das Verhalten des Anbieters und aktuelle Grenzen erläutern Cloudflares Purge-Dokumentation, die Anleitung zum Entwicklungsmodus und die Einstellungen für Cache-Regeln.
Beginnen Sie mit der Seite, die veraltet erscheint
Installieren Sie die Erweiterung, bestätigen Sie die verbundene Zone und prüfen Sie die betroffene URL. Wählen Sie den Löschumfang anhand der Ergebnisse. Kontrollieren Sie danach die Seite, die Besucher tatsächlich erhalten.