304 Not Modified und ETag: Wie Sie das Crawling des Googlebots effizienter machen

Wir von Talha Aslan und Team begegnen diesem Thema regelmäßig in technischen SEO Audits. Viele Websitebetreiber halten eine Antwort mit 304 Not Modified für einen Fehler. Richtig eingerichtet bewirkt sie allerdings das Gegenteil: Der Googlebot lädt bei unveränderten Seiten nicht das gesamte HTML herunter und kann seine Kapazität deshalb auf neue oder aktualisierte Adressen verwenden. Eine fehlerhafte Einrichtung ist dagegen riskant, denn Google behält dann womöglich eine veraltete Fassung einer Seite, die Sie gerade bearbeitet haben.

In diesem Leitfaden erklären wir bedingte Anfragen, die Header Last-Modified und ETag, wie Google diese laut offizieller Dokumentation nutzt und was Sie in CDN und Cache prüfen sollten. Codeblöcke zeigen wir bewusst nicht. Das Ziel ist, dass Sie mit Ihrem Entwickler oder Ihrem Hostingteam dieselbe Sprache sprechen.

Wie funktioniert eine bedingte Anfrage (Conditional Request) konkret?

Bei einer bedingten Anfrage sagt der Client: „Wenn meine gespeicherte Kopie noch gültig ist, schick mir den Inhalt nicht erneut.“ Beim ersten Besuch liefert der Server die Seite mit 200 OK aus und hängt einen Validator an. Dieser Validator ist entweder ein Datum (Last-Modified) oder eine inhaltsbezogene Kennung (ETag).

Beim nächsten Besuch schickt der Client diesen Validator zurück. Der Server vergleicht ihn und wählt dann eines von zwei Ergebnissen:

1. Hat sich der Inhalt nicht geändert, antwortet er mit 304 Not Modified und ohne Inhalt.
2. Hat sich der Inhalt geändert, liefert er mit 200 OK den neuen Inhalt und einen neuen Validator.

Dieser Mechanismus gehört nicht allein zum Googlebot. Browser nutzen zudem genau dasselbe Verfahren. Zum Beispiel betont der Leitfaden zum HTTP Cache auf web.dev, dass bei einer Antwort mit 304 nur sehr wenige Daten fließen. Ein sauber eingerichteter Ablauf hilft also sowohl dem Nutzererlebnis als auch der Crawlingeffizienz.

Entscheidend ist dabei Folgendes: Die Entscheidung fällt auf dem Server. Der Client sagt nur „Ich habe diese Fassung“. Ob sich die Seite wirklich verändert hat, muss daher allein Ihr System zuverlässig wissen.

Was leisten die Header Last-Modified und If-Modified-Since?

Last-Modified ist ein Antwortheader. Der Server sendet ihn mit der Seite und nennt darin das Datum der letzten Änderung. If-Modified-Since ist dagegen ein Anfrageheader, den der Client bei der nächsten Anfrage mitschickt. Das heißt: Der erste kommt vom Server, der zweite geht zum Server zurück.

Der Ablauf sieht so aus. Beim ersten Crawlen sieht der Googlebot in der Antwort den Wert von Last-Modified. Die Google Dokumentation zu Crawlingfehlern erklärt, dass dieser Wert beim Senden von If-Modified-Since dem Datum und der Uhrzeit des letzten Crawlings entspricht. Gab es danach keine Änderung, darf der Server mit 304 Not Modified antworten.

Das Datumsformat spielt außerdem eine große Rolle. Die Übersicht zu den Google Crawlern verlangt, dass das Datum dem HTTP Standard folgt. Daher machen Datumsangaben in lokaler Zeitzone, mit deutschen Monatsnamen oder in unvollständiger Form Probleme. Das Standardformat enthält Wochentag, Tag, abgekürzten Monat, Jahr, Uhrzeit und die Angabe GMT.

Zudem sollte das Datum den Moment einer inhaltlich relevanten Änderung abbilden. Ein System, das bei jeder Anfrage die aktuelle Uhrzeit ausgibt, macht den Header wertlos. Denn die Seite wirkt dann jedes Mal neu, und eine Antwort mit 304 entsteht nie.

Warum bevorzugt Google ETag und If-None-Match?

Ein ETag ist eine eindeutige Kennung, die der Server einer bestimmten Fassung einer Ressource zuweist. In der Praxis funktioniert er wie ein Fingerabdruck (Hashwert) des Inhalts. Bei der nächsten Anfrage sendet der Client diese Kennung im Header If-None-Match zurück. Stimmt sie überein, antwortet der Server mit 304 Not Modified, sonst liefert er den neuen Inhalt.

Google äußert hier eine klare Präferenz. Laut derselben Crawlerübersicht verwenden die Google Crawler den ETag, wenn eine Antwort sowohl ETag als auch Last-Modified enthält. Außerdem empfiehlt Google, die Cachepräferenz eher per ETag als per Datum anzugeben. Der Grund ist praktisch: Mit dem ETag müssen Sie sich nicht um Probleme bei der Datumsformatierung kümmern.

Ist der Datumsheader also überflüssig? Keineswegs. Manche Clients und Zwischenschichten werten nur Datumsangaben aus. Deshalb ist es in der Praxis am robustesten, beide Header gemeinsam und widerspruchsfrei zu senden. In unseren Audits prüfen wir zunächst, ob der ETag stabil bleibt. Danach prüfen wir, ob das Datum zu echten Änderungen passt.

Dasselbe Dokument erwähnt zudem das Feld max-age im Header Cache-Control. Es ist optional, kann den Crawlern allerdings bei der Entscheidung helfen, wann sie eine Adresse erneut crawlen. Andererseits stellt Google klar, dass es andere HTTP Cachedirektiven nicht unterstützt.

Wie bewertet Google eine Antwort mit 304 Not Modified?

Die Google Dokumentation zu HTTP Statuscodes beantwortet diese Frage direkt. Erhalten die Crawler eine 304, melden sie dem nächsten Verarbeitungssystem, dass der Inhalt dem letzten Crawling entspricht. Für die Indexierung heißt es dort, die Pipeline könne Signale für die Adresse neu berechnen, ansonsten habe der Statuscode keine Auswirkung auf die Indexierung.

Dieser Satz hat praktische Folgen. Eine Antwort mit 304 Not Modified:

• entfernt die Seite nicht aus dem Index.
• hebt oder senkt das Ranking nicht von sich aus.
• sorgt dafür, dass Google die früher gespeicherte Kopie weiterverwendet.
• senkt die Kosten für das Erzeugen und Senden des Seiteninhalts.

Kurz gesagt ist die 304 ein Effizienzmechanismus und kein Rankingsignal. Niemand kann seriös versprechen, dass Sie mit einer solchen Einrichtung nach oben klettern, und auch wir versprechen das nicht. Haben Sie allerdings sehr viele Seiten, kann weniger Aufwand für unveränderte Adressen indirekt dazu beitragen, dass wichtige Seiten regelmäßiger an die Reihe kommen.

Umgekehrt gilt ebenso: Liefern Sie nach einer Änderung trotzdem eine 304, nutzt Google weiter die alte Kopie. Deshalb zählt die Korrektheit der Einrichtung mehr als ihre bloße Existenz.

Sendet der Googlebot bei jeder Anfrage bedingte Header?

Nein. Die Google Seite zur Fehlerbehebung erklärt, dass die Crawler diese Header nicht bei jedem Crawlversuch mitsenden. Stattdessen hängt das vom Zweck der Anfrage ab. Die Seite merkt zudem an, dass AdsBot sie mit höherer Wahrscheinlichkeit sendet.

Dieselbe Seite enthält außerdem ein interessantes Detail. Ein Server darf auf jede Anfrage des Googlebots eine 304 ohne Inhalt senden, wenn sich der Inhalt seit dem letzten Besuch nicht geändert hat, selbst wenn die Anfrage keine bedingten Header enthält. Dafür muss Ihr Server allerdings wissen, wann der Googlebot zuletzt da war, und das erfordert auf den meisten Websites zusätzliche Logik.

Zudem nutzt nicht jeder Google Crawler den Cache auf dieselbe Weise. Laut Google unterstützt der Googlebot das Caching beim erneuten Crawlen für die Google Suche, Storebot-Google dagegen nur unter bestimmten Bedingungen. Sehen Sie also in den Logs, dass manche Google Anfragen immer eine 200 erhalten, ist das allein noch kein Defekt.

Anders gesagt: Ihr Ziel sollte nicht sein, dass jede Googlebot Anfrage eine 304 bekommt. Ihr Ziel ist, dass der Server bei jeder bedingten Anfrage richtig entscheidet.

Warum ist 304 Not Modified für die Crawlingeffizienz wichtig?

Der Google Leitfaden zur Verwaltung des Crawl Budgets nennt HTTP Caching und die Unterstützung des Statuscodes 304 ausdrücklich als Empfehlungen. Hat sich eine Seite seit dem letzten Crawling nicht geändert, teilt laut Leitfaden eine 304 Google mit, die zwischengespeicherte Fassung erneut zu verwenden.

Derselbe Leitfaden verknüpft die Crawlingkapazität außerdem mit der Serverleistung. Bleiben die Antwortzeiten stabil oder verbessern sie sich, kann das Limit steigen. Schnelle Antworten ohne Inhalt helfen daher indirekt, weil sie die Serverlast senken. Mehr zur Servergeschwindigkeit lesen Sie in unserem Beitrag zu TTFB und SEO.

Das Konzept des Crawl Budgets wiederholen wir hier nicht; welche Websites sich wirklich damit befassen sollten, zeigt unser Leitfaden zum Crawl Budget. Ist Ihre Crawlrate plötzlich gesunken, finden Sie mögliche Ursachen in warum der Googlebot weniger crawlt.

Mit einer einmaligen Prüfung lässt sich kaum feststellen, ob solche Einstellungen auf Ihrer Website dauerhaft funktionieren. In unserer SEO Beratung beobachten wir Serverantworten, Logs und Search Console Daten gemeinsam, beheben das Problem auf Ihrer Website und verfolgen die Entwicklung weiter.

Welche Websites sollten 304 Not Modified vorrangig unterstützen?

Die Dringlichkeit ist zunächst nicht für jede Website gleich. Der Google Leitfaden zum Crawl Budget richtet sich grob an große Websites mit vielen eindeutigen Seiten und mäßig häufigen Änderungen, an mittlere oder größere Websites mit sehr schnell wechselnden Inhalten und an Websites mit vielen Adressen im Status „Discovered, currently not indexed“ in der Search Console.

Zu diesem Status haben wir einen eigenen Beitrag: was „gefunden, derzeit nicht indexiert“ bedeutet. Nach unserer Praxiserfahrung profitieren vor allem diese Websitetypen von der Unterstützung:

• E-Commerce Shops mit Tausenden Produktseiten und Kategorieseiten.
• Nachrichtenportale und Contentseiten mit großem, selten geändertem Archiv.
• Kleinanzeigenportale und Katalogseiten, die Filterseiten und Listenseiten erzeugen.
• Mittelgroße Websites auf geteilten oder knapp bemessenen Servern.

Andererseits ist die Einrichtung für eine Unternehmenswebsite mit wenigen Dutzend Seiten keine Priorität. Dort bringt es mehr, zunächst Inhalte, interne Verlinkung und Indexierungsprobleme zu lösen. Unterstützt Ihre Plattform das Verfahren aber bereits standardmäßig, gibt es auch keinen Grund, es abzuschalten.

Worin unterscheiden sich 200 OK, 304 Not Modified und andere Antworten?

Die folgende Tabelle fasst die Erläuterungen der Google Dokumentation zu Statuscodes und ihre praktischen Folgen für das Crawling zusammen. Sie ist allerdings kein Rankingratgeber. Sie zeigt nur, was jeder Code Google mitteilt.

Der wichtigste Unterschied lautet: Eine 304 verhält sich wie eine Erfolgsmeldung, enthält aber keinen Inhalt. Eine 5xx bremst dagegen das Crawling. Liefert also ein defekter Cache plötzlich 5xx statt 304, kehrt sich die Crawlingeffizienz über Nacht um. Details zu Serverfehlern finden Sie im selben Google Dokument.

Wie testen Sie, ob Ihre Website 304 Not Modified liefert?

Bevor Sie beginnen, halten Sie eines fest: Sie wollen das Verhalten der Templates sehen, nicht nur einer einzelnen Seite. Wählen Sie daher aus jedem Template mindestens eine Adresse, etwa Startseite, Kategorie, Produkt oder Beitrag und eine statische Datei. Folgen Sie dann diesen Schritten:

1. Öffnen Sie in den Entwicklertools Ihres Browsers den Tab Netzwerk (Network) und stellen Sie sicher, dass die Option zum Deaktivieren des Caches ausgeschaltet ist.
2. Laden Sie die Seite zum ersten Mal und notieren Sie, ob die Antwort des Dokuments ETag und Last-Modified enthält.
3. Laden Sie die Seite normal neu und prüfen Sie, ob in der Statusspalte für das Dokument 304 steht.
4. Ändern Sie den Inhalt geringfügig und laden Sie erneut. Diesmal sollten Sie 200 und einen neuen ETag sehen.
5. Wiederholen Sie den Test mit einem HTTP Client auf der Kommandozeile und setzen Sie den ETag in den Header If-None-Match.

Schritt vier überspringen die meisten. Dabei deckt gerade er die eigentliche Gefahr auf. Ein System, das nach einer Änderung weiter 304 liefert, sagt Google, die alte Fassung zu behalten. Als Beispielszenario: Ändern Sie auf example.com/produkt den Preis und erhalten trotzdem eine 304, liegt das Problem im Cache.

Wo finden Sie 304 in den Crawlingstatistiken der Search Console?

In der Search Console finden Sie diese Daten im Bericht zu den Crawlingstatistiken (Crawl stats) unter den Einstellungen. Laut Google Hilfe gruppiert der Bericht die Antworten nach Typ und zeigt jeden Typ als Anteil aller Crawlantworten. Die Zeile „Not modified (304)“ bedeutet, dass sich die Seite seit der letzten Crawlanfrage nicht geändert hat.

Wir empfehlen außerdem einen Blick auf diese Bereiche:

• Crawlingzweck: Discovery steht für Adressen, die Google zuvor nie gecrawlt hat, Refresh für das erneute Crawlen bekannter Seiten.
• Durchschnittliche Antwortzeit: der Mittelwert für alle Ressourcen, die Google im gewählten Zeitraum abgerufen hat.
• Hoststatus: ob Google beim Crawlen Ihrer Website Verfügbarkeitsprobleme hatte.
• Aufschlüsselung nach Dateityp und Googlebot Typ: So trennen Sie, welche Ressourcen Google wie oft crawlt.

Bei der Deutung ist allerdings Vorsicht geboten. Hat eine Website viele Refresh Crawls und liegt der Anteil der 304 nahe null, funktioniert die Unterstützung womöglich gar nicht. Andererseits veröffentlicht Google keinen Zielwert für diesen Anteil. Daher nennen wir Ihnen keine Schwelle. Sinnvoll ist, im selben Bericht den Zeitraum vor und nach einer Änderung zu vergleichen.

Wie lesen Sie Zeilen mit 304 Not Modified in Serverlogs?

Die Search Console liefert eine zusammengefasste Sicht. Serverlogs zeigen dagegen jede einzelne Anfrage. Deshalb sind Logs der verlässlichste Weg, die Einrichtung zu prüfen. Hier konzentrieren wir uns auf die Punkte, die speziell für 304 gelten.

Stellen Sie Ihren Logs folgende Fragen:

1. Kommen die Anfragen, die sich als Googlebot ausgeben, wirklich von Google? Lassen Sie die von Google empfohlene umgekehrte DNS Abfrage nicht weg.
2. Welche Templates erhalten nie eine 304? Erhalten zum Beispiel Beiträge eine 304, Produktseiten aber immer eine 200, unterscheiden sich die Templates.
3. Ist die Antwortgröße bei Adressen mit 304 tatsächlich nahe null?
4. Hat am Tag einer Aktualisierung die erste Googlebot Anfrage für diese Adresse eine 200 erhalten?

Große Logdateien von Hand zu durchsuchen kostet allerdings viel Zeit. Einen ersten Durchgang erledigen Sie daher mit unserem Werkzeug zur Logfile Analyse und sehen die Verteilung nach Statuscodes. Danach prüfen Sie die verdächtigen Templates einzeln. So ersetzen Sie die vage Annahme „die Website kann 304“ durch einen Beleg, wo es wirklich funktioniert.

Welche Probleme verursacht ein falscher Wert im Datumsheader?

Es gibt zwei typische Fehler beim Header Last-Modified, und beide schaden auf unterschiedliche Weise. Erstens ein Datum, das immer „jetzt“ lautet. Dann wirkt die Seite bei jeder Anfrage neu, bedingte Anfragen enden nie mit 304, und der Effizienzgewinn verschwindet vollständig.

Zweitens, und das ist tückischer: ein Datum, das sich nie ändert. Ein Template gibt zum Beispiel das ursprüngliche Erstellungsdatum der Seite aus. Selbst nach einer Aktualisierung meldet der Server dann womöglich „unverändert“ und liefert 304. Folglich sieht Google den neuen Preis, den neuen Abschnitt oder Ihre Korrektur eventuell nicht.

Ein drittes Problem betrifft Bausteine der Seite. Der Haupttext einer Produktseite bleibt vielleicht gleich, während Lagerstatus, Preis oder Bewertungsanzahl wechseln. Berücksichtigt das Datum nur den Haupttext, übersieht das System Änderungen, die Nutzer tatsächlich sehen.

Daraus folgt unsere Empfehlung. Das Datum sollte die letzte Änderung aller relevanten Daten abbilden, die die HTML Ausgabe beeinflussen. Nebensächliche Teile wie das Copyrightjahr oder ein zufälliger Empfehlungskasten sollten es dagegen nicht auslösen.

Wie erzeugen Sie auf dynamischen Seiten einen korrekten ETag?

Am robustesten denken Sie den ETag als Fingerabdruck des relevanten Seiteninhalts. Gleicher Inhalt ergibt also denselben Fingerabdruck, geänderter Inhalt einen anderen. Damit spiegelt die Kennung den echten Zustand der Seite. Auf dynamischen Websites bricht diese einfache Idee allerdings an einigen Stellen.

Diese Schwachstellen sehen wir am häufigsten:

• Ein Teil, der sich bei jeder Antwort ändert, etwa ein Sitzungstoken, ein Zeitstempel oder eine Zufallskennung, fließt in den Fingerabdruck ein, sodass der ETag jedes Mal anders ausfällt.
• Hinter mehreren Servern erzeugt jeder Server für dieselbe Datei einen anderen ETag; der Client sieht dann je nach antwortendem Server eine andere Kennung.
• Die Komprimierung vergibt für komprimierte und unkomprimierte Fassung denselben starken ETag oder entfernt ihn ganz.
• Personalisierte Inhalte gehen mit derselben Kennung an angemeldete und nicht angemeldete Nutzer.

Der HTTP Standard unterscheidet schwache (weak) und starke (strong) ETags. Eine schwache Kennung behandelt inhaltlich gleichwertige Fassungen als gleich, eine starke verlangt bytegenaue Übereinstimmung. Welche Sie wählen, hängt von Ihrer Technik ab. Wichtig ist nur, dass derselbe Inhalt auf jedem Server und bei jeder Anfrage dieselbe Kennung erhält.

Wie beeinflussen CDN und Cache den Ablauf von 304 Not Modified?

Nutzen Sie ein CDN oder einen Reverse Proxy, spricht der Googlebot oft mit dieser Zwischenschicht statt mit Ihrem Ursprungsserver. Folglich müssen Sie wissen, wer die Entscheidung über die 304 trifft. Manchmal prüft das CDN seine eigene Kopie und antwortet selbst, manchmal leitet es die Anfrage an den Ursprung weiter.

Dabei sind drei Fälle möglich. Erstens reicht das CDN ETag und Datum des Ursprungs unverändert durch, was der Idealfall ist. Zweitens entfernt das CDN diese Header oder ersetzt sie durch eigene Werte, wodurch Ihre Arbeit am Ursprung verpufft. Drittens hält das CDN eine veraltete Kopie zu lange und liefert 304, obwohl sich der Inhalt geändert hat.

Der dritte Fall ist vor allem riskant. Ein Beispielszenario: Sie aktualisieren auf example.com eine Aktionsseite, leeren aber den CDN Cache nicht. Der Googlebot sendet eine bedingte Anfrage, das CDN findet eine Übereinstimmung mit dem alten ETag und antwortet mit 304. Google nutzt somit weiter die veraltete Kopie.

Planen Sie einen Reverse Proxy Cache, finden Sie die grundlegende Konfigurationslogik in unserem Leitfaden zu Varnish Cache. Unabhängig vom Werkzeug gilt dieselbe Regel: Den passenden Cacheeintrag bei jeder Inhaltsänderung zu leeren, muss ein fester Schritt in Ihrem Veröffentlichungsprozess sein.

Was gehört auf eine Checkliste für CDN und Cachekonfiguration?

Gehen Sie die folgende Liste mit Ihrem Team durch, wenn Sie ein neues CDN einrichten oder ein Cacheplugin wechseln. Jeden Punkt haben wir als Testfrage formuliert. Jeder Punkt ohne klares „Ja“ verdient eine genauere Prüfung.

1. Enthalten HTML Antworten einen ETag oder ein Änderungsdatum?
2. Reicht das CDN diese Header unverändert vom Ursprung durch?
3. Liefert dieselbe Adresse an verschiedenen Edgestandorten denselben ETag?
4. Leert sich bei einer Inhaltsänderung der passende Cacheeintrag automatisch?
5. Erhält die erste bedingte Anfrage nach einer Aktualisierung 200 und einen neuen ETag?
6. Bleiben personalisierte oder sitzungsabhängige Seiten aus dem gemeinsamen Cache heraus?
7. Landen Fehlerseiten (404, 5xx) nicht fälschlich als 200 oder 304 im Cache?
8. Haben Sie die Werte für Cache-Control je Seitentyp bewusst gewählt?
9. Versionieren Sie statische Dateien wie CSS, JavaScript und Bilder?
10. Beobachten Sie nach jeder Änderung die Verteilung der Antworten in den Crawlingstatistiken?

Einmal ausfüllen reicht allerdings nicht. Wir empfehlen, die Liste nach jeder Änderung an Theme, Plugin oder CDN erneut durchzugehen. Denn das Verhalten bei 304 bricht oft unbemerkt, als Nebenwirkung einer ganz anderen Änderung.

Worauf sollten Sie bei WordPress und gehosteten Plattformen achten?

Bei WordPress, gehosteten Shopsystemen und Baukastensystemen bestimmen meist Webserver, Cacheplugin und CDN gemeinsam das Verhalten bei 304. Auch der Leitfaden auf web.dev erwähnt, dass manche Webserver diese Header standardmäßig setzen, andere dagegen erst nach entsprechender Konfiguration.

Bei WordPress sehen wir häufig folgendes Muster. Ein Plugin für den Seitencache erzeugt statisches HTML, und der Server versieht diese Dateien automatisch mit Headern. Liefert das Plugin eine Seite jedoch nicht aus, fehlt den dynamischen PHP Antworten meist der ETag. Zudem schreiben manche Sicherheitsplugins oder Performanceplugins Header um.

Auf gehosteten Plattformen ist Ihr Zugriff auf Servereinstellungen dagegen oft begrenzt. Dann ist das Beste, was Sie tun können, das aktuelle Verhalten mit den Testschritten oben zu messen. Wenden Sie sich danach bei Bedarf mit einem konkreten Beispiel an den Support der Plattform. Schreiben Sie also nicht „304 geht nicht“, sondern nennen Sie Adresse, Header und erwartetes Verhalten.

Hinweis: Wir sind kein Hostinganbieter und betreiben keine Server. Im Rahmen der SEO Beratung bereiten wir allerdings klare technische Befunde für Ihr Hostingteam oder Ihren Entwickler vor und prüfen das Ergebnis nach der Umsetzung gemeinsam mit Ihnen.

Wie halten Sie lastmod in der Sitemap und den Datumsheader synchron?

Das Tag lastmod in Ihrer Sitemap und der HTTP Header Last-Modified stehen an verschiedenen Orten, beantworten aber dieselbe Frage: Wann hat sich diese Seite zuletzt relevant geändert? Laut Google Dokumentation zu Sitemaps nutzt Google den Wert von lastmod, wenn er durchgängig und nachprüfbar korrekt ist. Als Beispiel nennt Google den Vergleich mit der letzten Änderung der Seite.

Was passiert, wenn beide Werte auseinanderliegen? Angenommen, die Sitemap meldet eine Änderung von gestern, während der Server ein Datum von vor Monaten ausgibt. Dann widersprechen sich die Signale. Dieser Widerspruch kann dazu führen, dass Google Ihren Angaben zu lastmod nicht mehr vertraut.

Unser Rat ist daher einfach: Erzeugen Sie beide Werte aus einer einzigen Quelle, nämlich dem Feld „letzte relevante Änderung“ Ihres Inhalts. Die richtige Nutzung erklären wir in unserem Leitfaden zu lastmod in der Sitemap, die Grundlagen in XML Sitemap erstellen: was sie ist und wie es geht. So erzählt Google sowohl die Sitemap als auch die HTTP Antwort dieselbe Geschichte.

Welche Fehler machen eine Einrichtung mit 304 gefährlich?

Die schädlichsten Fehler bei 304 Not Modified sind diejenigen, die die inhaltliche Richtigkeit beschädigen, nicht die Effizienz. Diese riskanten Fälle sehen wir in Audits am häufigsten:

• Eine 304 nach einer Inhaltsänderung, sodass Google die alte Fassung behält.
• Eine 304 ohne Inhalt während Wartung oder Fehler, die das Problem verdeckt.
• Eine 304 mit altem ETag auf weitergeleiteten Adressen, sodass Google das neue Ziel verpasst.
• Alte Header im Cache für Seiten, bei denen Sie noindex oder Canonical geändert haben.
• Dieselbe Kennung für mobile und Desktopfassung auf Websites mit unterschiedlichem HTML.

Alle diese Fehler haben eines gemeinsam. Das System meldet „unverändert“, obwohl sich etwas geändert hat. Fragen Sie beim Testen deshalb nicht nur „Bekomme ich eine 304?“, sondern auch „Bekomme ich nach einer Änderung eine 200?“. Die zweite Frage ist wichtiger als die erste.

Vor einer großen Templateänderung, einem Domainumzug oder einem neuen Theme ist es zudem eine sichere Gewohnheit, den Cache bewusst zu leeren und die ersten Crawls in den Logs zu beobachten.

Wann sollten Sie diese Aufgabe an ein SEO Team übergeben?

Bedingte Anfragen wirken auf dem Papier einfach. Auf echten Websites greifen allerdings Ursprungsserver, Cacheplugin, CDN, Load Balancer und CMS gleichzeitig ineinander. Die betroffene Schicht zu finden, bedeutet daher meist, Logs, Header und Search Console Daten zusammen zu lesen.

Wir empfehlen Unterstützung, wenn einer dieser Punkte auf Sie zutrifft:

• Sie haben Tausende Seiten, und der Googlebot erreicht wichtige Seiten erst spät.
• Google zeigt aktualisierte Inhalte noch lange in der alten Fassung.
• Ihre Crawlingstatistiken zeigen Serverfehler oder hohe Antwortzeiten.
• Sie planen den Wechsel zu einem neuen CDN oder einer neuen Cacheschicht.

Wir finden solche technischen Crawlingprobleme auf Ihrer Website, geben Ihren Entwicklern klare Umsetzungsschritte und verfolgen das Ergebnis regelmäßig. Rankings garantieren wir nicht. Stattdessen bauen wir einen messbaren Verbesserungsprozess auf, der sich auf die offizielle Google Dokumentation stützt. Ein auf Ihre Website zugeschnittenes Angebot erhalten Sie über unsere Seite zur SEO Beratung.

Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.