Cacheausnahmen anhand von URLs, Cookies und Sitzungen prüfen: präzise Regeln, zwei getrennte Besucherzustände und konkrete Gegenproben.
Eine Cacheausnahme schützt eine Antwort, die sich nicht gefahrlos wiederverwenden lässt. Ein Cookie ist dabei ein Hinweis auf einen Zustand, keine fertige Entscheidung. Entscheidend ist, ob sich Inhalt, Berechtigung oder Aktion tatsächlich ändern. Dieser Leitfaden führt von einer beobachteten persönlichen Ansicht zu einer eng begrenzten, überprüfbaren Regel.
Beginnen Sie mit einer konkreten URL und einem konkreten Unterschied. Zeigt eine Produktseite für alle Besucher denselben Text, ist sie grundsätzlich ein anderer Fall als ein Kundenkonto mit Bestellungen. Eine Wunschliste kann im sichtbaren Seitenteil persönlich sein, obwohl ihr Rahmen öffentlich bleibt. Ein Formular kann gleich aussehen und trotzdem einen sitzungsabhängigen Sicherheitswert enthalten. Aus dem Seitennamen allein lässt sich daher keine zuverlässige Regel ableiten.
Schreiben Sie die gewünschte Antwort in einem Satz auf: Ein nicht angemeldeter Besucher sieht die allgemeine Beratung; ein angemeldeter Kunde sieht seine eigenen Vertragsdaten. Prüfen Sie danach, wo dieser Unterschied entsteht. Wird er bereits in HTML erzeugt, muss die Cacheentscheidung diesen Zustand berücksichtigen. Lädt eine Anwendung persönliche Daten später über einen getrennten Request, sind auch dessen Antwort und Berechtigungsprüfung zu untersuchen. Ein unveränderter HTML-Rahmen beweist keine korrekte API.
Der Überblick über die LSCache-Architektur hilft, die beteiligten Ebenen zu benennen. Browser, CDN und serverseitiger Seitencache können dieselbe URL unterschiedlich behandeln. Eine Ausnahme im WordPress-Plugin darf nicht durch eine pauschale HTML-Regel am vorgeschalteten System wieder aufgehoben werden. Notieren Sie deshalb, welche Schicht die untersuchte Antwort geliefert hat und welche Regel dort wirksam sein soll.
Öffnen Sie die Entwicklerwerkzeuge Ihres Browsers und betrachten Sie die Cookies der betroffenen Domain. Erfassen Sie den Namen, den zugehörigen Pfad, die Laufzeit und den Zeitpunkt, an dem der Cookie entsteht. Dokumentieren Sie keine vollständigen Sitzungswerte in einem öffentlichen Supportticket. Für eine Cacheentscheidung genügt meistens die Bedeutung des Zustands: angemeldet, Warenkorb vorhanden oder eine bestimmte Darstellungsvariante gewählt.
Vergleichen Sie einen frischen Besuch mit dem Zustand nach der relevanten Aktion. Fügen Sie beispielsweise auf einer Testumgebung einen Artikel zur Merkliste hinzu und laden Sie denselben Pfad erneut. Ändert sich der sichtbare Inhalt? Ändert sich nur eine Statistikkennung? Ein Analysecookie ist nicht automatisch ein Grund, den kompletten Seitencache zu umgehen. Umgekehrt kann eine Funktion ohne auffällig benannten Cookie persönliche Ausgabe erzeugen. Beobachtung und Anwendungslogik müssen zusammenpassen.
Ein Cookie mit Sprache oder Währung beschreibt häufig eine kleine, definierte Zahl von Ansichten. Ein Sitzungstoken beschreibt dagegen viele individuelle Zustände. Diese Fälle verlangen unterschiedliche Entscheidungen. Für einen öffentlichen Sprachtext kann eine getrennte Variante sinnvoll sein; eine Bestellübersicht darf nicht durch einen gemeinsamen Sprachcache öffentlich werden. Legen Sie zuerst die zulässigen Inhalte jeder Variante fest. Erst danach entscheiden Sie über einen Vary oder einen Ausschluss.
| Beobachteter Zustand | Möglicher Ansatz | Erforderlicher Nachweis |
|---|---|---|
| Allgemeiner Artikel ohne persönliche Ausgabe | Öffentlicher Seitencache | Identischer Inhalt in unabhängigen Sitzungen |
| Individuelle Kundenübersicht | Ganze Seite ausschließen oder belegter privater Pfad | Keine fremden Daten; Zugriffsschutz bleibt wirksam |
| Öffentliche Ansicht je Sprache | Begrenzte Cachevarianten | Jede Sprache wird richtig getrennt und aktualisiert |
| Persönlicher Bereich in öffentlichem Rahmen | Geeignete Integration oder ESI prüfen | Fragment und Gesamtdokument getrennt kontrollieren |
| Cookie verändert nur eine Messkennung | Keine pauschale Ausnahme daraus ableiten | HTML und Funktionsablauf bleiben unverändert |
In LiteSpeed Cache finden Sie URL-Ausnahmen im Bereich Cache und dort unter Excludes beziehungsweise Ausschlüsse. Arbeiten Sie mit dem tatsächlich aufgerufenen Pfad. Die Herstellerdokumentation beschreibt Muster mit einer Markierung für Anfang und Ende. Eine eng formulierte Regel lässt sich leichter nachvollziehen als ein kurzes Wort, das zufällig viele verschiedene Adressen enthält. Vor dem Speichern vergleichen Sie das Muster mit Ihrer vollständigen Liste betroffener URLs.
Für eine beispielhafte persönliche Seite unter /kundenbereich/ kann eine genaue Pfadregel passend sein. Besitzt dieser Bereich zusätzlich Unterseiten, muss die gewählte Regel auch diese erreichen. Ein Muster für genau die Hauptseite ist dann unvollständig. Ein breiter Begriff wie kunde kann umgekehrt öffentliche Ratgeber treffen. Die richtige Breite entsteht aus der Routenstruktur der Website und lässt sich nicht als universelle Zeichenfolge aus einer fremden Anleitung übernehmen.
# Nur ein Beispiel für eine genau benannte Seite:
^/kundenbereich/$
# Tatsächliche Unterseiten separat prüfen.
Prüfen Sie nach einer Regeländerung die bisher gespeicherte Fassung und invalidieren Sie die betroffenen Cacheeinträge nach dem vorgesehenen Verfahren. Eine bereits vorhandene Kopie ist sonst eine mögliche Erklärung für widersprüchliche Beobachtungen. Notieren Sie, wann die Regel aktiviert und wann der zugehörige Purge durchgeführt wurde. Damit bleibt ein späterer Vergleich verständlich, ohne nachträglich aus Erinnerungen eine Reihenfolge rekonstruieren zu müssen.
Die Einstellung Do Not Cache Cookies ist für Cookies vorgesehen, bei deren Vorhandensein eine Antwort vom Seitencache ausgenommen werden soll. Tragen Sie einen anhand der Anwendung belegten Namen ein. Eine aus dem Browser kopierte Liste sämtlicher Cookies kann nahezu jeden Besuch dynamisch machen, während das eigentliche Problem ungelöst bleibt. Beschreiben Sie zu jedem Eintrag kurz, welche Ausgabe er schützt und wie dieser Zusammenhang geprüft wurde.
Auch Querystrings verdienen eine eigene Bewertung. Eine URL mit einer Vorschaukennung oder einer persönlichen Auswahl hat andere Anforderungen als ein allgemeiner Trackingparameter. Das Entfernen eines Parameters aus dem Cacheschlüssel ist nur sinnvoll, wenn die Antwort dadurch fachlich unverändert bleibt. Verändert ein Parameter einen Preis, einen Suchbegriff oder die Berechtigung, darf diese Bedeutung nicht stillschweigend verschwinden. Prüfen Sie parameterfreie und parametrisierte Antworten separat.
Ein Ausschluss für eine Benutzerrolle kann bei einem begrenzten Test helfen, ersetzt aber keine systematische Behandlung aller persönlichen Zustände. Ein anonym begonnener Warenkorb besitzt beispielsweise keine WordPress-Rolle. Ebenso können mehrere Kunden derselben Rolle unterschiedliche Informationen sehen. Eine Gruppe gleichberechtigter Konten ist daher nicht automatisch eine Gruppe identischer Inhalte. Diese Unterscheidung ist besonders bei Mitgliedschafts- und Geschäftskundenfunktionen wichtig.
Richten Sie zwei getrennte Browserprofile oder zuverlässig getrennte Testkontexte ein. Sitzung A erhält eine erkennbare Testauswahl, Sitzung B bleibt zunächst leer. Verwenden Sie Testdaten und einen geschützten Bereich. Rufen Sie in beiden Kontexten dieselbe URL auf und wiederholen Sie die Aufrufe. Halten Sie Inhalt und Antwortheader zusammen fest. Der Header allein zeigt nicht, ob eine personalisierte Ausgabe zur richtigen Sitzung gehört.
Wechseln Sie danach die Reihenfolge. Lassen Sie B die Seite zuerst aufrufen, ändern Sie anschließend A und laden Sie beide erneut. So fällt ein Fehler auf, bei dem der erste Besucher ungewollt die gemeinsame Kopie prägt. Führen Sie den Vergleich zusätzlich nach einem Purge durch, weil sich ein Fehler erst beim Befüllen eines leeren Caches zeigen kann. Eine einzige erfolgreiche Ansicht aus einem bereits eingespielten Zustand reicht als Abnahme nicht aus.
Kontrollieren Sie den Zustand nach der Abmeldung. Persönliche Angaben sollen nicht in einer allgemeinen Antwort auftauchen. Beachten Sie außerdem die Zurückfunktion des Browsers: Eine zuvor geladene Darstellung und eine neue Serverantwort sind verschiedene Beobachtungen. Für die Cacheprüfung betrachten Sie den dokumentierten neuen Request. Wenn sensible Daten im Verlauf sichtbar bleiben, untersuchen Sie die Browsercachevorgaben gesondert und ordnen Sie den Befund der richtigen Ebene zu.
Für den LSCache-Ausschluss nennt LiteSpeed unter anderem X-LiteSpeed-Cache-Control: no-cache als Prüfhinweis. Lesen Sie diesen am HTML-Dokument der endgültigen URL. Ein Header an einem Bild oder an einer Weiterleitung beantwortet eine andere Frage. Den genauen Ablauf beschreibt Cache-HIT und MISS prüfen. Bei einem vorgeschalteten CDN kommen dessen eigene Zustandsbelege hinzu.
HTTP-Cachevorgaben besitzen eigene Bedeutungen. Nach der MDN-Referenz verlangt no-cache grundsätzlich eine Validierung vor Wiederverwendung; no-store untersagt die Speicherung. Ein Cachebegriff in einem Pluginfeld ist daher nicht ohne Weiteres mit einer HTTP-Direktive gleichzusetzen. Übernehmen Sie keine selbstgeschriebene globale Headerregel, nur weil dieselbe Wortfolge vertraut wirkt. Lassen Sie Anwendung und beteiligte Cacheebenen ein zusammenhängendes Verhalten liefern.
Eine großzügige Ausnahme kann eine falsche Antwort kurzfristig verschwinden lassen. Prüfen Sie trotzdem, ob die Anwendung ihre persönliche Ausgabe und Zugriffskontrolle richtig beschreibt. Eine Seite, die ohne Berechtigungsprüfung fremde Daten liefert, wird durch das Abschalten des Caches nicht korrekt geschützt. Ebenso kann ein fehlender Aktualisierungshook eine öffentliche Ansicht veralten lassen. In diesem Fall ist die Anbindung an den Purge-Ablauf das eigentliche Thema.
Dokumentieren Sie eine vorläufige Ausnahme als solche: betroffener Pfad, geschützte Funktion, verantwortlicher Ansprechpartner und erneuter Prüftermin. Damit wächst aus einer schnellen Korrektur keine dauerhaft undurchsichtige Konfiguration. Bei einem späteren Pluginwechsel lässt sich dann entscheiden, ob die Regel weiterhin notwendig ist. Entfernen Sie sie erst nach einer erneuten Funktionsprobe und einer klaren Behandlung noch vorhandener Cachekopien.
Ein zusätzliches Gegenbeispiel verhindert eine zu einfache Regel. Wählt Besucher A eine andere Sprache, kann die übersetzte Artikelansicht für viele Besucher gleich sein. Besucher B soll weiterhin seine eigene Sprache erhalten. Prüfen Sie diesen Zustand mit einer ausdrücklich allgemeinen Seite, auf der keine persönlichen Daten vorkommen. Wenn die Sprache getrennte URLs besitzt, testen Sie diese URLs direkt. Wird sie über einen Cookie gewählt, dokumentieren Sie die vorhandene Integration und kontrollieren Sie beide Zustände nach dem Befüllen des Caches.
Führen Sie danach denselben Sprachwechsel auf einer persönlichen Seite durch. Dort reicht die öffentliche Sprachvariante nicht zur Trennung der Konten. Dieser Vergleich zeigt, warum eine Eigenschaft der Darstellung und eine individuelle Sitzung zwei verschiedene Dimensionen sind. Eine Regel, die nur den ersten Testfall löst, kann im zweiten Fall unvollständig sein.
Ein zweiter Diagnosefall betrifft eine Vorschau. Eine redaktionelle Vorschau kann unveröffentlichten Text enthalten und eine andere Berechtigung als die spätere öffentliche Seite verlangen. Notieren Sie den tatsächlichen Vorschauweg und prüfen Sie ihn nur innerhalb der autorisierten Testumgebung. Untersuchen Sie anschließend die öffentliche URL ohne Vorschauparameter in einer getrennten Sitzung. Dort darf der unveröffentlichte Inhalt nicht erscheinen. Ein unterschiedlicher Seitentitel oder eine zufällige Parameterfolge ist kein ausreichender Ersatz für diese Zugriffstrennung.
Wenn die Vorschau fehlschlägt, vergleichen Sie Status und Antwortinhalt vor einer neuen Regel. Eine abgelaufene Vorschaukennung kann eine korrekte Ablehnung auslösen. Eine ungewollt gespeicherte öffentliche Kopie ist dagegen ein anderer Befund. Dokumentieren Sie, welchen Zustand Sie beobachtet haben. Entfernen Sie Token und vollständige persönliche URLs aus weitergegebenen Unterlagen und geben Sie stattdessen einen bereinigten Aufbau sowie die konkrete Abweichung an. So kann die Diagnose den richtigen Pfad untersuchen, ohne Zugangshinweise zu veröffentlichen.
Für den späteren Betrieb genügt eine kurze Ausnahmeliste mit Zweck und Prüfdatum. Ergänzen Sie darin, welche reguläre öffentliche Vergleichsseite weiterhin einen passenden Cachebeleg liefert. Diese Gegenprobe schützt vor einer unbeabsichtigten globalen Deaktivierung. Nach einem Themewechsel prüfen Sie nicht nur, ob die gespeicherten Regeln noch vorhanden sind, sondern ob die persönliche Ausgabe weiterhin an denselben Stellen entsteht.
Die folgende Checkliste fasst konkrete Beobachtungen zusammen. Sie bestätigt weder automatisch die Website noch eine Datenschutzanforderung. Markieren Sie nur Schritte, die an Ihrer Installation durchgeführt wurden. Für Warenkorb und Bestellung ergänzt der WooCommerce-Leitfaden diesen Ablauf; für gemischte öffentliche und private Fragmente folgt die ESI-Prüfung.
7. Oktober 2026. Die Beispiele sind Prüfanleitungen und keine Messung Ihrer Installation.