304 Not Modified: Bedeutung, Caching und SEO

TL;DR — Eine 304 Not Modified-Antwort ist die Art des Servers zu sagen: „Das haben Sie bereits — Ihre Kopie ist noch gültig, laden Sie es nicht erneut herunter.“ Sie ist kein Fehler, und obwohl sie zur 3xx-„Redirect“-Familie gehört, schickt sie niemanden zu einer neuen URL. Sie tritt nur auf, wenn der Client (ein Browser oder Crawler) zunächst eine bedingte Anfrage sendet und fragt: „Hat sich das seit dem letzten Mal geändert?“ Für SEO verändert sie keine Rankings, aber auf großen Websites kann sie Suchmaschinen helfen, ihre Ressourcen effizienter einzusetzen.

Was eine 304 tatsächlich ist

Jede Antwort Ihres Servers beginnt mit einem dreistelligen Statuscode. 200 OK bedeutet: „Hier ist die Seite, inklusive Body.“ Eine 304 Not Modified bedeutet etwas Spezifischeres: Der Client hat eine bedingte Anfrage gestellt — eine Anfrage nach dem Muster „Gib mir diese Seite, aber nur, wenn sie sich geändert hat“ — und der Server hat festgestellt, dass sie sich nicht geändert hat. Statt der 200, die er sonst gesendet hätte, antwortet er mit 304 und überhaupt keinem Body. Das ist die tatsächliche Regel: Eine 304 ist ausschließlich die Antwort auf eine bedingte GET/HEAD-Anfrage, deren Bedingung als falsch ausgewertet wurde.

Ein zweiter Besuch ist die typische Situation dafür und ein hilfreiches Bild: Beim ersten Abruf einer Seite durch Browser oder Crawler erhalten Sie eine normale 200-Antwort mit dem vollständigen Inhalt — plus einige kleine Header als „Fingerabdruck“. Beim nächsten Besuch zeigt der Client dem Server diesen Fingerabdruck und fragt: „Noch gleich?“ Wenn sich nichts geändert hat, antwortet der Server mit 304, sendet überhaupt keinen Seiten-Body und der Client verwendet einfach die Kopie weiter, die er bereits hatte. „Zweiter Besuch“ ist aber nur das Beispiel, nicht die Protokollregel — eine 304 wird tatsächlich durch die bedingte Anfrage ausgelöst, ganz gleich, wie sie beim Server ankommt. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

Warum sie zur „Redirect“-Familie gehört, aber keine Weiterleitung ist

304 beginnt mit einer 3, und 3 ist die HTTP-Klasse für Weiterleitungen. Das sorgt ständig für Verwirrung. Eine 304 hat jedoch keinen Location-Header und schickt Sie nicht an eine andere Adresse — niemand geht irgendwohin. Sie verweist den Client lediglich auf seine eigene gespeicherte Kopie zurück. „Redirect-Familie“ ist daher eine Eigenheit der Nummerierung, nicht die Beschreibung ihrer Funktion.

Ist eine 304 ein Problem?

Nein. 304s im Netzwerk-Tab Ihres Browsers oder in einem Crawl-Bericht zu sehen, bedeutet, dass Caching funktioniert — genau das, was Sie wollen. Viele Ratgeber zu „304-Fehler, wie beheben?“ behandeln den Status so, als sei auf Ihrer Seite etwas kaputt. Das stimmt nicht. Es ist das korrekte, beabsichtigte Ergebnis eines gut funktionierenden Caches.

Hilft sie der SEO?

Nicht direkt Ihren Rankings. Google besitzt den Inhalt bereits vom letzten Crawl der Seite — eine 304 bestätigt lediglich, dass sich nichts geändert hat, sodass Google weiter verwendet, was bereits gespeichert ist (Search kann die Signale einer URL trotzdem neu berechnen, aber die 304 selbst ist kein Ranking- oder Indexierungsbonus). Wo sie tatsächlich hilft, ist die Ressourceneffizienz: Wenn eine Suchmaschine Seiten nicht erneut herunterladen muss, die sich nicht geändert haben, spart das auf beiden Seiten Bandbreite und Rechenleistung. Laut Google kann das indirekt dazu beitragen, dass Crawling effizienter abläuft — es ist aber keine Garantie, dass die eingesparte Arbeit automatisch auf Ihre neuen oder aktualisierten Seiten umverteilt wird. Das ist vor allem auf großen Websites mit vielen selten geänderten Seiten wichtig. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation

Möchten Sie die tatsächliche Mechanik — ETags, If-None-Match, starke und schwache Validatoren, die Implementierung und das, was Google tatsächlich dazu gesagt hat? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — 304 ist die Antwort auf eine bedingte GET-/HEAD-Anfrage, deren Bedingung falsch ausgewertet wird und die andernfalls eine 200-Antwort ergeben hätte (RFC 9110 §15.4.5). Sie gehört zur 3xx-Klasse, ist aber keine Weiterleitung: kein Location-Header, keine neue URL und — normativ — kein Body („sie kann keinen Inhalt und keine Trailer enthalten“). Die Bedingung wird durch If-None-Match (gegen einen ETag) und/oder If-Modified-Since (gegen Last-Modified) übertragen; wenn der Validator noch übereinstimmt, gibt der Server 304 zurück und der Client verwendet seinen Cache weiter. SEO-Auswirkung: kein direkter Ranking-Effekt — Google hat den Inhalt bereits, auch wenn Search die Signale einer URL weiterhin neu berechnen kann — und ein Ressourcenvorteil auf großen Websites (Google sagt, dass dies die Crawling-Effizienz indirekt verbessern kann; eine automatische Umverteilung des Crawl-Budgets auf andere URLs wird nicht versprochen). Googles Crawling-Infrastruktur unterstützt beide Validatoren und empfiehlt ETag als primären Validator (dort gibt es keine Probleme mit Datumsformaten). Nicht mit 301/302/307/308 (sie verschieben die URL) oder 204 (ebenfalls ohne Body, aber weil tatsächlich nichts zu senden ist) verwechseln.

Was 304 in der Spezifikation bedeutet

RFC 9110 (HTTP Semantics) §15.4.5 definiert es genau: “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (Übersetzung) Der Statuscode 304 (Not Modified) zeigt an, dass eine bedingte GET- oder HEAD-Anfrage empfangen wurde und andernfalls eine 200-(OK-)Antwort ergeben hätte, weil die Bedingung falsch ausgewertet wurde. Das ist der tatsächliche normative Auslöser — eine bedingte GET-/HEAD-Anfrage, deren Bedingung falsch ausgewertet wird und die sonst eine 200 ergeben hätte. In einfachen Worten: Der Client fragt „Gib mir diese Seite, aber nur, wenn sie sich geändert hat“, der Server stellt fest, dass sie sich nicht geändert hat, und lässt den Body deshalb weg. Ein „zweiter Besuch“ ist das alltägliche Beispiel dafür, wie eine Anfrage bedingt wird (der Client fügt einen Validator aus einer früheren Antwort an), aber nur ein Lehrbeispiel, nicht die Regel — die Spezifikation verlangt keinen vorherigen Besuch, sondern nur eine bedingte Anfrage. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified Evidence for this claim A 304 response terminates after the header section and cannot contain content or trailers. Scope: conditional GET and HEAD Confidence: high · Verified: 2026-07-16 RFC 9110 §15.4.5: 304 Not Modified

Die Spezifikation verwendet in diesem Abschnitt sogar das Wort “redirecting” (Übersetzung) „Weiterleiten“ — “the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response” (Übersetzung) Der Server leitet den Client daher zu dieser gespeicherten Darstellung, damit er sie wie den Inhalt einer 200-(OK-)Antwort verwenden kann. Lesen Sie den Satz genau: Der Client wird zu seinem eigenen Cache zurückgeleitet, nicht zu einer anderen URL. Es gibt keinen Location-Header und keine neue Adresse. Dieser eine Satz ist die Ursache für den Großteil der Verwirrung darüber, ob 304 „eine Weiterleitung“ ist. Im HTTP-Sinn ist sie das nicht.

Zwei weitere normative Punkte sind wichtig:

• Nie ein Body. RFC 9110 sagt: “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (Übersetzung) Eine 304-Antwort endet mit dem Ende des Header-Abschnitts; sie darf keinen Inhalt oder Trailer enthalten. Eine 304 mit Body verletzt die Spezifikation, und manche Clients behandeln sie dann fehlerhaft. Das ist eine harte Regel, keine Stilfrage.
• Dieselben Metadaten wie bei 200. Der Server folgt der Vorgabe “MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Content-Location, Date, ETag, and Vary,” (Übersetzung) Der Server muss daher die entsprechenden Headerfelder einer 200-(OK-)Antwort für dieselbe Anfrage erzeugen: Content-Location, Date, ETag und Vary; je nach Fall kommen Cache-Control und Expires hinzu. Eine 304 ist damit die Header-Information einer 200 ohne deren Payload.

Wie 304 tatsächlich funktioniert: bedingte Anfragen

Ein Server sendet eine 304 nie aus dem Nichts. Sie ist immer die Antwort auf eine bedingte Anfrage — eine Anfrage, die der Client durch einen aus einer früheren Antwort gespeicherten Validator bedingt macht. Es gibt zwei Validatoren.

ETag und If-None-Match

Ein ETag (Entity-Tag) ist ein undurchsichtiges Token, das der Server an eine 200-Antwort anhängt — stellen Sie es sich als Versions-Fingerabdruck für genau diese Darstellung der URL vor. Bei der nächsten Anfrage an diese URL sendet der Client den gespeicherten Wert in einem If-None-Match-Header zurück. Der Server vergleicht: Wenn der aktuelle ETag weiterhin übereinstimmt, hat sich nichts geändert und er gibt 304 zurück; wenn er abweicht, gibt er eine frische 200-Antwort mit dem neuen Inhalt und einem neuen ETag zurück.

Last-Modified und If-Modified-Since

Die datumsbasierte Alternative: Der Server sendet bei der 200 einen Last-Modified-Zeitstempel. Beim nächsten Mal sendet der Client ihn in einem If-Modified-Since-Header zurück, und der Server vergleicht die Daten — wenn sich die Ressource seit diesem Zeitstempel nicht geändert hat, ist die Antwort eine 304. Das ist einfacher, aber gröber (nur so genau wie der Zeitstempel) und empfindlich gegenüber dem exakten HTTP-Datumsformat, was häufig Fehler verursacht. Wenn beide Validatoren vorhanden sind, hat If-None-Match (der ETag) Vorrang vor If-Modified-Since.

Starke und schwache ETags

Ein ETag kann stark oder schwach sein, und der Unterschied ist wichtig. Laut MDNs Anleitung zu bedingten Anfragen bedeutet “strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (Übersetzung) Eine starke Validierung garantiert, dass die Ressource Byte für Byte identisch mit der Vergleichsressource ist. Ein schwacher ETag beginnt mit W/ (zum Beispiel ETag: W/"abc123") und behauptet nur semantische Gleichwertigkeit — MDNs Beispiel beschreibt: “a page that would differ from another only by a different date in its footer, or different advertising, would be considered identical to the other with weak validation.” (Übersetzung) Eine Seite, die sich von einer anderen nur durch ein anderes Footer-Datum oder andere Werbung unterscheidet, gilt bei schwacher Validierung als identisch. Starke ETags (ohne Präfix) sind für Dinge wie Range-Anfragen nötig, die einen bytegenauen Abgleich benötigen; schwache ETags sind nützlich, wenn Komprimierung, Leerraum oder geringfügige nicht inhaltliche Unterschiede keinen vollständigen Abruf auslösen sollen. Die praktische Falle: Wenn sich Ihr ETag bei jeder Gzip-/Brotli-Neukomprimierung ändert oder zwischen Servern eines Load-Balancers variiert, lösen Sie unnötige neue Crawls aus — wählen Sie starke oder schwache ETags bewusst und halten Sie den Wert für tatsächlich unveränderten Inhalt stabil.

Der vollständige Handshake, Schritt für Schritt

1. Erste Anfrage → Der Server gibt 200 OK mit dem Inhalt sowie ETag und/oder Last-Modified zurück.
2. Der Client speichert den Inhalt und diese Validatoren.
3. Nächste Anfrage → Der Client sendet If-None-Match und/oder If-Modified-Since mit den gespeicherten Werten.
4. Der Server entscheidet: unverändert → 304 Not Modified, kein Body, der Client verwendet seinen Cache; geändert → 200 OK mit dem neuen Body und frischen Validatoren. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation

Wenn Sie die ausführlichere Behandlung von Caching und Validatoren als Hebel für Crawling-Effizienz möchten — die gesamte Geschichte der bedingten Anfragen und ihr Zusammenhang mit dem Crawl-Budget — ist das ein Begleitthema; dieser Artikel konzentriert sich auf den Statuscode.

304 und SEO: kein Ranking-Effekt, aber ein echter Effekt auf die Crawling-Effizienz

Hier ist die gesamte SEO-Geschichte, und sie ist enger, als viele Blogtexte nahelegen. 304 hat keinen direkten Ranking-Effekt, und Googles eigene Hinweise dazu, wie Statuscodes Crawling und Indexierung beeinflussen, begrenzen auch den Indexierungseffekt: Search kann die Signale einer URL weiterhin neu berechnen, ansonsten ändert eine 304 aber nicht, wie die Seite indexiert wird. Google besitzt den Inhalt bereits vom vorherigen Crawl; eine 304 bestätigt nur, dass sich nichts geändert hat, und Google verwendet ihn weiter. Für die Rückgabe von 304s gibt es keinen Rankingbonus.

Was Ihnen 304 ermöglicht, sind Ressourceneinsparungen mit möglicher indirekter Verbesserung der Crawling-Effizienz. In Googles Blogbeitrag „Crawling December: HTTP caching“ vom Dezember 2024 formulierte Gary Illyes es klar: “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (Übersetzung) Besonders bei großen Websites mit selten geänderten Inhalten kann lokales Caching dazu beitragen, dass die Website effizienter gecrawlt wird; Googles Infrastruktur unterstützt dafür heuristisches HTTP-Caching mit ETag/If-None-Match und Last-Modified/If-Modified-Since.

Zum genauen 304-Mechanismus erklärt derselbe Beitrag ausdrücklich, warum der leere Body der entscheidende Punkt ist: Wenn der vom Crawler gesendete ETag “matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body,” (Übersetzung) sollte der Server bei übereinstimmendem Wert den Statuscode 304 ohne HTTP-Body zurückgeben. Der Teil “no HTTP body” (Übersetzung) „kein HTTP-Body“ ist wichtig, weil “your server doesn’t have to spend compute resources on actually generating content” (Übersetzung) der Server keine Rechenressourcen für die tatsächliche Erzeugung des Inhalts aufwenden muss und “doesn’t have to transfer the HTTP body” (Übersetzung) den HTTP-Body nicht übertragen muss — Sie sparen auf beiden Seiten Rechenleistung und Bandbreite. Googles eigene Formulierung für den nachgelagerten Nutzen ist vorsichtig: Diese Ressourceneinsparungen können die Crawling-Effizienz indirekt verbessern. Es ist kein Versprechen, dass die eingesparte Arbeit automatisch auf Ihre neuen oder aktualisierten URLs umverteilt wird — betrachten Sie es als Ressourceneinsparungsmechanismus mit einem plausiblen, aber nicht garantierten Nebeneffekt.

Warum das auf großen Websites wichtiger ist

Wenn Sie einige hundert Seiten haben, ist das weitgehend akademisch — Google wird Ihre gesamte Website unabhängig davon bequem crawlen. Der Nutzen wächst mit der Größe: Eine Website mit Hunderttausenden oder Millionen URLs, von denen sich viele selten ändern, profitiert spürbar, wenn Crawler die unveränderten Seiten nicht erneut abrufen müssen. An dieses Publikum richtet sich Googles Beitrag, und das ist die ehrliche Einordnung — verkaufen Sie 304 nicht als Maßnahme für kleine Websites.

ETag oder Last-Modified — und was als „geändert“ zählt

Google empfiehlt ETag als primären Validator: “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (Übersetzung) Wir empfehlen ETag dringend, weil er weniger fehleranfällig ist und sein Wert im Gegensatz zu Last-Modified nicht strukturiert ist. Beide zu setzen ist in Ordnung und wird empfohlen. Wenn Sie Last-Modified verwenden, “must be formatted according to the HTTP standard” (Übersetzung) muss das Datum nach dem HTTP-Standard formatiert sein — Google empfiehlt das Format “Weekday, DD Mon YYYY HH:MM:SS Timezone,” (Übersetzung) „Wochentag, Tag Monat Jahr Stunde:Minute:Sekunde Zeitzone“, zum Beispiel “Fri, 4 Sep 1998 19:15:56 GMT” (Übersetzung) eine gültige HTTP-Datumsangabe; andernfalls wird es möglicherweise stillschweigend ignoriert. Google empfiehlt außerdem, das max-age-Feld von Cache-Control und bei Bedarf Expires zu setzen, damit Crawler entscheiden können, wann sie erneut crawlen. Evidence for this claim Google's crawler guidance recommends ETag because its opaque value avoids date-formatting errors, while also allowing both ETag and Last-Modified; this is Google-specific operational advice, not a change to HTTP validator semantics. Scope: HTTP cache validation Confidence: high · Verified: 2026-07-16 Crawling December: HTTP caching

Was als Änderung gilt, die den Cache ungültig machen sollte, entscheiden Sie selbst. Googles Rat lautet, dies für wesentliche Änderungen aufzuheben: “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (Übersetzung) Fordern Sie eine Cache-Aktualisierung nur bei signifikanten Inhaltsänderungen an; ein ausschließlich aktualisiertes Copyright-Datum im Seitenfuß ist wahrscheinlich nicht signifikant.

Was Googlebot und Bingbot tatsächlich damit tun

Nicht jede Crawler-Anfrage ist bedingt. Googles Crawler-Dokumentation weist darauf hin, dass einzelne Google-Crawler und Fetcher je nach bedientem Produkt unterschiedliche Caching-Unterstützung haben — Googlebot unterstützt Caching beim erneuten Crawlen von URLs für Search, während einige andere Google-Fetcher es nur unter bestimmten Bedingungen unterstützen. Erwarten Sie daher auch bei korrekt eingerichteten Headern nicht, dass 100 % der Anfragen If-None-Match/If-Modified-Since enthalten. Bei Bing gilt: Bedingte Anfragen sind keine Google-exklusive Funktion. Bings Crawler unterstützt bedingte GET-Anfragen (sendet If-Modified-Since und, wenn verfügbar, If-None-Match und akzeptiert bei unverändertem Inhalt eine 304) mindestens seit einem Live-Search-Blogbeitrag von 2008 — Bing hat jedoch keine moderne Entsprechung zu Googles Beitrag von 2024 veröffentlicht. Betrachten Sie die Mechanik als allgemeines HTTP-Verhalten, das für beide Suchmaschinen gilt.

304-Unterstützung implementieren

1. Validatoren bei der 200 senden. Konfigurieren Sie Server, CDN oder Anwendung so, dass normale 200-Antworten einen ETag (empfohlen) und/oder einen korrekt formatierten Last-Modified-Header erhalten. Viele Server und Frameworks erzeugen ETags für statische Dateien automatisch; dynamische Antworten benötigen meist eine ausdrückliche Aktivierung.
2. Bedingte Header bei der nächsten Anfrage berücksichtigen. Wenn eine Anfrage mit If-None-Match/If-Modified-Since eintrifft, vergleichen Sie mit dem aktuellen Validator und geben Sie 304 (ohne Body) zurück, wenn er weiterhin übereinstimmt, oder eine frische 200, wenn nicht. Auch hier erledigen Server für statische Dateien das oft automatisch; App-Routen und Edge-Worker tun es häufig nicht, sofern Sie es nicht einrichten.
3. Definieren Sie, was „geändert“ bedeutet, und halten Sie den ETag für tatsächlich unveränderten Inhalt stabil — lassen Sie ihn nicht durch erneute Komprimierung oder Unterschiede zwischen Servern unnötig wechseln.
4. Achten Sie auf die klassischen Fehlkonfigurationen:
   • Immer 200 — es werden nie Validatoren ausgegeben, daher ist keine Anfrage bedingt und der Effizienzvorteil bleibt aus.
   • Instabile ETags — ein Wert ändert sich, obwohl der Inhalt gleich bleibt (Load-Balancer oder erneute Komprimierung), und erzwingt ständige neue Abrufe.
   • Veraltete 304s — die gefährliche Variante: Ein Server gibt nach einer echten Inhaltsänderung weiterhin 304 (oder denselben ETag) zurück, sodass Crawler und Caches die Aktualisierung nie erhalten. Das ist ein Fehler, den Sie in der Log-Analyse finden müssen, keine inhärente Schwäche von 304.

304 im Vergleich zu anderen Statuscodes

304 im Vergleich zu 301 / 302 / 307 / 308

Das sind die tatsächlichen Weiterleitungen. Eine dauerhafte 301/308 oder eine vorübergehende 302/307 trägt einen Location-Header und verschiebt den Client zu einer anderen URL — 301/308 übertragen außerdem ein Kanonisierungssignal. Eine 304 hat keinen Location-Header, verschiebt niemanden und überträgt kein Rankingsignal. Gleiche 3xx-Familie nach der Nummer, völlig andere Aufgabe. Die Details zu den einzelnen Weiterleitungscodes stehen in den jeweiligen Artikeln (siehe den Beitrag 301 redirect und den Weiterleitungs-Sub-Hub).

304 im Vergleich zu 204 No Content

Beide sind aus völlig unterschiedlichen Gründen ohne Body. Eine 204 No Content ist ein erfolgreicher 2xx-Status mit absichtlich leerem Body, weil der Server wirklich nichts zu senden hat — etwa nach einem erfolgreichen API-DELETE/PUT oder bei einem Analytics-Beacon. Eine 304 sendet ebenfalls keinen Body, aber nicht, weil nichts zu senden wäre, sondern weil „Sie die Ressource bereits haben und sie noch gültig ist“. Verwechseln Sie die beiden nicht: Eine 204 auf einer Seiten-URL kann wie ein Soft-404 behandelt werden, weil kein indexierbarer Inhalt vorhanden ist, während eine 304 eine Gültigkeitsbestätigung für Inhalt ist, den Google bereits besitzt. Der Artikel 204 No Content behandelt diesen Code vollständig.

Häufige Mythen über 304

1. „304 ist eine Weiterleitung.“ Kein Location-Header, niemand geht irgendwohin. Der Client verwendet seine eigene Cache-Kopie weiter. Das „Weiterleiten des Clients, damit er die gespeicherte Darstellung nutzt“ in RFC 9110 bedeutet, auf den Cache zurückzuverweisen, nicht auf eine andere URL.
2. „304 ist ein Fehler, den ich beheben muss.“ Es ist das korrekte, beabsichtigte Ergebnis einer funktionierenden Einrichtung für bedingte Anfragen. 304s in einem Crawl oder in DevTools zu sehen, ist ein Zeichen dafür, dass Caching funktioniert — das häufigste Missverständnis in den SERPs.
3. „304 hilft Rankings.“ Es gibt keinen direkten Ranking-Effekt, und Google begrenzt auch den Indexierungseffekt — Search kann die Signale einer URL neu berechnen, aber eine 304 ändert ansonsten nichts an der Indexierung. Der Nutzen sind Ressourceneinsparungen, die laut Google die Crawling-Effizienz auf sehr großen Websites indirekt verbessern können; 304 ist aber kein Rankingsignal und keine Garantie, dass eingesparte Arbeit auf andere URLs übergeht.
4. “If my server returns 304, Google will use stale content forever.” (Übersetzung) Wenn mein Server 304 zurückgibt, wird Google den veralteten Inhalt für immer verwenden. 304 wird nur zurückgegeben, solange der Validator übereinstimmt. Sobald sich der Inhalt tatsächlich ändert, gibt ein korrekt implementierter Server eine frische 200 mit neuen Validatoren zurück. Das echte Risiko ist ein falsch konfigurierter Server, der nach einer Inhaltsänderung weiter 304 liefert — ein Fehler, keine Eigenschaft von 304. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation
5. „ETag und Last-Modified sind austauschbar.“ Beide sind Validatoren, aber Last-Modified ist empfindlich gegenüber dem Datumsformat und nur so genau wie sein Zeitstempel, während ETag undurchsichtig und präzise ist (bei schlechter Implementierung aber zwischen Servern oder nach erneuter Komprimierung unpraktisch variieren kann). Google empfiehlt ETag als primären Validator, beide sind möglich.

FAQs

Ist HTTP 304 ein Fehler? Nein — es ist ein Erfolgssignal dafür, dass Caching funktioniert. Die Cache-Kopie des Clients ist noch gültig.

Ist 304 Not Modified eine Weiterleitung? Nein. Der Status gehört wegen seiner Nummerierung zur 3xx-Klasse, hat aber keinen Location-Header und verschiebt den Client nicht zu einer neuen URL.

Hilft 304 SEO oder Rankings? Kein direkter Ranking-Effekt und kein Indexierungseffekt, abgesehen davon, dass Google die Signale einer URL möglicherweise neu berechnet. Der Status spart Bandbreite und Rechenleistung, weil Crawler unveränderte Seiten nicht erneut abrufen müssen; laut Google kann das die Crawling-Effizienz auf großen Websites indirekt verbessern.

Was ist der Unterschied zwischen ETag und Last-Modified? ETag ist ein undurchsichtiger Versions-Fingerabdruck, der über If-None-Match abgeglichen wird; Last-Modified ist ein Zeitstempel, der über If-Modified-Since abgeglichen wird. Google empfiehlt ETag, weil er weniger fehleranfällig ist.

Was ist ein schwacher bzw. starker ETag? Ein starker ETag behauptet byteidentischen Inhalt; ein schwacher ETag (mit dem Präfix W/) behauptet semantische Gleichwertigkeit und toleriert geringfügige Unterschiede wie Komprimierung oder ein geändertes Footer-Datum.

Warum sehe ich 304s in meinen Logs oder Crawl-Berichten? Weil Clients bedingte Anfragen stellen und Ihr Server korrekt bestätigt, dass sich der Inhalt nicht geändert hat. Das ist erwartbar und gut.

Wie bringe ich meinen Server dazu, 304 korrekt zurückzugeben? Senden Sie bei der 200 ETag/Last-Modified und berücksichtigen Sie bei der nächsten Anfrage If-None-Match/If-Modified-Since, indem Sie bei weiterhin übereinstimmendem Validator eine 304 ohne Body zurückgeben.

Was ist der Unterschied zwischen 304 und 204? Beide sind ohne Body; 204, weil nichts zu senden ist, 304, weil Sie bereits eine weiterhin gültige Kopie besitzen.

Sendet Googlebot bei jeder Anfrage bedingte Header? Nein — die Caching-Unterstützung variiert je nach Crawler, daher ist nicht jede Anfrage bedingt, auch wenn die Header konfiguriert sind.

Darf eine 304-Antwort einen Body enthalten? Nein. Laut RFC 9110 „kann sie keinen Inhalt und keine Trailer enthalten“. Eine 304 mit Body verletzt die Spezifikation. Evidence for this claim A 304 response terminates after the header section and cannot contain content or trailers. Scope: conditional GET and HEAD Confidence: high · Verified: 2026-07-16 RFC 9110 §15.4.5: 304 Not Modified

KI-Zusammenfassung

Eine komprimierte Zusammenfassung der Version für Fortgeschrittene:

• 304 Not Modified ist die Antwort auf eine bedingte GET-/HEAD-Anfrage, deren Bedingung falsch ausgewertet wird und die andernfalls eine 200-Antwort ergeben hätte (RFC 9110 §15.4.5). Der Status gehört zur 3xx-Klasse, ist aber keine Weiterleitung: kein Location-Header, keine neue URL und — normativ — kein Body: “it cannot contain content or trailers.” (Übersetzung) Eine 304-Antwort darf keinen Inhalt oder Trailer enthalten. Ein zweiter Besuch ist nur das typische Beispiel dafür, wie eine Anfrage bedingt wird, nicht die Protokollregel.
• Sie ist die Antwort auf eine bedingte Anfrage. Eine GET-/HEAD-Anfrage trägt If-None-Match (abgeglichen mit einem ETag) und/oder If-Modified-Since (abgeglichen mit Last-Modified). Wenn der Validator noch übereinstimmt, gibt der Server 304 zurück und der Client verwendet seine Cache-Kopie weiter.
• Google empfiehlt ETag als primären Validator: “less prone to errors and mistakes” (Übersetzung) „weniger fehleranfällig“; beide Validatoren zu setzen ist in Ordnung.
• ETag vs. Last-Modified: ETag ist ein undurchsichtiges Versionstoken (abgeglichen über If-None-Match); Last-Modified ist ein Datum (abgeglichen über If-Modified-Since, mit exakt erforderlichem HTTP-Datumsformat). Wenn beide vorhanden sind, hat If-None-Match Vorrang. Starker ETag = byteidentisch; schwacher ETag (Präfix W/) = semantische Gleichwertigkeit.
• Kein direkter Ranking-Effekt und kein Indexierungseffekt, abgesehen davon, dass Google die Signale einer URL möglicherweise neu berechnet. Google besitzt den Inhalt bereits; 304 bestätigt nur, dass sich nichts geändert hat. Wie Gary Illyes es formulierte, kann Caching “may help your site be crawled more efficiently” (Übersetzung) dazu beitragen, dass Ihre Website effizienter gecrawlt wird — der Nutzen sind Ressourceneinsparungen mit möglicher indirekter Verbesserung der Crawling-Effizienz; keine garantierte Umverteilung des Crawl-Budgets und kein Rankingsignal.
• Google empfiehlt ETag als primären Validator: “less prone to errors and mistakes” (Übersetzung) „weniger fehleranfällig“; beide zu setzen ist in Ordnung. Last-Modified muss das Format “Weekday, DD Mon YYYY HH:MM:SS Timezone” (Übersetzung) „Wochentag, Tag Monat Jahr Stunde:Minute:Sekunde Zeitzone“ verwenden; der Cache sollte nur bei signifikanten Änderungen ungültig werden, nicht wegen eines Copyright-Datums im Footer.
• Caching-Unterstützung variiert je nach Crawler — nicht jede Googlebot-Anfrage ist bedingt. Bing unterstützt bedingte GET-Anfragen laut einem Live-Search-Beitrag seit 2008; das ist allgemeines HTTP-Verhalten.
• Nicht verwechseln mit 301/302/307/308 (echte Weiterleitungen, welche die URL verschieben) oder 204 No Content (ebenfalls ohne Body, aber weil tatsächlich nichts zu senden ist).
• Das echte Risiko ist nicht 304 selbst, sondern ein falsch konfigurierter Server, der nach einer tatsächlichen Inhaltsänderung 304 zurückgibt — das lässt sich in der Log-Analyse erkennen. Eine gültige 304 kann in manchen Client-Bibliotheken oder Plattform-Caching-Schichten auch wie ein Fehler aussehen, obwohl tatsächlich nichts falsch ist.

Offizielle Dokumentation

Primärquellen dazu, was 304 bedeutet und wie Suchmaschinen damit umgehen.

HTTP-Spezifikation und Browser-Referenz

• RFC 9110 §15.4.5 — 304 Nicht geändert — die maßgebliche Definition: bedingte Anfrage, kein Body, erforderliche Header.
• MDN — 304 Nicht geändert — verständliche Einordnung, der Auslöser If-None-Match/If-Modified-Since und die Liste der Header, die eine 304 enthalten muss.
• MDN — Bedingte HTTP-Anfragen — Erklärung starker und schwacher Validierung.
• MDN — ETag — der ETag-Header einschließlich der Syntax für schwache (W/) und starke ETags.

Google Search Central

• Crawling December: HTTP-Caching — Gary Illyes’ Beitrag vom 9. Dezember 2024: wie ETag/If-None-Match und Last-Modified/If-Modified-Since 304s auslösen und warum sie die Crawling-Effizienz verbessern.
• Google-Crawler (User-Agent) — Übersicht — welche Google-Crawler Caching unterstützen und die Empfehlung für ETag gegenüber Last-Modified.
• Wie HTTP-Statuscodes die Crawler von Google beeinflussen — Googles aktuelle Zeile zu 304, einschließlich des Hinweises, dass Search die Signale einer URL neu berechnen kann, obwohl 304 ansonsten keinen Indexierungseffekt hat.
• Probleme beim Crawling der Google-Suche beheben — die Quelle für Googles vorsichtige Formulierung, dass Ressourceneinsparungen durch bedingte Anfragen die Crawling-Effizienz „indirekt verbessern können“ und Google nicht bei jedem Crawl-Versuch bedingte Header sendet.

Bing

• Ankündigung von Verbesserungen des Crawlers für die Live-Suche — der (alte) Beitrag von Bing/Live Search, der seit 2008 Unterstützung für bedingte GET-Anfragen (If-Modified-Since/If-None-Match → 304) bestätigt.

Zitate aus den Quellen

Nachprüfbare Aussagen. Jeder Link führt direkt zur zitierten Passage auf der Quellseite, sofern die Quelle dies unterstützt.

Die HTTP-Spezifikation

• “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (Übersetzung) „Der Statuscode 304 (Not Modified) zeigt an, dass eine bedingte GET- oder HEAD-Anfrage empfangen wurde und andernfalls eine 200-(OK-)Antwort ergeben hätte, weil die Bedingung falsch ausgewertet wurde.“ — RFC 9110, HTTP Semantics, §15.4.5. Abschnitt lesen
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (Übersetzung) „Eine 304-Antwort endet mit dem Ende des Header-Abschnitts; sie darf keinen Inhalt oder Trailer enthalten.“ — RFC 9110, §15.4.5 (die normative Regel „niemals ein Body“). Abschnitt lesen

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (Übersetzung) „Der HTTP-Statuscode 304 Not Modified bedeutet, dass die angeforderten Ressourcen nicht erneut übertragen werden müssen.“ Zum Zitat springen
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (Übersetzung) „Eine starke Validierung garantiert, dass die Ressource Byte für Byte identisch mit der Vergleichsressource ist.“ — MDN, „HTTP conditional requests“. Leitfaden lesen

Gary Illyes, Google — „Crawling December: HTTP caching“ (9. Dezember 2024)

• “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (Übersetzung) „Besonders bei großen Websites mit selten geänderten Inhalten kann lokales Caching dazu beitragen, dass die Website effizienter gecrawlt wird.“ Beitrag lesen
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (Übersetzung) „Wir empfehlen dringend ETag, weil dieser weniger fehleranfällig ist.“ Beitrag lesen
• “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (Übersetzung) „Wenn der ETag-Wert übereinstimmt, sollte der Server den Statuscode 304 ohne HTTP-Body zurückgeben.“ Beitrag lesen
• “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (Übersetzung) „Aktualisieren Sie den Cache bei wesentlichen Inhaltsänderungen; eine reine Copyright-Änderung ist wahrscheinlich nicht wesentlich.“ Beitrag lesen

Zitat von Patrick Stox bei Ahrefs

• “304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (Übersetzung) „304 Not Modified bedeutet, dass die Seite nicht geändert wurde und typischerweise für Caching verwendet wird.“ — aus meinem Leitfaden HTTP-Statuscodes und ihre SEO-Auswirkungen (dieser Artikel ist der Deep Dive, den dieser Eintrag nie bekommen hat). Zum Zitat springen

304 im Kontext: die bodylosen und 3xx-Codes, mit denen sie verwechselt wird

304 und ihre Doppelgänger

Die Falle: 304 und 204 sind beide ohne Body, und 304/301/302/307/308 gehören alle zur 3xx-Klasse — aber 304 ist auf beiden Achsen der Sonderfall. Sie ist die einzige 3xx, die niemanden verschiebt, und der einzige bodylose Status, der „Sie haben es bereits“ statt „es gibt nichts zu senden“ bedeutet.

Die beiden Validatoren

Wenn beide vorhanden sind, hat If-None-Match Vorrang vor If-Modified-Since.

Schnelle Fakten

• 304 hat niemals einen Body — RFC 9110 macht das normativ.
• 304 gehört zur 3xx-Klasse, ist aber keine Weiterleitung (kein Location-Header, keine neue URL).
• Kein direkter Ranking-Effekt und kein Indexierungseffekt, abgesehen davon, dass Google die Signale einer URL möglicherweise neu berechnet — der Nutzen sind Ressourceneinsparungen mit möglicher indirekter Verbesserung der Crawling-Effizienz auf großen Websites.
• Google empfiehlt ETag als primären Validator; beide, ETag und Last-Modified, zu setzen ist in Ordnung.
• Last-Modified muss „Weekday, DD Mon YYYY HH:MM:SS Timezone“ verwenden, sonst wird der Header möglicherweise ignoriert.
• Den Cache nur bei signifikanten Inhaltsänderungen ungültig machen, nicht wegen eines Copyright-Datums im Footer.
• Nicht jede Crawler-Anfrage ist bedingt — Caching-Unterstützung variiert je nach Crawler.
• Bing unterstützt bedingte GET → 304 seit 2008; das ist allgemeines HTTP.
• Das echte Risiko ist eine veraltete 304 (der Server gibt nach einer Inhaltsänderung 304 zurück) — in der Log-Analyse erkennen.

Der Handshake einer bedingten Anfrage in rohem HTTP

Konkrete Anfrage-/Antwortketten, die zeigen, wie eine 304 entsteht. (Die Header-Werte dienen nur als Beispiel.)

ETag / If-None-Match — der erste Abruf (200)

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

<full page body here>

Der Client speichert den Body und den ETag-Wert.

ETag / If-None-Match — der nächste Abruf, Inhalt unverändert (304)

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

Kein Body. Der ETag stimmte überein, daher sparte der Server die Rechenleistung für die Seitenerzeugung und die Bandbreite für deren Übertragung. Der Client verwendet seine Cache-Kopie weiter.

Last-Modified / If-Modified-Since — das datumsbasierte Gegenstück

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT

Achten Sie auf das exakte HTTP-Datumsformat — „Weekday, DD Mon YYYY HH:MM:SS Timezone“ — das Google empfiehlt, um Parsing-Probleme zu vermeiden.

Wenn sich der Inhalt GEÄNDERT hat — eine frische 200, keine 304

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "e5f6g7h8"          ← new value: content changed

<updated page body here>

Der gespeicherte ETag stimmt nicht mehr überein, daher sendet der Server den neuen Inhalt und einen neuen Validator. Der Cache wird aktualisiert. Genau deshalb kann eine korrekt implementierte 304 einen Crawler nicht auf veraltetem Inhalt „gefangen halten“ — sobald sich der Inhalt ändert, ändert sich der Validator und die nächste Anfrage erhält eine echte 200.

Schwacher und starker ETag

ETag: "a1b2c3d4"      ← strong: asserts byte-for-byte identity
ETag: W/"a1b2c3d4"    ← weak: asserts semantic equivalence (the W/ prefix)

Faustregel: Wenn Sie eine große Website mit vielen selten geänderten URLs betreiben, können ein stabiler ETag und die Berücksichtigung von If-None-Match bei Ihren 200-Antworten Crawlern erlauben, mit einer günstigen, bodylosen 304 zu bestätigen, dass „noch alles gleich“ ist. Das spart Bandbreite und Rechenleistung, was laut Google die Effizienz des restlichen Crawlings indirekt verbessern kann. Wenn Ihr ETag bei jeder erneuten Komprimierung oder zwischen Load-Balancer-Servern wechselt, verlieren Sie diesen Nutzen.

304-Fehler, die bedingtes Caching zerstören

Den ETag ändern, obwohl sich die Darstellung nicht geändert hat

Ein ETag, der an eine Serverinstanz, einen Komprimierungslauf oder den Zeitpunkt der Anfrage gebunden ist, macht den Validator wirkungslos: Unveränderter Inhalt liefert weiterhin eine vollständige 200. Erzeugen Sie einen stabilen Validator aus der Darstellung oder verwenden Sie bewusst einen schwachen ETag, wenn Unterschiede auf Byte-Ebene nicht relevant sind.

Nach einer Inhaltsänderung 304 zurückgeben

Ein veralteter Validator kann eine echte Aktualisierung vor Clients und Crawlern verbergen. Machen Sie den ETag ungültig oder setzen Sie Last-Modified bei jeder Änderung der Darstellung fort, prüfen Sie anschließend, dass eine alte bedingte Anfrage eine frische 200 mit Body erhält.

304 ohne passende bedingte Anfrage senden

Ein Server sollte nicht raten, dass ein Client eine Cache-Kopie besitzt. Geben Sie 304 erst zurück, nachdem Sie If-None-Match oder If-Modified-Since ausgewertet haben; eine gewöhnliche erste Anfrage benötigt eine vollständige Antwort.

304 wie eine Weiterleitung oder eine leere Seite behandeln

Eine 304 hat keinen Location-Header und keinen Antwort-Body. Leiten Sie diese Antwort nicht durch die Weiterleitungslogik und ersetzen Sie keine echte leere Ressource durch 304; verwenden Sie den Status, der die tatsächliche Antwort beschreibt.

Häufige 304-Probleme

Der Server gibt immer 200 zurück

Symptom: Wiederholte Anfragen laden den vollständigen Body herunter, obwohl sich nichts geändert hat. Wahrscheinliche Ursache: Die erste Antwort enthält keinen Validator oder die Anwendung ignoriert die Header der bedingten Anfrage. Behebung: Senden Sie ETag und/oder ein gültiges Last-Modified und implementieren Sie die Prüfung von If-None-Match oder If-Modified-Since. Bestätigen Sie, dass eine unveränderte Anfrage eine 304 ohne Body zurückgibt.

Verschiedene Origin-Server erzeugen unterschiedliche ETags

Symptom: Dieselbe unveränderte URL wechselt hinter einem Load-Balancer zwischen 200 und 304. Wahrscheinliche Ursache: Jeder Knoten erzeugt seinen eigenen Validator. Behebung: Leiten Sie den ETag aus einem gemeinsamen Inhaltszustand ab, nicht aus dem Server, der die Anfrage bedient, und wiederholen Sie dieselbe bedingte Anfrage über mehrere Antworten hinweg.

Aktualisierter Inhalt liefert weiterhin 304

Symptom: Ein Browser oder Crawler behält nach einem Deployment eine alte Darstellung. Wahrscheinliche Ursache: Der Validator wurde zusammen mit dem Inhalt nicht ungültig gemacht. Behebung: Korrigieren Sie Cache-Key- oder Deployment-Logik, leeren Sie den betroffenen Cache, falls nötig, und weisen Sie nach, dass der alte ETag nun eine 200 mit einem neuen Validator erhält.

Last-Modified scheint ignoriert zu werden

Symptom: If-Modified-Since erzeugt nie eine 304. Wahrscheinliche Ursache: Ein ungültiges HTTP-Datum, unzureichende Zeitstempelgenauigkeit oder ein ETag, der Vorrang hat. Behebung: Untersuchen Sie die rohen Header, korrigieren Sie das Datumsformat und testen Sie jeden Validator einzeln.

Eine 304 sieht im Anwendungscode wie ein Fehler aus

Symptom: Ein Skript oder eine Anwendung wirft eine Exception oder protokolliert einen „Fehler“, obwohl die Anfrage tatsächlich eine 304 erhalten hat. Wahrscheinliche Ursache: Manche HTTP-Client-Bibliotheken behandeln jeden Status ungleich 200 — einschließlich einer gültigen 304 — wie eine Ausnahme, sofern Sie diese nicht ausdrücklich so konfigurieren, dass sie Weiterleitungen folgen oder Not-Modified-Antworten zulassen. Das ist eine Eigenheit der Client-Bibliothek, kein Protokoll- oder Serverproblem. Behebung: Prüfen Sie speziell den Umgang der Client-Bibliothek mit 304 (nicht nur ihre Fehlerbehandlung für 4xx/5xx) und bestätigen Sie, dass die rohe HTTP-Antwort eine korrekte, bodylose 304 ist, bevor Sie den Server verantwortlich machen.

Eine Plattform-Caching-Schicht (z. B. IIS Output Caching) verschleiert das Bild

Symptom: Die Origin-Anwendung wirkt korrekt, aber das Verhalten von 304 scheint weiterhin falsch. Wahrscheinliche Ursache: Eine für die Hosting-Plattform spezifische Caching-Schicht — IIS Output Caching ist ein dokumentiertes Beispiel — liegt zwischen Anwendung und Client und kann 304-Antworten selbst erzeugen oder abfangen. Behebung: Betrachten Sie dies als eine mögliche Schicht unter mehreren (Origin-Anwendung, CDN, Load-Balancer, Plattform-Cache), nicht als Standardverdächtigen. Isolieren Sie die Schicht mit einem kontrollierten Test, der den Validator in jeder Schicht einzeln ändert, bevor Sie entscheiden, welche Schicht verantwortlich ist.

Prompt: einen Trace bedingter Anfragen prüfen

Fügen Sie die Anfrage- und Antwort-Header eines ersten Abrufs und eines wiederholten Abrufs ein.

Act as an HTTP caching reviewer. I will paste two request/response header traces for
the same URL: an initial fetch and a conditional repeat. Identify the validator used,
check whether If-None-Match or If-Modified-Since was evaluated correctly, verify that
a 304 has no body or Location header, and flag unstable or stale-validator risks.
Return: observed flow, pass/fail checks, likely cause of each failure, and the exact
next request I should run. Do not infer headers that are not present.

[PASTE BOTH TRACES]

Prompt: eine ETag-Implementierung prüfen

Fügen Sie die relevante Konfiguration der Anwendung, des CDNs oder des Servers ein.

Review this ETag/Last-Modified implementation for conditional GET correctness. Trace
the 200 -> conditional request -> 304 path, explain what causes the validator to
change, and test mentally for multiple origin nodes, compression variants, and real
content updates. Separate protocol violations from efficiency issues. Give a minimal
fix and a curl-based validation plan. Do not invent platform behavior.

[PASTE CONFIGURATION OR CODE]

Shell: einen ETag als bedingte Anfrage wiederholen

Führen Sie dies in einem macOS-/Linux-Terminal aus. Kopieren Sie den ETag exakt, einschließlich der Anführungszeichen.

URL='https://example.com/page'
curl -sS -D - -o /dev/null "$URL"
curl -sS -D - -o /dev/null -H 'If-None-Match: "PASTE_ETAG_HERE"' "$URL"

Die erste Antwort sollte den Validator sichtbar machen. Die zweite sollte 304 zurückgeben, wenn die Darstellung unverändert ist, und 200, wenn der eingefügte ETag veraltet ist.

PowerShell: Last-Modified testen

Führen Sie dies in PowerShell aus, nachdem Sie URL und Zeitstempel ersetzt haben.

$url = 'https://example.com/page'
$headers = @{ 'If-Modified-Since' = 'Tue, 14 Jul 2026 12:00:00 GMT' }
Invoke-WebRequest -Uri $url -Headers $headers -SkipHttpErrorCheck

DevTools-Konsole: Validatoren der Seitenressourcen auflisten

Führen Sie dies in der Browser-Konsole aus. Der Befehl meldet Einträge aus dem Resource Timing; untersuchen Sie im Network-Panel die tatsächlichen ETag-, Last-Modified- und Status-Header.

console.table(performance.getEntriesByType('resource').map(r => ({name: r.name, transferSize: r.transferSize, encodedBodySize: r.encodedBodySize})));

Tools zum Prüfen des 304-Verhaltens

• HTTP Header Checker: Untersuchen Sie ETag, Last-Modified, Cache-Control, Vary und CDN-/Edge-Fingerabdrücke in der normalen Antwort, bevor Sie einen Validator wiederholen.
• Browser-DevTools-Network-Panel: Deaktivieren Sie „Disable cache“, laden Sie neu und vergleichen Sie Anfrage- und Antwort-Header. DevTools macht auch HSTS- und lokalen Cache sichtbar; unterscheiden Sie daher Browserverhalten von dem, was der Origin gesendet hat.
• curl: Senden Sie einen exakten If-None-Match- oder If-Modified-Since-Header, ohne dass der Cache-Zustand des Browsers dazwischenkommt.
• Access-Logs: Ermitteln Sie, welche Crawler-Anfragen bedingt waren und ob sie mit 304 oder einer vollständigen 200 endeten.

Nach einer Änderung nachweisen, dass bedingte Antworten funktionieren

Test mit unveränderter Darstellung

Auszuführender Test: Rufen Sie die URL ab, kopieren Sie ihren ETag und wiederholen Sie die Anfrage mit curl -I -H 'If-None-Match: "VALUE"' URL. Erwartetes Ergebnis: 304, der passende Validator und kein Body oder Location-Header. Interpretation eines Fehlschlags: Der Server ignoriert die Bedingung oder erzeugt einen instabilen Validator. Beobachtungsfenster: sofort. Rollback-Auslöser: Die Caching-Änderung führt dazu, dass normale Anfragen ihre vollständige 200-Antwort verlieren.

Test mit geänderter Darstellung

Auszuführender Test: Stellen Sie eine echte Inhaltsänderung bereit und wiederholen Sie anschließend den alten ETag. Erwartetes Ergebnis: 200 mit aktualisiertem Body und einem neuen Validator. Interpretation eines Fehlschlags: Die Cache-Invalidierung ist veraltet. Beobachtungsfenster: sofort nachdem das Deployment jeden Origin erreicht hat. Rollback-Auslöser: Ein Origin gibt nach abgeschlossener Ausrollung für den alten Validator weiterhin 304 zurück.

Stabilitätstest über mehrere Origins

Auszuführender Test: Wiederholen Sie dieselben normalen und bedingten Anfragen oft genug, um den Serving-Pool zu erreichen, und protokollieren Sie ETag und Status. Erwartetes Ergebnis: Unveränderte Darstellungen verwenden kompatible Validatoren und liefern zuverlässig 304. Interpretation eines Fehlschlags: Validatoren variieren je nach Knoten oder Kodierung, ohne dass eine passende Vary-Strategie vorhanden ist. Beobachtungsfenster: sofort über den gesamten ausgerollten Pool. Rollback-Auslöser: Die neue Validatorlogik liefert veralteten Inhalt oder vermischt Darstellungen zwischen Clients.

Die Gesundheit des bedingten Caches messen

Erfolgsrate der bedingten Validierung

Metrik: Bedingte Anfragen, die mit 304 enden, im Vergleich zu vollständigen 200-Antworten. Was sie zeigt: Ob unveränderte Ressourcen unnötige Übertragungen vermeiden. So ermitteln: Gruppieren Sie Access-Log-Anfragen mit If-None-Match oder If-Modified-Since nach Antwortstatus und URL-Klasse. Benchmark / realistischer Bereich: Ermitteln Sie je Inhaltstyp eine Baseline; häufig geänderte Seiten sollten nicht auf die Rate statischer Assets gedrückt werden. Taktung: während des Rollouts wöchentlich, danach monatlich.

Vermiedene Bytes bei unveränderten Abrufen

Metrik: Geschätzte Bytes des Antwort-Bodys, die bei gültigen 304-Antworten nicht übertragen wurden. Was sie zeigt: Die Bandbreitenseite des Vorteils für die Crawling-Effizienz. So ermitteln: Verknüpfen Sie die Zahl der 304s mit der Größe der letzten vollständigen Antwort für dieselbe URL-Klasse. Benchmark / realistischer Bereich: Vergleichen Sie mit der eigenen Baseline der Website vor der Änderung; kein universelles Ziel passt zu jedem Inhaltsmix. Taktung: monatlich.

Fehler durch veraltete Validatoren

Metrik: Geänderte URLs, die einen alten Validator weiterhin akzeptieren. Was sie zeigt: Ob die Effizienz auf Kosten der Aktualität entsteht. So ermitteln: Führen Sie nach einem Deployment eine kleine Stichprobe aus, die ETags aus der Zeit vor dem Deployment wiederholt. Benchmark / realistischer Bereich: Jede bestätigte veraltete Antwort erfordert eine Untersuchung. Taktung: bei jedem Deployment, das Caching oder die Erzeugung von Validatoren ändert.

Testen Sie Ihr Wissen: 304 Not Modified

Fünf kurze Fragen dazu, was 304 bedeutet und wie der Status funktioniert. Wählen Sie für jede eine Antwort und prüfen Sie die Antwort anschließend.

Änderungsprotokoll