HTTP-Statuscode 304: Bedeutung und Lösungen

Eine 304-Antwort bedeutet, dass dein Server dem Browser sagt: Der Inhalt hat sich seit dem letzten Check nicht geändert, nutz einfach deine Version aus dem Cache. Das ist normalerweise ein Feature, kein Bug. Aber wenn es dazu führt, dass User veraltete Inhalte sehen, wird es zu einem Problem, das du beheben musst.

Was ist der 304-Statuscode?

HTTP 304 Not Modified ist ein Antwortcode aus der Redirect-Klasse, der dem Client sagt, dass seine zwischengespeicherte Version einer Ressource noch gültig ist. Der Server schickt bei einer 304-Antwort keinen Body mit, sondern nur Header – das sorgt für schnellere Ladezeiten und spart Bandbreite.

304 Not Modified: So funktioniert es

Der Ablauf sieht so aus: Ein Browser fragt eine Ressource an und der Server antwortet mit dem Content plus Caching-Headern. Beim nächsten Besuch schickt der Browser eine bedingte Anfrage (If-Modified-Since oder If-None-Match) und fragt nach, ob sich der Inhalt geändert hat. Wenn sich nichts geändert hat, antwortet der Server mit 304 und der Browser nutzt seinen lokalen Cache. Es wird kein Inhalt übertragen.

304 vs. 200: Wo ist der Unterschied?

Eine 200-Antwort schickt die komplette Ressource. Eine 304-Antwort schickt nichts außer den Headern, die bestätigen, dass die Cache-Version noch aktuell ist. Aus User-Sicht führen beide dazu, dass die Seite lädt. Der Unterschied liegt im Speed und in der Bandbreite. Eine 304-Antwort für ein 500KB großes Bild spart also 500KB an Datentransfer.

Ist 304 ein Fehler? Wann es zum Problem wird

304 ist kein Fehler. Alles läuft genau wie geplant. Es wird erst zum Problem, wenn du Content auf dem Server aktualisierst, die User aber die alte Version sehen, weil ihre Browser noch nicht abgelaufene Kopien aus dem Cache laden. Genau dann musst du eingreifen.

Wie HTTP-Caching eine 304-Antwort auslöst

Zwei Mechanismen steuern, ob ein Server bei wiederholten Anfragen 304 oder 200 zurückgibt.

Der ETag-Header

ETags sind eindeutige IDs, die der Server für jede Version einer Ressource generiert. Der Server schickt ETag: „abc123“ mit der ersten Antwort mit. Bei den nächsten Anfragen schickt der Browser If-None-Match: „abc123“. Wenn der aktuelle ETag des Servers übereinstimmt, antwortet er mit 304. Falls nicht, schickt er eine 200 mit dem neuen Content und einem neuen ETag.

Der Last-Modified-Header

Der Last-Modified-Header sagt dem Browser, wann eine Ressource das letzte Mal geändert wurde. Bei den folgenden Anfragen schickt der Browser „If-Modified-Since“ mit genau diesem Datum. Wurde die Ressource seitdem nicht mehr angefasst, antwortet der Server mit 304.

Cache-Control und seine Rolle

Cache-Control-Header legen fest, wie lange Ressourcen gecacht werden sollen, bevor der Browser überhaupt eine bedingte Anfrage stellt. „Cache-Control: max-age=3600“ heißt, dass der Browser die Ressource für 3600 Sekunden nicht nochmal anfragt. Erst wenn diese Zeit abgelaufen ist, schickt er die Anfrage (If-Modified-Since / If-None-Match), die ein 304 auslösen kann.

So behebst du den 304-Statuscode

Wenn 304-Antworten für Probleme mit veralteten Inhalten sorgen, gibt es fünf Lösungswege.

1. Leere deinen Browser-Cache

Der schnellste Fix, wenn ein einzelner User veraltete Inhalte sieht: Browser-Cache leeren. In Chrome: Geh in die Einstellungen – Datenschutz und Sicherheit – Browserdaten löschen – wähl „Zwischengespeicherte Bilder und Dateien“ und klick auf „Daten löschen“. In Firefox: Geh in die Einstellungen – Datenschutz und Sicherheit – Daten löschen (unter Cookies und Website-Daten).

Das zwingt den Browser, beim nächsten Besuch frischen Content anzufragen und den 304-Zyklus zu umgehen.

2. Deaktiviere das Browser-Caching beim Debuggen

Nutz während der Entwicklung die Dev-Tools deines Browsers, um das Caching zu deaktivieren. In den Chrome DevTools: Öffne den Netzwerk-Tab und setz den Haken bei „Disable Cache“. Das zwingt jede Anfrage zu einer frischen 200-Antwort und macht es leicht zu checken, ob Content-Updates auch wirklich im Browser ankommen.

3. Cache-Control-Header serverseitig anpassen

Um Browser zu zwingen, gecachten Content öfter zu validieren, musst du den „max-age“-Wert verringern. In nginx:

location ~* \.(css|js)$ {     add_header Cache-Control "public, max-age=300"; }

Ein kürzerer „max-age“-Wert bedeutet, dass Browser häufiger nach Aktualisierungen fragen.

4. Eine frische Antwort mit „no-cache“ erzwingen

Die „no-cache“-Direktive verhindert das Caching nicht. Sie zwingt den Browser aber dazu, bei jeder Anfrage beim Server nachzufragen:

add_header Cache-Control "no-cache";

Das heißt, jeder Seitenaufruf löst eine bedingte Anfrage aus. Hat sich am Content nichts geändert, gibt der Server weiterhin 304 zurück. Wenn sich was geändert hat, kommt eine 200 mit frischem Content zurück. User sehen so immer den aktuellen Content, ohne unveränderte Ressourcen ständig neu laden zu müssen.

5. Proxy- und CDN-Caching-Layer checken

Wenn du ein CDN oder einen Reverse-Proxy nutzt, könnten die 304-Antworten von dort kommen statt direkt von deinem Origin-Server. Check deine CDN-Konfiguration auf Cache-TTL-Einstellungen und such in den Antworten nach Headern wie „X-Cache: HIT“. Wenn ein CDN veralteten Content liefert, muss dessen Cache geleert werden „purged“ – da reicht es nicht, nur den Browser-Cache zu löschen.

304-Statuscode und SEO

304-Antworten sind im Allgemeinen SEO-neutral. Suchmaschinen-Crawler respektieren HTTP-Caching. Eine 304-Antwort sagt dem Googlebot: Der Seiteninhalt ist seit dem letzten Crawl unverändert. Der Crawler nutzt dann seine eigene Cache-Version, was ziemlich effizient ist. Probleme gibt es nur, wenn dein Server 304 zurückgibt, obwohl sich der Content geändert hat – dann verpassen die Crawler deine Updates. Halt deine ETags und Last-Modified-Header also immer aktuell.

FAQ: HTTP 304-Statuscode