Du korrigierst eine wichtige Aussage in einem Artikel. Im Browser steht längst die neue Fassung, doch du möchtest wissen, ob ein Crawler sie beim nächsten Abruf ebenfalls bekommen kann. Ein normaler Seitenaufruf beantwortet diese Frage nur teilweise. Der Server kann auf einen Besucher ohne gespeicherte Fassung anders reagieren als auf einen Client, der fragt: „Hat sich seit meinem letzten Besuch etwas geändert?“
Genau diese zweite Anfrage lohnt sich zu prüfen. Bei unverändertem Inhalt ist 304 Not Modified eine sinnvolle Antwort. Wenn die Seite inzwischen wesentlich überarbeitet wurde, kann eine falsche Bestätigung dazu führen, dass der Client seine alte Fassung weiterverwendet. Der Fehler steckt dann möglicherweise in einem Änderungskennzeichen, einer Cache-Regel oder der Auslieferung zwischen CMS und CDN.
Mit dem folgenden Test prüfst du diesen technischen Vertrag. Ob Googlebot den Fehler tatsächlich erlebt hat, lässt sich erst mit passenden Abrufbelegen untersuchen.
Was eine 304-Antwort überhaupt bestätigt
Unter den HTTP-Statuscodes für SEO hat 304 eine besondere Aufgabe: Sie liefert keinen neuen Seiteninhalt, sondern bestätigt bei einer passenden bedingten Anfrage, dass eine vorhandene Fassung weiterverwendet werden kann. Ein Client braucht dafür zunächst eine gespeicherte Antwort.
Google beschreibt die Unterstützung von ETag und Last-Modified in seinem Beitrag zum HTTP-Caching beim Crawling. Das ist ein Verfahren zum effizienten Abruf. Aus einer einzelnen 304-Antwort folgt weder ein Indexierungsproblem noch ein Rankingvorteil.
Zwei Header-Paare begegnen dir dabei:
| Server liefert | Client fragt beim nächsten Mal | Aussage |
|---|---|---|
ETag: "artikel-v1" | If-None-Match: "artikel-v1" | Ist die gespeicherte Repräsentation weiterhin gültig? |
Last-Modified: Wed, 21 Oct 2026 08:00:00 GMT | If-Modified-Since: Wed, 21 Oct 2026 08:00:00 GMT | Wurde diese Repräsentation seit diesem Zeitpunkt geändert? |
Die Werte sind Beispiele. Ein ETag kann etwa aus einer Inhaltsrevision entstehen. Seine Erzeugung ist nicht auf einen bestimmten Algorithmus festgelegt. Das Präfix W/ bezeichnet einen schwachen Validator, der semantische Gleichwertigkeit statt identischer Bytes ausdrückt. MDN erläutert die ETag-Varianten.
Für die Diagnose zählt deshalb nicht jede Abweichung im HTML. Ein wechselnder technischer Zeitstempel kann andere Bytes erzeugen, ohne den fachlichen Inhalt zu ändern. Eine korrigierte Lieferbedingung, ein neuer Absatz oder eine geänderte Indexierungsanweisung ist ein deutlich besserer Testfall.
Wann sich die Prüfung lohnt
Prüfe die bedingte Auslieferung, wenn eine wichtige Änderung im CMS gespeichert ist, aber einzelne Abrufwege widersprüchliche Fassungen zeigen. Weitere Anlässe sind ein neues CDN, geänderte Cache-Regeln oder ein Deployment, das Inhaltsrevisionen anders verarbeitet.
Allein ein altes Suchergebnis ist noch kein solcher Nachweis. Zwischen Veröffentlichung, Crawling und der Verarbeitung einer Änderung liegen unterschiedliche Schritte. Ein normaler Testabruf kann die Auslieferung prüfen, aber weder einen erneuten Google-Abruf erzwingen noch dessen Ergebnis vorwegnehmen.
Auch das Crawl Budget braucht eine passende Einordnung. Googles Leitfaden zur Crawl-Budget-Verwaltung richtet sich besonders an große oder häufig aktualisierte Websites. Für einen kleinen Blog ist eine korrekte Cache-Implementierung gute technische Pflege. Daraus muss kein eigenes Großprojekt entstehen.
Ein sauberer Test beginnt vor der Änderung
Wähle eine öffentliche HTML-Seite, die du kontrolliert bearbeiten darfst. Verwende ihre endgültige URL ohne Weiterleitung. Notiere Sprache, Host und den Zeitpunkt. Halte diese Bedingungen bei allen Abrufen gleich. Wenn du nachher einen anderen Host oder eine andere Sprachfassung anfragst, vergleichst du möglicherweise verschiedene Repräsentationen.
Die Befehle verwenden das Programm curl. Unter Windows kannst du ausdrücklich curl.exe aufrufen, falls deine Shell den Namen anders belegt. Sie führen GET-Anfragen aus. Ein Test nur mit HEAD liefert keinen Body, an dem du die tatsächliche Inhaltsfassung erkennen könntest.
1. Ausgangsfassung und ETag speichern
bashcurl -sS -D before.headers -o before.html --etag-save before.etag -H "Accept-Encoding: identity" -w "%{http_code}\n" "https://example.com/ratgeber/lieferzeiten"
Ersetze die Beispieladresse durch deine Seite. Prüfe Status, Header und die gespeicherte HTML-Datei. Bei einer normalen öffentlichen Zielseite erwartest du zunächst 200 und den tatsächlichen Artikelinhalt. Eine Anmeldung, Fehlerseite oder Weiterleitung muss vor dem Cache-Test geklärt werden.
In before.etag muss ein Wert stehen. Fehlt der Header, kann curl eine leere Datei anlegen. Dann hast du mit diesem Befehl noch keinen ETag-Test vorbereitet. Prüfe stattdessen den verfügbaren Last-Modified-Header oder bespreche mit der Entwicklung, ob die Anwendung Validatoren unterstützen soll. Ein fehlender ETag ist für sich genommen kein SEO-Fehler.
Die curl-Dokumentation zu ETag-Dateien erklärt die beiden Optionen. Bewahre before.etag unverändert auf. Du brauchst den alten Wert nach dem nächsten Veröffentlichungsschritt erneut.
2. Ohne Bearbeitung denselben Validator senden
bashcurl -sS -D unchanged.headers -o unchanged.html --etag-compare before.etag -H "Accept-Encoding: identity" -w "%{http_code}\n" "https://example.com/ratgeber/lieferzeiten"
Wenn die ausgelieferte Fassung unverändert ist und der Server die Bedingung entsprechend auswertet, passt 304 ohne neuen Body zum erwarteten Verhalten. Eine vollständige 200-Antwort kann bedeuten, dass die bedingte Auslieferung auf diesem Weg nicht genutzt wird. Untersuche das getrennt von der Frage, ob Änderungen verloren gehen.
Verwende unterschiedliche Ausgabedateien und lies immer den HTTP-Status mit. Die bloße Existenz einer alten HTML-Datei sagt nichts darüber aus, welchen Inhalt die letzte Anfrage übertragen hat.
3. Eine erkennbare Inhaltsänderung veröffentlichen
Ändere einen konkreten Satz, den du anschließend in der HTTP-Antwort wiederfinden kannst. In unserem hypothetischen Beispiel wird aus „Versand in zwei Werktagen“ die Aussage „Versand in fünf Werktagen“. Es geht um eine echte Inhaltsänderung, keine unsichtbare Formatkorrektur.
Prüfe nach der Veröffentlichung zuerst einen normalen GET ohne den alten Validator. Steht der neue Satz schon in der ausgelieferten HTML-Datei? Wenn nicht, untersuchst du zunächst den Veröffentlichungs- oder Cache-Invalidierungspfad. Ein Cache kann eine alte Seite auch mit 200 ausliefern. Dafür brauchst du keinen fehlerhaften 304-Mechanismus.
4. Nach der Änderung nochmals den alten ETag senden
bashcurl -sS -D after.headers -o after.html --etag-compare before.etag -H "Accept-Encoding: identity" -w "%{http_code}\n" "https://example.com/ratgeber/lieferzeiten"
Für eine wesentlich veränderte Repräsentation sollte der alte Validator die Wiederverwendung der alten Fassung nicht mehr bestätigen. Erwartet wird bei einer erfolgreichen normalen Zielseite die neue Fassung mit 200. Kontrolliere den korrigierten Satz im Body und notiere den jetzt gelieferten ETag, sofern vorhanden.
Eine 304-Antwort ist hier ein untersuchungswürdiger Befund, wenn du sicher dieselbe Repräsentation vergleichst und die veröffentlichte Änderung wesentlich ist. Wiederhole nicht einfach zehnmal denselben Abruf. Halte die widersprüchlichen Antworten fest und grenze die verantwortliche Schicht ein.
Last-Modified separat testen
Wenn die Seite einen Änderungszeitpunkt liefert, kannst du den alten Wert zusätzlich in einer eigenen Anfrage senden:
bashcurl -sS -D modified.headers -o modified.html -H "If-Modified-Since: Wed, 21 Oct 2026 08:00:00 GMT" -H "Accept-Encoding: identity" -w "%{http_code}\n" "https://example.com/ratgeber/lieferzeiten"
Übernimm das Datum aus deiner Ausgangsantwort. Das Beispieldatum ist kein gemessener Wert. Teste den Zeitstempel nicht versehentlich zusammen mit dem gespeicherten ETag, wenn du gerade die Datumslogik isolieren möchtest. Nach RFC 9110 zu bedingten Anfragen hat If-None-Match Vorrang vor If-Modified-Since.
Last-Modified muss die ausgewählte Repräsentation sinnvoll abbilden. Ein stets neues Datum kann unnötige Übertragungen verursachen. Ein unverändertes Datum trotz relevanter Änderungen kann eine falsche Bestätigung begünstigen. MDN beschreibt den Header und seine Grenzen. Wenn eine Seite in sehr kurzen Abständen verändert wird, sollte die Entwicklung außerdem die zeitliche Genauigkeit der verwendeten Änderungslogik prüfen.
CDN und Ursprung auseinanderhalten
Zwischen Anfrage und CMS können mehrere Systeme antworten. Eine Prüfung der Anwendung allein reicht dann nicht aus. Stelle für denselben Testfall die Antworten der öffentlichen URL einem intern freigegebenen Ursprungstest gegenüber. Die Entwicklung kann diesen Vergleich durchführen, ohne Sicherheitsregeln der Website abzuschalten.
Diese Unterscheidung hilft beim nächsten Schritt:
| Beobachtung | Nächste Untersuchung |
|---|---|
| Schon der normale öffentliche GET enthält den alten Satz | Veröffentlichung, HTML-Cache und Invalidierung prüfen |
| Öffentlicher GET ist neu, Anfrage mit altem ETag liefert 304 | Erzeugung und Auswertung des Validators auf diesem Weg prüfen |
| Ursprung liefert die neue Fassung, öffentlicher Abruf eine alte | CDN-Regeln, Cache-Schlüssel und Weitergabe von Headern vergleichen |
| Neue HTML-Fassung kommt an, nur das Suchergebnis wirkt alt | Abrufzeit und weitere Verarbeitung bei Google getrennt untersuchen |
Ein angehängter Zufallsparameter ist kein ausreichender Gegenbeweis. Er kann eine andere Cache-Variante anfordern. Auch ein Browser mit Anmeldung oder Vorschau-Cookie eignet sich schlecht als Vergleich für eine öffentliche Crawler-Anfrage. Halte den ursprünglichen Abrufweg im Blick.
Dokumentiere bei einem vermuteten CDN-Fehler außerdem, ob die Antwort einen Cache-Status oder einen Alterswert enthält. Welche Header dafür verfügbar sind und was sie bedeuten, hängt vom Anbieter und der Konfiguration ab. Ein solcher Hinweis hilft bei der Zuordnung, ersetzt aber nicht den Vergleich des tatsächlich ausgelieferten Inhalts.
Nach einer Korrektur brauchst du erneut beide Testfälle. Wenn die Entwicklung jede Anfrage pauschal mit 200 beantwortet, kann die neue Fassung zwar ankommen, die Wiederverwendung unveränderter Seiten ist damit aber noch nicht geprüft. Umgekehrt reicht eine korrekte 304 vor der Änderung nicht aus. Das entscheidende Paar lautet: unverändert wiederverwenden, wesentlich geändert neu übertragen. Halte dafür denselben Host, dieselbe URL und dieselben Anfragebedingungen fest.
Was du damit über Googlebot weißt
Ein eigener GET zeigt, was dein Testclient unter den dokumentierten Bedingungen erhalten hat. Selbst ein nachgeahmter User-Agent beweist keinen Besuch von Googlebot. Für den tatsächlichen Ablauf brauchst du passende Server- oder CDN-Protokolle mit Zeitpunkt, URL und Antwortstatus. Zur Zuordnung von echten Google-Anfragen gehört eine verlässliche Bot-Verifizierung.
Erst danach lässt sich sinnvoll fragen: Erfolgte der Abruf vor oder nach der Änderung? Welche Schicht beantwortete ihn? Zeigt der Befund einen Übertragungsfehler oder muss die weitere Indexierung untersucht werden? Der Status „Gecrawlt, zurzeit nicht indexiert“ ist eine andere Diagnose als ein unpassender Cache-Validator.
Für die Übergabe reichen wenige belastbare Dateien: Ausgangs-HTML mit Headern, der alte Validator, der Veröffentlichungszeitpunkt und die Antwort nach der Änderung. Ergänze die konkrete erwartete Textstelle. So kann die Entwicklung den Fehler nachstellen, statt aus einer veralteten Suchvorschau eine Ursache erraten zu müssen.
Die Ergebnisse gehören in den technischen Prüfprozess. Im Site-Audit-Bereich von Crawl Foundry lässt sich der weitere Zusammenhang einer betroffenen URL untersuchen. Ob die Cache-Korrektur funktioniert, belegst du zusätzlich mit der beschriebenen Anfragefolge. Unser Beitrag zur Priorisierung und Überprüfung von Audit-Befunden ordnet solche Einzelprüfungen in die Arbeit des Teams ein.
Der Test ist abgeschlossen, wenn die unveränderte Fassung korrekt wiederverwendet werden kann und eine wesentliche Änderung mit dem alten Validator erneut ausgeliefert wird. Ob und wann sich diese Änderung in der Suche zeigt, bleibt ein gesonderter Nachweis.