HTTP 304 und bedingte Anfragen praktisch testen

Was HTTP 304 tatsächlich bestätigt

Eine bedingte Anfrage fragt den Server, ob eine bereits bekannte Darstellung noch aktuell ist. Passt ein ETag bei If-None-Match, kann die Antwort 304 Not Modified die erneute Übertragung des Inhalts vermeiden. Last-Modified und If-Modified-Since verfolgen ein ähnliches Ziel anhand des Änderungsdatums. Ein bloß vorhandener Header beweist noch nicht, dass diese Anfragen korrekt verarbeitet werden.

So läuft der Vergleich ab

Zuerst wird die öffentliche URL ohne Bedingung abgerufen. Bei HTTP 200 und verwendbaren Validatoren folgen passende Anfragen. Ein zusätzlicher, zufälliger ETag dient als Gegenprobe. Sind beide Validatoren vorhanden, prüft eine weitere Anfrage den Vorrang von If-None-Match gegenüber If-Modified-Since. Die endgültige URL bleibt für diese Folgeanfragen fest.

HTTP 200 ist nicht automatisch ein Fehler

Ändert sich der Inhalt zwischen zwei Abrufen, kann eine erneute 200-Antwort korrekt sein. Bei vollständigen Antworten vergleicht das Tool deshalb zusätzlich den Inhalt. Wurde ein Leselimit erreicht, wird keine unveränderte Darstellung behauptet. Personalisierung, wechselnde Zeitstempel und unterschiedliche Serverknoten können die Einordnung ebenfalls beeinflussen.

Speicherbarkeit und Revalidierung getrennt beurteilen

Cache-Control: no-store betrifft die Speicherung. Ein ETag allein erlaubt nicht jede Speicherung, und ein fehlender ETag ist kein eigenständiger SEO-Fehler. Nutzen Sie für das gesamte Cache-Konzept zusätzlich den Cache-/Kompressions-Checker. Die Semantik der Bedingungen ist in RFC 9110 beschrieben.

Häufige Fragen