Last-Modified und If-Modified-Since: 549 Websites im Test

Der Last-Modified-Header ist das Datum, an dem sich eine Seite laut Server zuletzt geändert hat. Ein Browser oder Crawler schickt dieses Datum im Header If-Modified-Since zurück, und wenn sich nichts geändert hat, antwortet der Server mit 304 Not Modified ohne Inhalt. In unserem Test der Tranco-Top-1.000 am 31. Oktober 2026 beachteten 86,7 % der Startseiten, die Last-Modified senden, diesen Header.

Die Lücke zwischen diesen beiden Werten übergehen die meisten Ratgeber. Googles Crawling-Dokumentation sagt: Trägt eine Antwort sowohl ein ETag als auch ein Last-Modified-Datum, verwenden Googles Crawler das ETag. Google empfiehlt ETag, weil es keine Probleme mit der Datumsformatierung hat. Ein Server, der Datumswerte sauber verarbeitet, aber bei ETags patzt, versagt also genau auf dem Weg, den Google bevorzugt.

Ich entwickle B2B-SaaS-Produkte mit TypeScript und Next.js, und aus Entwicklersicht geht Caching genau hier leise kaputt. Eine selbst gehostete Next.js-App etwa bildet das ETag als Hash aus dem HTML, das sie gleich ausliefert. Ein einziger Wert pro Anfrage in diesem HTML, ein Zeitstempel oder eine CSP-Nonce, gibt jeder Antwort ein neues ETag, und keine bedingte Anfrage kann je passen. Es gibt keine Fehlermeldung. Der Crawler lädt die ganze Seite einfach erneut herunter.

Gut gesetzte Cache-Header vermeiden doppelte Datenübertragungen zwischen Server und Crawler

Was sind If-Modified-Since- und Last-Modified-Header?

Diese beiden HTTP-Header arbeiten als Paar. Stellen Sie sich ein Gespräch zwischen Ihrem Browser (oder dem Googlebot) und Ihrem Server vor. Der Header If-Modified-Since ist die Frage: „Hat sich diese Seite seit diesem Datum geändert?“ Der Header Last-Modified ist die Antwort, die der Server vorher gegeben hat: „Zu diesem Zeitpunkt habe ich diese Ressource zuletzt aktualisiert.“

Richtig umgesetzt, erspart dieser Austausch unnötige Datenübertragungen. Statt die ganze Seite jedes Mal herunterzuladen, kann der Server mit dem Statuscode 304 antworten, der sagt: „Nichts hat sich geändert, nutzen Sie Ihre gespeicherte Version.“

Die technische Aufschlüsselung:

• If-Modified-Since: ein Request-Header, den Browser und Crawler senden. Er fragt, ob der Inhalt nach dem mitgeschickten Datum geändert wurde (dem Last-Modified-Wert, den sie gespeichert haben).
• Last-Modified: ein Response-Header mit dem genauen Zeitpunkt, an dem die Ressource auf dem Server zuletzt geändert wurde.

ETag und If-None-Match sind das zweite Validator-Paar und erledigen dieselbe Aufgabe mit einer Kennung statt eines Datums. Der Server sendet ein undurchsichtiges ETag wie "34aa387-d-1568eb00" (meist ein Hash oder eine Versionsnummer), der Client schickt es in If-None-Match zurück, und bei Übereinstimmung gibt es eine 304. RFC 9110, der HTTP-Standard, weist Server an, If-Modified-Since zu ignorieren, sobald If-None-Match vorhanden ist, weil ein Entity-Tag die genauere Prüfung ist.

Das Datum selbst hat ein strenges Format. Googles Dokumentation empfiehlt die HTTP-Datumsform, zum Beispiel Fri, 4 Sep 1998 19:15:56 GMT: Wochentag, Tag, Monat, Jahr, Uhrzeit und immer GMT. Eine lokale Zeitzone oder ein ISO-8601-Datum ist genau die Art von „Formatierungsproblem“, wegen der Google ETags bevorzugt.

So funktioniert die Cache-Validierung

Das passiert bei einer bedingten GET-Anfrage. Dieser Mechanismus macht If-Modified-Since für SEO so nützlich.

Schritt 1: Erste Anfrage

Wenn ein Browser oder der Googlebot Ihre Seite zum ersten Mal aufruft, sendet er eine normale HTTP-Anfrage. Ihr Server antwortet mit dem vollständigen Seiteninhalt, dem Statuscode 200 und, ganz wichtig, einem Last-Modified-Header (oft zusätzlich mit einem ETag):

Last-Modified: Thu, 15 Jan 2026 14:30:00 GMT

Schritt 2: Folgeanfragen

Beim nächsten Besuch schickt der Browser einen If-Modified-Since-Header mit diesem gespeicherten Zeitstempel mit:

If-Modified-Since: Thu, 15 Jan 2026 14:30:00 GMT

Schritt 3: Entscheidung des Servers

Ihr Server vergleicht die Zeitstempel und entscheidet:

• Inhalt unverändert? Er antwortet mit 304 Not Modified ohne Inhalt und spart Bandbreite und Rechenzeit.
• Inhalt aktualisiert? Er liefert die vollständige Antwort mit Status 200 und dem neuen Last-Modified-Zeitstempel.

Das wirkt wie eine kleine Optimierung, aber bei Tausenden von Seiten und regelmäßigem Crawling summiert sich der Effekt deutlich.

Was unser Test von 1.000 Top-Websites ergeben hat

Die meisten Top-Startseiten beantworten eine bedingte Anfrage nicht mit einer 304. Am 31. Oktober 2026 haben wir die Startseiten der Tranco-Top-1.000-Domains abgerufen. 549 lieferten eine HTML-Seite (die übrigen waren API- und CDN-Hostnamen ohne Startseite, Fehler oder Bot-Sperren). Danach haben wir jeden gesendeten Validator erneut geschickt und die Antwort notiert.

Diese 47 sind die klarsten Fehler: Der Server sagt, die Version sei unverändert, und schickt trotzdem die ganze Seite. Die 28 sind ein anderes Problem. Ihr ETag ändert sich zwischen Anfragen, die Sekunden auseinanderliegen, und 15,6 % aller Startseiten-ETags änderten sich in unserem Test zwischen zwei normalen Anfragen, gegenüber 3,3 % der Last-Modified-Daten.

Der Weg über das Datum hielt deutlich besser. Nur 3,9 % der Last-Modified-Daten lagen höchstens zwei Sekunden vom Date-Header der Antwort entfernt, also der Fehler „Zeitstempel ist immer jetzt“.

Die 51,2 % der Startseiten ganz ohne Validator fallen gegenüber dem Web Almanac 2021 auf, wo nur 24,5 % aller Antworten keinen von beiden trugen. Der Almanac zählte auch Bilder, Skripte und Stylesheets, also Dateien, die ein Webserver standardmäßig mit Validatoren ausliefert; HTML, das pro Anfrage erzeugt wird, bekommt oft keinen.

Sitemaps schnitten besser ab als Startseiten. Von 287 /sitemap.xml-Dateien, die antworteten, sendeten 66,6 % einen Validator, und 54,4 % lieferten auf mindestens eine bedingte Anfrage eine 304. Dasselbe Muster zeigte sich: 86,4 % beachteten If-Modified-Since, 62,1 % If-None-Match. Wenn Sie nicht wissen, wo eine Website ihre Sitemap ablegt, lesen Sie, wie Sie die Sitemap einer Website finden.

Am selben Tag haben wir unsere eigenen Seiten geprüft. seomator.com und dieser Beitrag senden ein schwaches ETag und kein Last-Modified, und ein erneut gesendetes ETag bekommt eine 304. Google empfiehlt, beide Validatoren zu setzen, also steht das fehlende Datum auch auf unserer Liste.

So haben wir getestet

Wir haben die Top-1.000-Domains der Tranco-Liste 746VX (erstellt am 30. Oktober 2026) genommen, derselbe Ansatz wie bei unserer robots.txt-Studie, und am 31. Oktober 2026 von Istanbul aus ein Node.js-Skript mit einem Desktop-Chrome-User-Agent laufen lassen. Für jede Domain hat es:

1. https://<domain>/ abgerufen (mit Fallback auf www.) und das Ergebnis nur behalten, wenn die finale Antwort eine HTML-Seite mit Status 200 war.
2. Die Header Last-Modified, ETag und Date notiert.
3. Die Seite ohne bedingte Header erneut abgerufen, um zu prüfen, ob die Validatoren stabil bleiben, und um eine 200 bei bereits offener Verbindung zu messen.
4. Das ETag in If-None-Match, dann das Datum in If-Modified-Since, dann beide zusammen erneut gesendet und jeden Statuscode notiert.
5. Die Schritte 2 bis 4 für /sitemap.xml wiederholt, wenn diese ein <urlset> oder <sitemapindex> lieferte.

Eine 200 mit demselben Validator, den wir geschickt hatten, gilt als „ignoriert“; eine 200 mit anderem Validator als „geändert“. 87 Domains blockierten die Anfrage (401, 403, 429, 503 oder eine Bot-Prüfung) und 364 hatten keine nutzbare Startseite, die Anteile oben beziehen sich also auf die 549, die antworteten.

Die Grenzen sind wichtig. Das ist ein Standort und ein Browser-User-Agent, nicht der Googlebot, und CDNs können Crawler anders behandeln. Unser Website-Crawl-Test ruft eine Seite mit dem User-Agent des Googlebots ab, wenn Sie sehen möchten, was Ihr Server ihm zurückgibt. Der Test deckt Startseiten und Sitemaps ab, keine Artikel-Templates. Skript und Rohdaten bleiben gespeichert, damit wir den Test wiederholen und vergleichen können.

Warum diese Header für SEO wichtiger sind denn je

Google ist zunehmend offen mit den Grenzen des Crawl-Budgets umgegangen und sagt klar, wen das betrifft. Sein Leitfaden zum Crawl-Budget richtet sich an Websites mit mehr als einer Million einzelner Seiten, die sich wöchentlich ändern, oder mehr als 10.000, die sich täglich ändern. Darunter ist das Crawl-Budget selten der Engpass, die Einsparungen bei Bandbreite und Server gelten aber trotzdem.

1. Geschontes Crawl-Budget

Ihre Website hat ein begrenztes Crawl-Budget, also die Zahl der Seiten, die der Googlebot in einem bestimmten Zeitraum crawlt. Liefern unveränderte Seiten eine 304 statt des vollständigen Inhalts, kann der Googlebot mehr Ressourcen für neue und aktualisierte Inhalte einsetzen.

Googles eigene Formulierung: „If a page hasn't changed since Google last crawled it, returning a 304 code tells Google to reuse the cached version, saving your server bandwidth and resources.“ Hat sich eine Seite seit dem letzten Crawl nicht geändert, sagt eine 304 Google also, die gespeicherte Version wiederzuverwenden, und spart Ihnen Bandbreite und Serverressourcen.

2. Schnellere Server-Antwortzeiten

Eine 304 zu liefern geht schneller, als die ganze Seite zu erzeugen und zu senden, aber der Unterschied ist kleiner als gedacht, sobald die Verbindung steht. Bei den 204 Startseiten, die auf eine bedingte Anfrage mit 304 antworteten, dauerte die mittlere 200 bei offener Verbindung von Istanbul aus 114 ms und die mittlere 304 73 ms, eine mittlere Ersparnis von 25 ms pro Anfrage. Der größere Gewinn liegt auf Ihrer Seite: Der Server muss die Seite gar nicht erst rendern, wenn er den Validator günstig prüfen kann.

3. Geringere Bandbreitenkosten

Bei Websites mit viel Traffic summieren sich die Bandbreitenkosten. Die mittlere Startseite in dieser Gruppe hatte 141,6 KB HTML nach dem Entpacken, und eine 304 sendet nichts davon. Rechnen Sie das auf jeden Bot und jeden wiederkehrenden Browser hoch, der neu validiert, dann liegt die Ersparnis eher bei Bytes und CPU als bei Millisekunden. KI-Crawler kommen inzwischen zu diesem Bot-Traffic hinzu; unser monatlicher KI-Crawler-Bericht verfolgt, welche am meisten crawlen.

4. Bessere Nutzererfahrung

Schnellere Ladezeiten bedeuten eine bessere Erfahrung für wiederkehrende Besucher: Ein Browser, der eine Seite schon gespeichert hat und eine 304 bekommt, kann sie anzeigen, ohne sie erneut herunterzuladen. Halten Sie die Ranking-Erwartung realistisch: Laut Googles Dokumentation zur Nutzerfreundlichkeit nutzen die Rankingsysteme Core Web Vitals, aber eine 304 hilft beim ersten Besuch nicht, und gute Werte garantieren keine Top-Rankings. Das größere Bild zeigt, wie sich die Ladegeschwindigkeit auf Rankings und Nutzerverhalten auswirkt.

ETag oder Last-Modified: Was nutzt Google?

Google nutzt das ETag, wenn beide vorhanden sind, und empfiehlt trotzdem, beide zu senden. Die beiden Validatoren unterscheiden sich auf einem echten Server in wichtigen Punkten:

Schwache ETags (mit dem Präfix W/) sind dafür in Ordnung. Nach RFC 9110 nutzt If-None-Match den schwachen Vergleich, W/"abc" passt also weiterhin. 53,3 % der Startseiten-ETags in unserem Test waren schwach.

Häufige Fehler bei der Umsetzung

Diese Probleme haben wir in unserem Test am häufigsten gesehen:

Last-Modified-Header fehlen ganz

Manche Server und CMS-Plattformen senden standardmäßig keinen Last-Modified-Header. Ohne diesen Header (oder ein ETag) können Browser und Crawler keine bedingten Anfragen stellen, und jeder Besuch lädt den vollständigen Inhalt herunter. Das betraf 51,2 % der getesteten Startseiten.

So prüfen Sie es: Sehen Sie in den Browser-DevTools (Tab „Netzwerk“) oder mit einem HTTP-Header-Checker nach, ob Ihre Seiten Last-Modified- oder ETag-Header liefern. Die Prüfschritte weiter unten zeigen, wie.

Falsche Zeitstempel

Last-Modified bei jeder Anfrage auf die aktuelle Serverzeit zu setzen, macht den ganzen Zweck zunichte. Der Zeitstempel muss angeben, wann sich der Inhalt tatsächlich zuletzt geändert hat, nicht wann er zuletzt angefragt wurde. RFC 9110 verbietet außerdem ein Last-Modified-Datum, das nach dem Date-Header der Antwort liegt.

Ein ETag, das sich bei jeder Anfrage ändert

Das ist die ETag-Variante desselben Fehlers, und sie war häufiger: 15,6 % der Startseiten-ETags änderten sich zwischen zwei identischen Anfragen. Frameworks, die das gerenderte HTML hashen (Next.js macht das standardmäßig mit generateEtags), erzeugen ein neues ETag, sobald das HTML einen Wert pro Anfrage enthält. Bilden Sie das ETag aus dem Inhalt oder seiner Version, nicht aus der Antwort.

Apaches -gzip-Suffix am ETag

Die meisten übrigen, darunter ibm.com, hp.com und avast.com, beantworteten ein erneut gesendetes Datum mit 304 und ein erneut gesendetes ETag mit der ganzen Seite. Ab Apache 2.4.58 behebt die Direktive DeflateAlterETag das (siehe den Apache-Abschnitt unten).

Dynamische Inhalte übersehen

Seiten mit dynamischen Elementen (nutzerspezifische Inhalte, Echtzeitdaten) brauchen besondere Sorgfalt. Der Last-Modified-Header sollte den jüngsten Änderungszeitpunkt aller Bestandteile angeben, nicht nur den des Templates.

Konflikte mit Cache-Control

Wenn Sie Cache-Control: no-cache zusammen mit Last-Modified senden, validieren Browser trotzdem beim Server, und wenn dieser mit 304 antwortet, nutzen sie die gespeicherte Kopie. Stimmen Sie Ihre Cache-Direktiven auf Ihre Validierungsstrategie ab. no-cache plus ein funktionierender Validator ist für HTML eine vernünftige Grundeinstellung: Jeder Besuch fragt beim Server nach, und unveränderte Seiten kosten nur eine 304. Google ergänzt, dass ein max-age in Cache-Control seinen Crawlern helfen kann, den Zeitpunkt für den nächsten Crawl zu bestimmen, und dass andere Caching-Direktiven von seinen Crawlern nicht unterstützt werden.

Umsetzung auf gängigen Plattformen

Cache-Header in WordPress

WordPress-Websites profitieren von Cache-Plugins, die diese Header übernehmen, aber die Plugins unterscheiden sich bei den Validatoren stärker, als ihre Funktionslisten vermuten lassen. Das tun drei verbreitete Plugins, geprüft in ihrem Quellcode am 31. Oktober 2026:

• WP Super Cache: kostenlos. Die erweiterten Einstellungen enthalten die Option „304 Browser caching“, die das Plugin empfiehlt, aber standardmäßig ausgeschaltet lässt, weil manche Hosts früher Probleme mit den verwendeten Headern hatten. Im mod_rewrite-Modus liefert der Webserver die gecachten Dateien aus und sendet seine eigenen Validatoren.
• W3 Total Cache: kostenlos, mit mehr Einstellungsmöglichkeiten und Browser-Cache-Optionen in den Einstellungen: „Set Last-Modified header“ und „Set entity tag (ETag)“ für HTML, beide standardmäßig aktiv.
• WP Rocket: kostenpflichtig, jährlich abgerechnet. Die erzeugte .htaccess entfernt auf Apache die ETags (Header unset ETag und FileETag None), gecachte Seiten verlassen sich also auf Last-Modified.

Für WordPress gibt es außerdem eigene Last-Modified-Plugins, wenn Sie genaue Kontrolle ohne komplette Caching-Lösung möchten.

Apache-Konfiguration

Für statische Dateien sendet Apache Last-Modified von selbst und bildet das ETag aus den Dateiattributen, die in FileETag festgelegt sind. Auf Apache-Servern fügen Sie diese Direktiven in Ihre .htaccess oder Serverkonfiguration ein.

Die erste Zeile behält das Standardrezept für das ETag bei (Änderungszeit und Größe); der Block darunter sagt Caches, nach Ablauf der Stunde beim Server neu zu validieren.

FileETag MTime Size

<IfModule mod_headers.c>
  Header set Cache-Control "public, max-age=3600, must-revalidate"
</IfModule>

Wenn Sie mit mod_deflate ab Apache 2.4.58 komprimieren, beheben Sie zusätzlich das ETag-Suffix. DeflateAlterETag funktioniert nur in der Server- oder VirtualHost-Konfiguration, nicht in der .htaccess:

DeflateAlterETag Remove

Remove entfernt das ETag aus komprimierten Antworten, sodass Last-Modified übernimmt. NoChange behält stattdessen ein ETag für beide Kodierungen, was laut Apache-Dokumentation die Regel verletzt, dass jede Repräsentation ihr eigenes ETag hat. Seiten, die Ihre Anwendung erzeugt (PHP, Python, Node), brauchen weiterhin eine Anwendung, die einen Validator setzt und die bedingte Anfrage beantwortet.

Nginx-Konfiguration

Nginx setzt Last-Modified-Header für statische Dateien automatisch. Für dynamische Inhalte konfigurieren Sie Ihre Anwendung so, dass sie passende Zeitstempel setzt:

location / {
  add_header Cache-Control "public, max-age=3600";
  # Beide sind standardmäßig aktiv und gelten für Dateien, die Nginx selbst ausliefert
  etag on;
  if_modified_since exact;
}

Laut Nginx-Dokumentation gilt etag für statische Ressourcen. exact bedeutet eine 304 nur dann, wenn das Datum genau mit der Änderungszeit der Datei übereinstimmt, und genau dieses Datum schicken Browser und Crawler zurück.

So prüfen Sie Ihre Umsetzung

Verlassen Sie sich nicht darauf, dass Ihre Header funktionieren. Prüfen Sie es. So gehen Sie vor:

1. Response-Header prüfen: Bestätigen Sie mit curl, den Browser-DevTools oder dem HTTP-Header-Checker, dass Ihre Seiten Last-Modified- oder ETag-Header liefern.
2. Bedingte Anfragen testen: Senden Sie eine Anfrage mit einem If-Modified-Since-Header, der dem Last-Modified-Zeitstempel entspricht; Sie sollten eine 304 bekommen. Machen Sie dasselbe mit If-None-Match und dem ETag.
3. Search Console beobachten: Behalten Sie die Crawling-Statistiken im Blick. Der Bericht gruppiert die Anfragen des Googlebots nach Antwort, und Not modified (304) zählt zu den guten Antwortcodes. Steigt der 304-Anteil nach der Korrektur, funktioniert sie.
4. Mehr als die Startseite testen: Prüfen Sie eine URL pro Template (Artikel, Kategorie, Produkt), weil jedes anders gebaut sein kann.

Diese curl-Befehle decken die Schritte 1 und 2 ab. Der erste zeigt, welche Validatoren die Seite sendet; die beiden anderen schicken sie einzeln zurück (setzen Sie Ihre eigenen Werte ein):

curl -sI --compressed https://example.com/ | grep -iE '^(etag|last-modified|cache-control)'
curl -s -o /dev/null -w '%{http_code}\n' --compressed -H 'If-None-Match: "abc123"' https://example.com/
curl -s -o /dev/null -w '%{http_code}\n' --compressed -H 'If-Modified-Since: Thu, 15 Jan 2026 14:30:00 GMT' https://example.com/

Eine richtig konfigurierte Seite sollte auf eine bedingte Anfrage so antworten:

HTTP/1.1 304 Not Modified
Date: Thu, 29 Jan 2026 10:00:00 GMT
ETag: "abc123"
Cache-Control: public, max-age=3600

RFC 9110 verlangt, dass eine 304 die Header wiederholt, die eine 200 getragen hätte, etwa Date, ETag, Cache-Control und Vary.

Was Sie nach der Korrektur erwarten können

Rechnen Sie damit, dass sich die Änderung in Ihren Logs und den Crawling-Statistiken zeigt, nicht als Ranking-Sprung. Google beschreibt den Effekt als eingesparte Bandbreite und Ressourcen, dazu die Chance, mehr von Ihrer Website zu lesen, wenn Seiten schneller laden; Ranking-Gewinne verspricht es nicht. In unserem Test sparte jede 304 im Mittel 141,6 KB HTML und 25 ms gegenüber einer 200 bei offener Verbindung (Startseiten, 31. Oktober 2026).

Am meisten profitieren Websites, die groß genug für ein Crawl-Budget-Problem sind. Prüfen Sie dort in den Crawling-Statistiken, wie viele Googlebot-Anfragen bereits mit 304 enden. Kleineren Websites bringen die häufigsten technischen SEO-Probleme meist mehr.

Das Wichtigste in Kürze

If-Modified-Since- und Last-Modified-Header richtig umzusetzen, gehört zu den günstigeren technischen SEO-Korrekturen. Das sollten Sie sich merken:

• Cache-Header schonen das Crawl-Budget, weil sie dem Googlebot sagen, wann sich ein Inhalt nicht geändert hat.
• 304-Antworten sind leichter als das wiederholte Ausliefern des vollen Inhalts: kein Inhalt und oft keine Seite zum Rendern.
• Google nutzt das ETag, wenn beide Validatoren vorhanden sind, testen Sie also If-None-Match, nicht nur If-Modified-Since.
• Viele Server müssen erst konfiguriert werden, um korrekte Last-Modified-Zeitstempel zu senden: Die Hälfte der getesteten Top-Startseiten sendete gar keinen Validator, und 23,6 % derer mit Validator lieferten nie eine 304.
• Prüfen ist Pflicht. Testen Sie immer, ob Ihre Umsetzung funktioniert, und zwar mit eingeschalteter Komprimierung.
• Die Summe zählt. Kleine Einsparungen pro Anfrage vervielfachen sich über Tausende von Seiten.

Ob Sie das von Hand umsetzen oder ein Caching-Plugin nutzen: Lassen Sie diese Optimierung nicht aus. Der Zeitaufwand ist gering, die Wirkung auf Crawlbarkeit und Leistung Ihrer Website kann aber erheblich sein.

Lassen Sie Ihre eigenen Templates durch den Header-Checker laufen und schicken Sie die Validatoren dann mit den curl-Befehlen oben zurück. Kommen beide Anfragen mit eingeschalteter Komprimierung als 304 zurück, müssen Crawler und Browser unveränderte Seiten nicht mehr neu herunterladen.

Häufig gestellte Fragen

Was ist der Last-Modified-Header?

Last-Modified ist ein HTTP-Response-Header, der dem Client Datum und Uhrzeit nennt, zu der sich die Ressource laut Server zuletzt geändert hat, im Format Thu, 15 Jan 2026 14:30:00 GMT. Browser und Crawler schicken ihn in If-Modified-Since zurück, damit der Server mit 304 Not Modified antworten kann, statt die Seite erneut zu senden.

Was ist der Unterschied zwischen If-Modified-Since und If-None-Match?

If-Modified-Since schickt ein Datum zurück, If-None-Match ein ETag. RFC 9110 weist Server an, If-Modified-Since zu ignorieren, wenn If-None-Match vorhanden ist. In unserem Test vom Oktober 2026 beachteten Startseiten das Datum in 86,7 % und das ETag in 58,1 % der Fälle.

Sollte ich für SEO Last-Modified oder ETag verwenden?

Beides. Google empfiehlt für seine Crawler ETag, weil es keine Probleme mit dem Datumsformat hat, und nutzt das ETag, wenn beide vorhanden sind. Seine Dokumentation rät aber auch, beide zu setzen, weil andere Software sie ebenfalls liest. Testen Sie danach, ob beide eine 304 liefern.

Sendet der Googlebot If-Modified-Since?

Der Googlebot unterstützt Caching, wenn er URLs für die Google-Suche erneut crawlt, und sendet die gespeicherten Validatoren zurück: If-None-Match für ein ETag, If-Modified-Since für ein Datum. Nicht jeder Google-Crawler tut das; laut Googles Dokumentation cacht Storebot-Google nur unter bestimmten Bedingungen.

Schadet eine 304-Antwort dem SEO?

Nein. Die Search Console führt Not modified (304) bei den guten Antwortcodes, und Googles Leitfaden zum Crawl-Budget bittet Websites, sie zu unterstützen. Eine 304 sagt Google, die Kopie wiederzuverwenden, die es bereits hat.

Wie finde ich heraus, wann eine Website zuletzt geändert wurde?

Der Last-Modified-Header ist ein Hinweis, aber viele Websites senden ihn nicht (67,2 % der getesteten Startseiten nicht), und manche setzen ihn auf die aktuelle Zeit. Das browsereigene document.lastModified liest denselben Header und gibt, wenn keiner da ist, das aktuelle Datum und die aktuelle Uhrzeit zurück, ist also auch kein Beweis. Weitere Wege zeigt unser Beitrag dazu, wann eine Website zuletzt aktualisiert wurde, von Sitemaps und strukturierten Daten bis zum Internet Archive.