Ihr CDN-Dashboard zeigt ein grünes Licht an, Ihr Geschwindigkeitswert ist gestiegen, also gehen Sie davon aus, dass Ihre Seiten aus dem Cache bereitgestellt werden. Oft ist dies jedoch nicht der Fall, und die Überprüfungstools, die Ihnen mitteilen, dass “Ihr CDN funktioniert”, belegen lediglich, dass Ihre Bilder im Cache gespeichert sind – was aber nie die Frage war.
In dieser Anleitung erfahren Sie, wie Sie überprüfen können, ob Ihr CDN tatsächlich Ihre Seiten und nicht nur Ihre Assets zwischenspeichert: welcher Header aussagekräftig ist, was die einzelnen Werte bedeuten und was Sie tun können, wenn Ihr HTML bei jeder Anfrage unbemerkt an den Ursprungsserver weitergeleitet wird.
Wichtigste Erkenntnisse
- Ein CDN speichert standardmäßig Ihre CSS-, JS- und Bilddateien im Cache, nicht jedoch Ihre HTML-Seiten. Daher bedeutet “my assets HIT” nicht, dass Ihre Seiten im Cache gespeichert sind.
- Lesen Sie den Cache-Status-Antwortheader (
cf-cache-status(auf Cloudflare) auf der Seite selbst, mitcurl -Ioder auf der Registerkarte „Netzwerk“ des Browsers: „HIT“ bedeutet „Cache“, „DYNAMIC“ oder „BYPASS“ bedeutet, dass die Anfrage an den Ursprungsserver weitergeleitet wurde. - „DYNAMIC“ bedeutet, dass das CDN die Seite nie als zwischenspeicherbar eingestuft hat; „BYPASS“ bedeutet, dass dies der Fall gewesen wäre, aber ein Cookie oder ein
Cache-ControlDie Kopfzeile hat das verhindert. - Die
AlterDieser Header erscheint nur in einer zwischengespeicherten Antwort und nimmt umso größere Werte an, je länger das Objekt im Cache verbleibt; daher ist er der eindeutigste Beweis dafür, dass eine Seite tatsächlich vom Edge-Server bereitgestellt wird. - In einem WooCommerce-Shop muss man auch das Gegenteil überprüfen: Warenkorb, Kasse und „Mein Konto“ dürfen NICHT zwischengespeichert werden, da sonst die Sitzung eines Kunden an den nächsten weitergegeben wird.
So überprüfen Sie, ob Ihr CDN eine Seite tatsächlich zwischenspeichert
Rufen Sie die Seite auf und lesen Sie den Antwort-Header zum Cache-Status. Bei Cloudflare lautet dieser Header cf-cache-status: „HIT“ bedeutet, dass die Seite aus dem Cache des CDN bereitgestellt wurde, „MISS“ oder „EXPIRED“ bedeutet, dass diesmal auf Ihren Ursprungsserver zurückgegriffen wurde, und „DYNAMIC“ oder „BYPASS“ bedeutet, dass das CDN die Seite überhaupt nicht aus dem Cache bereitgestellt hat.
Am schnellsten lässt sich das mit einem einzigen Befehl in Ihrem Terminal anzeigen:
curl -sI https://yoursite.com/ | grep -i cf-cache-statusDer Name des Headers variiert je nach Anbieter (Fastly verwendet x-cache, ein LiteSpeed-Server-Cache verwendet x-litespeed-cache, (KeyCDN und andere verwenden ihre eigenen), aber das Prinzip ist dasselbe: Man liest den Cache-Status-Header aus, den der eigene Stack zurücksendet.
Hier liegt der Haken – und genau das ist der Grund, warum es diesen Leitfaden überhaupt gibt. Wenn Sie dieselbe Überprüfung bei einem Bild oder einem Stylesheet durchführen, wird fast immer „HIT“ angezeigt, da CDNs diese standardmäßig zwischenspeichern. Dieses Ergebnis sagt jedoch nichts über Ihre Seiten aus. Also Testen Sie die URL der Seite, nicht das Logo.
Bevorzugen Sie einen Browser? Öffnen Sie die Seite, drücken Sie F12, wechseln Sie zur Registerkarte „Netzwerk“, laden Sie die Seite neu, klicken Sie dann auf die allererste Anfrage – das ist das HTML-Dokument selbst – und lesen Sie cf-cache-status unter „Response Headers“. Achten Sie darauf, dass Sie auf die oberste Dokumentzeile klicken und nicht auf ein Bild oder Skript darunter, sonst müssen Sie die Assets erneut überprüfen.
Die 30-Sekunden-Cache-Prüfung
- Führen Sie den Befehl „curl -I“ mit der URL einer echten Seite aus (kein Bild).
- Den Cache-Status-Header auslesen (cf-cache-status bei Cloudflare)
- „HIT“ oder „REVALIDATED“ bedeutet, dass die Seite aus dem Cache stammt.
- „DYNAMIC“ oder „BYPASS“ bedeutet, dass es jedes Mal zu Ihrer Quelle weitergeleitet wurde.
- Überprüfen Sie dies anhand des „Age“-Headers, der nur in einer zwischengespeicherten Antwort angezeigt wird.
Warum Ihre Bilder zwischengespeichert werden, Ihre HTML-Seiten jedoch in der Regel nicht
Ein CDN speichert statische Dateien nach Dateiendung im Cache und lässt Ihre HTML-Dateien unberührt. In Mit den Worten von Cloudflare, “Das Cloudflare-CDN speichert HTML- oder JSON-Dateien standardmäßig nicht im Cache.” Die Standardliste umfasst CSS, JS, JPG, PNG, WEBP, WOFF2, PDF und Dutzende weitere Formate, jedoch nicht .html und es gibt keine Regel, die eine Seite bereitstellt, sodass Ihre Seiten an den Ursprungsserver weitergeleitet werden, sofern Sie keine Regel hinzufügen.
Aus diesem Grund kann ein “CDN-Cache-Checker” einer Website, deren Seiten gar nicht im Cache gespeichert sind, eine positive Bewertung geben. Das Tool ruft eine Datei ab, erkennt einen „HIT“ und meldet einen Erfolg. Unterdessen sind Ihre eigentlichen Seiten – jene langsamen, datenbankgestützten Seiten, die Sie eigentlich im Cache haben wollten –, Besuchen Sie bei jedem Besuch weiterhin Ihren Ursprungsort.
Die Aufteilung lässt sich auf echten Websites erkennen. Hier sind echte Header-Auslesungen, die ich bei drei öffentlichen Websites durchgeführt habe, die alle über Cloudflare laufen:
$ curl -sI https://kinsta.com/ | grep -i cf-cache-status
cf-cache-status: DYNAMIC
$ curl -sI https://wpengine.com/ | grep -i cf-cache-status
cf-cache-status: DYNAMIC
$ curl -sI https://yoast.com/ | grep -iE 'cf-cache-status|age'
cf-cache-status: HIT
age: 22Zwei davon stellen ihre HTML-Inhalte DYNAMISCH direkt vom Ursprungsserver bereit, und einer speichert sie am Rand mit einem echten, steigenden Alter. Gleiches CDN, gegensätzliche Ergebnisse – und die einzige Möglichkeit herauszufinden, zu welcher Gruppe Ihre Website gehört, besteht darin, den Header Ihrer eigenen Seite zu lesen. (Echte Screenshots, Juli 2026; öffentliche Websites, Header sind öffentlich einsehbar.)
Was die einzelnen Werte von „cf-cache-status“ bedeuten und wie man darauf reagieren sollte
Hier sind alle cf-cache-status Wert, was Cloudflare damit meint und welche Maßnahme daraus folgt. Die Prüftools zeigen Ihnen den Wert an; die Spalte „Maßnahme“ wird dabei jedoch ausgelassen.
| Wert | Was Cloudflare damit meint | Was kann man dagegen tun? |
|---|---|---|
| HIT | “Die Ressource wurde im Cache von Cloudflare gefunden.” | Funktioniert wie vorgesehen. Bitte überprüfen Sie, ob der „Age“-Wert steigt, damit es sich um einen echten, dauerhaften Cache handelt. |
| MISS | “Die Ressource wurde im Cache von Cloudflare nicht gefunden und wurde vom Ursprungswebserver bereitgestellt.” | Beim ersten Aufruf „Normal“. Neu laden; wenn nie „HIT“ angezeigt wird, wird die Seite nicht zwischengespeichert. |
| ABGELAUFEN | “Die Ressource wurde im Cache von Cloudflare gefunden, war jedoch abgelaufen und wurde vom Ursprungsserver bereitgestellt.” | In Maßen ist das in Ordnung. Die ständige Meldung „EXPIRED“ bedeutet, dass Ihre TTL für die Seite zu kurz ist. |
| NEU BESTÄTIGT | Die Quelle bestätigte, dass die zwischengespeicherte Kopie unverändert ist und aus dem Cache bereitgestellt wurde. | Funktioniert. Der Edge-Server hat die Übereinstimmung mit dem Ursprungsserver überprüft und die im Cache gespeicherte Seite wiederverwendet. |
| DYNAMISCH | “Cloudflare betrachtet das Asset nicht als für die Zwischenspeicherung geeignet, und Ihre Cloudflare-Einstellungen weisen Cloudflare nicht ausdrücklich an, das Asset zwischenzuspeichern.” | Die Standardeinstellung für HTML. Fügen Sie eine Cache-Regel hinzu, wenn diese Seite zwischengespeichert werden soll. |
| BYPASS | Die Quelle wies Cloudflare an, den Cache zu überspringen, und zwar über Cache-Control, oder die Antwort setzt ein Cookie. | Finde das Cookie oder den Header, der die Seite deaktiviert; korrigiere dies für den Warenkorb und die Anmeldung – es handelt sich um einen Fehler an anderer Stelle. |
| VERALTET | Wurde aus dem Cache bereitgestellt, obwohl die Gültigkeitsdauer abgelaufen war, da Cloudflare den Ursprungsserver nicht erreichen konnte. | Überprüfen Sie den Status Ihres Ursprungsservers; der Edge-Server springt für einen Server ein, der nicht geantwortet hat. |
| AKTUALISIERUNG | Die Gültigkeit ist abgelaufen, wird jedoch aus dem Cache bereitgestellt, während die Ursprungsseite sie im Hintergrund aktualisiert. | Unmittelbar nach Ablauf unter Last im Normalzustand. Keine Maßnahme erforderlich. |
| KEINE / UNBEKANNT | Cloudflare hat eine Antwort generiert, die nicht für das Caching in Frage kommt (ein Worker, eine Weiterleitung, eine WAF-Regel). | Die Anfrage wurde beantwortet, bevor sie den Cache erreichte; das ist auf diesen Routen zu erwarten. |
Ein weiterer Header leistet hier im Hintergrund ganze Arbeit: Alter. Cloudflare gibt diesen Wert nur “für aus dem Cache gelieferte Antworten” zurück; er gibt die Anzahl der Sekunden an, die das Objekt bereits im Cache gespeichert ist, und wird bei einer Löschung oder Neuvalidierung zurückgesetzt. Ein wachsender Alter Das ist der eindeutigste Beweis dafür, dass eine Seite tatsächlich direkt vom Server stammt, und das Fehlen dieser Seite auf einer Seite, von der Sie erwartet hätten, dass sie zwischengespeichert ist, ist das eindeutige Anzeichen dafür, dass dies nicht der Fall ist.
Was „cf-cache-status DYNAMIC“ bedeutet und wie es sich von „BYPASS“ unterscheidet
“DYNAMIC” bedeutet, dass das CDN die Seite nie als zwischenspeicherbar eingestuft hat und sie daher von Ihrem Ursprungsserver abgerufen hat. Nach den Angaben von Cloudflare war das Asset „nicht für den Cache geeignet“, und Ihre Einstellungen haben dem System nichts anderes mitgeteilt. Dies ist der Standardzustand einer HTML-Seite ohne Cache-Regel, und genau deshalb suchen so viele Menschen danach: Sie haben das CDN aktiviert, auf jeder Seite „DYNAMIC“ gesehen und angenommen, dass etwas nicht funktioniert.
BYPASS ist eine ganz andere Sache. Cloudflare würde hat die Seite zwischengespeichert, aber Ihr Ursprungsserver hat dies ausdrücklich untersagt, entweder durch einen Cache-Control Kopfzeile eingestellt auf no-cache, privat, oder max-age=0, oder weil die Antwort ein Cookie gesetzt hat. Cloudflare speichert keine Antwort im Cache, die ein Set-Cookie Kopfzeile, so vorgesehen.
Der praktische Unterschied entscheidet über Ihre Lösung. DYNAMIC ist eine Konfigurationslücke: Sie haben dem CDN einfach noch nicht mitgeteilt, dass HTML zwischengespeichert werden soll; die Lösung ist also eine Cache-Regel. BYPASS ist eine Option auf der Seite, mit der man sich abmelden kann: Die Lösung besteht darin, das Cookie oder das Cache-Control Header-Eintrag sorgt dafür. Auf einer normalen Seite ist in der Regel ein verirrtes Session-Cookie die Ursache; auf einer Warenkorb- oder Checkout-Seite ist dieser „BYPASS“-Eintrag korrekt und sollte unverändert bleiben.
So speichern Sie Ihre HTML-Seiten bei Cloudflare im Cache, ohne dass dabei etwas schiefgeht
Um HTML zwischenzuspeichern, fügen Sie eine Cache-Regel hinzu, die die entsprechenden URLs als “Für den Cache geeignet” kennzeichnet (das ältere Äquivalent war eine Seitenregel vom Typ “Alles zwischenspeichern”). Der Fehler besteht darin, die Regel blind auf Ihre gesamte Website anzuwenden, da dadurch auch Seiten erfasst werden, die benutzerspezifisch bleiben müssen. Beschränken Sie den Geltungsbereich der Regel auf die Seiten, die sicher zwischengespeichert werden können, und lassen Sie die persönlichen Seiten außen vor – genau das ist die WooCommerce-Falle, die im nächsten Abschnitt behandelt wird.
Es ist außerdem hilfreich, die Standardeinstellungen von Cloudflare zu kennen. Wenn Ihr Ursprungsserver keine Cache-Control oder Gültig bis Header: Cloudflare speichert einen 200-, 206- oder 301-Status für 120 Minuten, einen 302- oder 303-Status für 20 Minuten und einen 404- oder 410-Status für nur 3 Minuten im Cache; alles andere wird nicht zwischengespeichert. Ein kurzlebiger Cache auf einer Seite, von der man erwartet hätte, dass er bestehen bleibt, ist also oft nur darauf zurückzuführen, dass der Ursprungsserver nicht antwortet und Cloudflare auf die Standarddauer von zwei Stunden zurückgreift.
Gut zu wissen: Bei den Tarifen „Free“, „Pro“ und „Business“, die von den meisten WordPress-Betreibern genutzt werden, berücksichtigt Cloudflare bereits die Cache-Control die von Ihrer Quelle gesendet werden. Wenn Ihre Seiten also nicht zwischengespeichert werden, muss der Header in Ihrem eigenen Stack (oder Ihrem WordPress-Cache und Optimierungsschicht) ausstößt, ist der erste Ansatzpunkt, und curl -I legt es dir direkt vor die Nase.
Stellen Sie in einem WooCommerce-Shop sicher, dass der Warenkorb und der Bezahlvorgang NICHT zwischengespeichert werden
In einem Online-Shop überprüfen Sie zwei gegensätzliche Aspekte gleichzeitig: dass normale Seiten im Cache gespeichert werden (HIT) und dass Warenkorb, Kasse und „Mein Konto“ NICHT im Cache gespeichert werden (BYPASS oder DYNAMIC). Ein Online-Shop, bei dem alles als „HIT“ gezählt wird, weist mehr Fehler auf als einer, bei dem nichts als „HIT“ gezählt wird, da eine zwischengespeicherte Seite für angemeldete Nutzer den Warenkorb und die Sitzung eines Kunden direkt an den nächsten Besucher weitergeben kann.
WooCommerce legt eindeutig fest, welche Seiten dynamisch bleiben müssen. Gemäß dessen eigene Caching-Richtlinien, mit Ausnahme von “Warenkorb”, „Zur Kasse“ und „Mein Konto“, da „diese Seiten dynamisch bleiben müssen, da sie Informationen anzeigen, die für den jeweiligen Kunden und dessen Warenkorb spezifisch sind“. Die Cookies, die eine persönliche Sitzung kennzeichnen und die Ihr Cache unter keinen Umständen zwischenspeichern darf, sind:
woocommerce_cart_hashundwoocommerce_items_in_cart, die WooCommerce mitteilen, wenn sich der Inhalt des Warenkorbs ändert.wp_woocommerce_session_, das jeden Kunden mit seinen Warenkorbdaten in der Datenbank verknüpft.woocommerce_recently_viewed, das das Widget „Zuletzt angesehene Produkte“ steuert.
Gute Cache-Plugins übernehmen das für Sie: WP Rocket schließt diese drei Seiten automatisch aus, sobald es WooCommerce erkennt, und WooCommerce weist WP Super Cache aktiv an, “Warenkorb”, „Kasse“ und „Mein Konto“ zu überspringen. Eine manuell erstellte „Alles zwischenspeichern“-Regel im CDN berücksichtigt dies jedoch nicht – und genau darin liegt die Gefahr.
Die Überprüfung erfolgt über denselben Befehl und bezieht sich auf die Seiten, die privat bleiben müssen:
curl -sI https://yourstore.com/cart/ | grep -i cf-cache-statusAuf der Warenkorbseite SOLLTEN Sie „BYPASS“ oder „DYNAMIC“ sehen. Wenn dort „HIT“ steht, sollten Sie sofort Ihre Cache-Regel korrigieren, bevor ein Kunde den Warenkorb eines anderen Kunden zu sehen bekommt. Es ist der einzige Ort, an dem ein Treffer ein Fehlschlag ist.
Was die Kopfzeilen unserer eigenen Website tatsächlich anzeigen
Hier ist ein echter Auszug aus unserer eigenen Website, der einen wichtigen Punkt auf den Punkt bringt. wpconsults.com nutzt Cloudflare überhaupt nicht vor seinem HTML; stattdessen wird ein LiteSpeed-Server-Seiten-Cache verwendet, daher lautet der zu beachtende Header x-litespeed-cache, nicht cf-cache-status:
$ curl -sI https://www.wpconsults.com/ | grep -iE 'x-litespeed-cache|server'
x-litespeed-cache: Treffer
server: LiteSpeedDas Treffer bedeutet, dass die Seite aus dem eigenen Seitencache des Servers bereitgestellt wurde, nicht von einem CDN-Edge-Cache, und dieser Unterschied ist wichtig, da die beiden oft miteinander verwechselt werden. Ein CDN-Edge-Cache (Cloudflare) speichert Ihre Seite in Rechenzentren in der Nähe des Besuchers. Ein Server-Seiten-Cache (LiteSpeed, WP Rocket, WP Super Cache) speichert den gerenderten HTML-Code auf Ihrem eigenen Ursprungsserver, sodass PHP nicht erneut ausgeführt wird. Sie können eine dieser Lösungen, beide oder gar keine verwenden, und jede Ebene verfügt über einen eigenen Status-Header, der ausgelesen werden kann.
Unsere Website läuft auf einem LiteSpeed-basierten Hosting-Angebot von Hostinger, weshalb der Seitencache auf dem Server gespeichert ist und es keinen cf-cache-status zu finden. Die statischen Assets verhalten sich in beiden Fällen so, wie man es erwarten würde:
$ curl -sI https://www.wpconsults.com/wp-content/.../style.css | grep -i cache-control
cache-control: public, max-age=604800Ein leergeräumter Sieben-Tage-Browser-Cache für das Stylesheet – kein Problem. Das ist die übliche Aufteilung: Assets sind zwischenspeicherbar und unspektakulär, Seiten sind die Ebene, die man tatsächlich überprüfen muss.
Warum Ihre Cache-Trefferquote niedriger ist, als Sie erwarten
Selbst wenn das HTML-Caching aktiviert ist, liegt Ihre Cache-Trefferquote – also der Anteil der Anfragen, die aus dem Cache statt vom Ursprungsserver bedient werden – in der Regel unter dem im Dashboard angezeigten Gesamtwert. Dieser Wert wird von Assets dominiert, die ohnehin immer einen Treffer erzielen würden, und schmeichelt Ihnen daher. Die Seiten, auf die es ankommt – die dynamischen –, machen nur einen kleinen Teil aus und sind die ersten, bei denen nach einer Cache-Leerung oder einer Bereitstellung ein „MISS“ auftritt.
Beurteilen Sie das Caching daher anhand der Header-Angaben in Ihren Schablonen für Schlüsselseiten – sei es ein Beitrag, eine Kategorie oder eine Sammlung oder die Startseite – und nicht anhand eines einzigen, für die gesamte Website geltenden Prozentsatzes. Ein hoher Anteil bei DYNAMISCHEN Seiten bedeutet lediglich, dass Ihre Bilder die Hauptlast tragen, während Ihre langsamen Seiten weiterhin den Ursprungsserver abfragen. Das ist auch der Grund, warum der Cache-Status in Ihrer Core Web Vitals und TTFB lange bevor es in einer Gesamtzahl zum Ausdruck kommt.
Also, speichert Ihr CDN Ihre Seiten tatsächlich im Cache?
Ehrlich gesagt lautet die Antwort meistens: “Nicht so, wie du denkst.” Die grüne Ampel und der Geschwindigkeitswert messen deine Ressourcen, und deine Ressourcen waren nie das Problem. Wenn das meine Website wäre, würde ich mir zwei Minuten Zeit nehmen, um curl -I Vergleichen Sie es zunächst mit drei echten Seitenvorlagen – einem Beitrag, einer Kategorie und dem Warenkorb –, bevor Sie einem Dashboard vertrauen, denn die Kopfzeile schmeichelt Ihnen nicht so sehr wie eine Punktzahl.
Konfigurieren Sie das HTML-Caching bewusst, schließen Sie benutzerspezifische Seiten davon aus und überprüfen Sie die Header-Einträge jedes Mal erneut, wenn Sie eine Regel oder ein Plugin ändern. Ein CDN, das alles zwischenspeichert, ist nicht das Ziel, ebenso wenig wie eines, das gar nichts zwischenspeichert; das Ziel ist es, zu wissen, welche Seiten zwischengespeichert werden, und dabei richtig zu liegen. Die Tools zeigen an, dass das CDN aktiv ist. Nur Der Antwort-Header zeigt an, dass alles wie vorgesehen funktioniert, und auf einer stark frequentierten Website ist das der Unterschied zwischen einen Verkehrsansturm überstehen und deinen Ursprung darunter zum Schmelzen zu bringen.
Du bist dir immer noch nicht sicher, was dir deine Kopfzeilen sagen?
Falls Ihr „Cache-Status“-Header einen Wert anzeigt, den Sie sich nicht erklären können, oder Ihre Seiten auf „DYNAMIC“ stehen bleiben und Sie nicht wissen, warum, kontaktieren Sie uns oder E-Mail und ich werde mir das einmal ansehen. Es lohnt sich, dafür zu sorgen, dass deine Seiten aus dem Cache bereitgestellt werden und die falschen Seiten nicht angezeigt werden.
Möchtest du, dass unsere Beiträge öfter bei Google erscheinen?
Ein Schritt – und Google zeigt diese Seite in Ihren „Top Stories“ an.
