304 statt 200 - Crawl-Budget clever schonen

Google hat seine Crawl-Budget-Dokumentation aktualisiert und empfiehlt neu den HTTP-Statuscode 304. Hat sich eine Seite seit dem letzten Crawl nicht verändert, spart die Antwort Serverressourcen. Zudem stellt Google klar: Alle Google-Crawler teilen sich dieselbe Kapazität.

Was Google konkret geändert hat

In der Dokumentation "Optimize Your Crawl Budget" sind zwei neue Passagen dazugekommen. Die erste betrifft das Zusammenspiel der verschiedenen Google-Crawler, die zweite ist eine klare Empfehlung zum Umgang mit unveränderten Seiten. Beides klingt technisch, hat aber sehr praktische Auswirkungen auf deinen Server und darauf, wie effizient Google deine Inhalte erfasst.

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. Wenn du eine klassische KMU-Website mit 40 Unterseiten betreibst, musst du nicht in Panik verfallen. Trotzdem lohnt sich das Verständnis, denn die Mechanik dahinter erklärt, warum manche Seiten schnell und andere quälend langsam in den Index kommen.

Alle Crawler teilen sich denselben Topf

Die erste Neuerung räumt mit einem verbreiteten Missverständnis auf. Google beschreibt neu, 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.

Im Klartext: Googlebot, Googlebot-Image, Googlebot-Video und die übrigen Bots bedienen sich am selben Budget. Wenn der Bilder-Crawler sich durch eine riesige Mediathek arbeitet, bleibt weniger Kapazität für den klassischen Googlebot, der deine neuen Landingpages und Blogartikel erfassen soll.

Für dich heisst das: Wenn du beobachtest, dass wichtige Seiten nur zäh gecrawlt werden, lohnt ein Blick in die Server-Logfiles oder in den Crawling-Bericht der Search Console. Vielleicht frisst gar nicht dein Content das Budget, sondern ein aufgeblähtes Bildarchiv, eine Filter-Navigation mit tausenden Parameter-URLs oder ein Video-Verzeichnis, das niemand braucht.

Ein praktischer Nebeneffekt: Wer seine Bilder konsequent komprimiert, alte Mediendateien entfernt und unnötige Varianten gar nicht erst generiert, entlastet damit indirekt auch das Crawling der eigentlichen Inhaltsseiten. Aufräumen wirkt in diesem Bereich oft stärker als jede zusätzliche technische Massnahme.

Der 304-Statuscode und was er wirklich macht

Die zweite Ergänzung ist die spannendere. Google empfiehlt neu ausdrücklich die Unterstützung des Statuscodes 304 (Not Modified). Die Begründung: Hat sich eine Seite seit dem letzten Crawl nicht verändert, signalisiert der 304-Code Google, die bereits zwischengespeicherte Version weiterzuverwenden. Das spart Bandbreite und Serverressourcen.

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 Effekt ist doppelt positiv. Dein Server muss die Seite weder rendern noch ausliefern, und der Googlebot kann seine verbleibende Kapazität für die Seiten einsetzen, die sich tatsächlich verändert haben. Bei einem Shop mit 80'000 Produktseiten, von denen sich pro Tag vielleicht 500 ändern, ist das ein gewaltiger Unterschied.

So funktioniert die Umsetzung

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

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 das bereits kann, findest du in wenigen Sekunden heraus. Ein einfacher curl-Aufruf mit dem Header If-Modified-Since zeigt dir, ob eine 304-Antwort zurückkommt. Alternativ gibt der Crawling-Bericht in der Search Console unter "Nach Antwort" Auskunft darüber, wie viele Anfragen bereits mit 304 beantwortet werden.

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: Deine Seite liefert ein 304 aus, obwohl sich der Inhalt sehr wohl geändert hat. Dann sieht Google deine Aktualisierung schlicht nicht, und dein sorgfältig überarbeiteter Ratgeber bleibt in der alten Fassung im Index.

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 ist kein Ersatz für sauberes technisches SEO. Wenn Google Kapazität in Parameter-URLs, Session-IDs, endlose Kalenderseiten oder Soft-404s investiert, löst ein Caching-Header das Grundproblem nicht. Zuerst räumst du auf, dann optimierst du die Auslieferung.

Was du daraus mitnimmst

Für kleinere Websites ist der 304-Code eine nette Effizienzverbesserung, aber kein Ranking-Hebel. Google crawlt eine gepflegte Website mit ein paar hundert Seiten ohnehin problemlos. 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 entscheidet die Crawl-Effizienz mit darüber, wie schnell neue Angebote sichtbar werden.

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 kurzer Test bringt Klarheit, ob du handeln musst oder ob dein Setup die Empfehlung von Google längst erfüllt.



Quelle: Searchenginejournal.com