HTTP 304: unveränderte Inhalte effizient ausliefern

Google hat die Crawl-Budget-Dokumentation um Hinweise zu HTTP 304 ergänzt. Antwortet ein Server auf eine bedingte Anfrage bei unverändertem Inhalt mit 304, überträgt er den Antwortinhalt nicht erneut. Ob auch Rechenlast sinkt, hängt von der Implementierung ab. Google dokumentierte zugleich: Crawler haben unterschiedliche Nachfrage, nutzen aber ein gemeinsames Kapazitätslimit für den Host.

Was Google konkret geändert hat

Die zwei Dokumentationspunkte betreffen das gemeinsame Kapazitätslimit der Google-Crawler und die Unterstützung bedingter HTTP-Anfragen. Diese Punkte erklären eine technische Möglichkeit zur effizienteren Übertragung, keine Zusage für schnellere Indexierung oder bessere Rankings. Stand der Google-Dokumentation: Oktober 2026.

Wichtig zur Einordnung: Google richtet sich mit diesem Dokument primär an sehr grosse Websites mit über einer Million Seiten sowie an mittelgrosse Projekte ab rund 10'000 Seiten, die sich häufig ändern. Bei einer kleinen KMU-Website mit überschaubaren URLs sind in der Regel Erreichbarkeit, klare Links und indexierbarer Inhalt vorrangig. HTTP 304 allein erklärt nicht, warum eine Seite im Index fehlt.

Alle Crawler teilen sich denselben Topf

Die erste Neuerung räumt mit einem verbreiteten Missverständnis auf. Google beschreibt in der überarbeiteten Dokumentation (Juli 2026), dass jeder Crawler zwar eine eigene Crawl-Nachfrage hat, die Crawl-Kapazität aber über alle Crawler hinweg geteilt wird. Hohe Nachfrage von einem Crawler kann die verfügbare Kapazität für die anderen reduzieren.

Das gemeinsame Kapazitätslimit ist nicht gleichbedeutend mit identischer Crawl-Nachfrage: Googlebot, Bild- und Video-Crawler verfolgen unterschiedliche Aufgaben. Ob das gemeinsame Limit auf deiner Website zum Engpass wird, zeigen erst Logdaten und Crawl-Muster.

Für dich heisst das: Wenn du beobachtest, dass wichtige Seiten nur zäh gecrawlt werden, lohnt ein Blick in die Server-Logfiles und den Bericht zur Crawling-Statistik der Search Console. Prüfe, welche URL-Typen und Crawler tatsächlich betroffen sind, statt einem Bildarchiv oder Filtern ohne Messung die Ursache zuzuschreiben. Den allgemeinen Entscheidungsweg für URL-Räume erklärt Crawling steuern.

Bildkompression kann die Übertragung einzelner Ressourcen verringern. Ob sie bei deiner Website das Abrufmuster anderer Crawler verändert, ist eine Messfrage. Unnötige URL-Varianten zuerst nach ihrem wirklichen Crawl-Verhalten und Nutzerzweck beurteilen.

Der 304-Statuscode und was er wirklich macht

Die zweite Ergänzung ist die spannendere. Google empfiehlt in der Dokumentation ausdrücklich die Unterstützung des Statuscodes 304 (Not Modified). Auf eine bedingte Anfrage mit unverändertem Inhalt signalisiert 304, dass Google seine gespeicherte Version wiederverwenden kann. Der Antwortinhalt wird nicht erneut übertragen; ob zusätzlich Rechenarbeit auf dem Server entfällt, hängt davon ab, wie Validatoren und Ausgabe implementiert sind.

Technisch gehört 304 zur Gruppe der 3xx-Codes, die üblicherweise als Weiterleitungen gelten. Tatsächlich wird hier aber nichts weitergeleitet. Der Server sagt schlicht: Nichts Neues, du hast die aktuelle Fassung bereits. Der Body der Antwort bleibt leer, es wandern nur ein paar Header über die Leitung statt der kompletten HTML-Datei.

Der sichere Gewinn ist die vermiedene Übertragung des Antwortinhalts. Um einen Validator zu prüfen, kann der Server weiterhin Arbeit leisten; ein bestimmter Crawl- oder Indexierungseffekt lässt sich aus 304 allein nicht ableiten. Bei grossen, oft gecrawlten Beständen lohnt ein Vorher-Nachher-Vergleich der Antworten und Serverlast.

So funktioniert die Umsetzung

Ein 304 entsteht nicht von selbst, sondern im Dialog zwischen Crawler und Server. Der Ablauf sieht so aus:

Erster Abruf mit ETag

Bedingte Anfrage

304 ohne Antwortinhalt

1. Beim ersten Abruf liefert dein Server die Seite mit einem Last-Modified-Header und idealerweise einem ETag aus.
2. Beim nächsten Besuch schickt der Crawler diese Werte als If-Modified-Since beziehungsweise If-None-Match mit.
3. Dein Server vergleicht die Werte mit dem aktuellen Stand der Seite.
4. Stimmen sie überein, antwortet er mit 304 und ohne Inhalt. Gibt es Änderungen, kommt ein normaler 200 mit dem vollständigen HTML.

Ob dein System bedingte Anfragen korrekt beantwortet, prüfst du mit einem vom Server tatsächlich ausgegebenen Last-Modified-Wert oder ETag und dem passenden Folgeheader. Ein beliebiger Zeitwert ist kein aussagekräftiger Test. Die Crawling-Statistik zeigt Antworttypen, ersetzt aber keine URL-genaue Gegenprobe nach einer Inhaltsänderung.

Die Verantwortung liegt je nach Setup an unterschiedlichen Stellen. Bei einem eigenen Server ist es die Konfiguration von Apache oder Nginx. Bei einem CDN wie Cloudflare regelst du das über die Caching-Einstellungen. Und bei Website-Baukästen und gehosteten Plattformen übernimmt das der Anbieter, ohne dass du eingreifen kannst oder musst.

Diese Stolperfallen solltest du kennen

So elegant der 304 ist, so unangenehm wird er bei falscher Konfiguration. Der grösste Fehler: Eine geänderte Seite antwortet trotzdem mit 304. Dann kann Google die gespeicherte ältere Fassung wiederverwenden und die Änderung vorerst übersehen. Prüfe Validatoren und ausgelieferten Inhalt zusammen.

Kritisch wird das besonders bei dynamischen Inhalten. Preise, Verfügbarkeiten, Bewertungen oder automatisch eingebundene Blog-Teaser ändern sich, ohne dass eine statische Datei angefasst wird. Wenn dein Last-Modified-Wert nur am Dateidatum hängt, entsteht ein falsches Signal.

Zweiter Klassiker: uneinheitliche ETags über mehrere Server hinweg. Wer mit Loadbalancing arbeitet und pro Server unterschiedliche ETags generiert, produziert dauernd Cache-Misses. Der 304 verpufft, und schlimmstenfalls steigt die Last statt zu sinken.

Und drittens: 304 ersetzt keine saubere URL-Steuerung. Wenn Logs viele Parameter-URLs, Kalenderseiten oder Soft-404s zeigen, löst Caching diesen URL-Bestand nicht. Prüfe zuerst, welche Adressen Suchmaschinen abrufen sollen; dann optimiere die Übertragung unveränderter Antworten.

Du möchtest wissen, ob Google deine wichtigsten Seiten effizient crawlt?

netpulse analysiert dein Crawl-Budget, deine Serverantworten und technische SEO-Signale. Melde dich bei netpulse, um passende Massnahmen anhand deiner Serverantworten und wichtigen URLs zu besprechen.

Was du daraus mitnimmst

Für kleinere Websites ist der 304-Code eine nette Effizienzverbesserung, aber kein Ranking-Hebel. Bei einer kleinen Website sind Linkwege, Servererreichbarkeit und geeignete Inhalte meist vorrangig. Wer hier Zeit investiert, holt mehr aus Inhalten, interner Verlinkung und Ladezeit heraus.

Richtig relevant wird das Thema bei Shops, Portalen, Immobilienplattformen, Stellenbörsen und allen Projekten mit vielen, sich ständig verändernden URLs. Dort kann die Crawl-Effizienz ein wichtiger Prüfpunkt sein; wie schnell eine URL indexiert oder gezeigt wird, hängt von weiteren Faktoren ab.

Der beste erste Schritt ist unspektakulär: Schau dir an, was auf deiner Website überhaupt gecrawlt wird. Die Server-Logs und der Crawling-Bericht der Search Console zeigen dir, wohin die Kapazität fliesst. Erst wenn du das weisst, kannst du entscheiden, ob Caching-Header, eine aufgeräumte URL-Struktur oder ein schlankeres Bildarchiv die grössere Wirkung entfaltet.

Und eine gute Nachricht zum Schluss: In vielen modernen Hosting-Umgebungen und auf gepflegten Plattformen funktioniert die 304-Auslieferung bereits im Hintergrund. Ein bedingter URL-Test zeigt, ob dein Setup unveränderte Inhalte korrekt mit 304 beantwortet. Ob daraus ein spürbarer Vorteil folgt, misst du am konkreten Abrufmuster.

Quellen

• Google: Crawling-Budget optimieren, einschliesslich HTTP-Caching, Anwendungsgrenzen und Crawl-Kapazität.
• Google: Crawling-Statistik in der Search Console.