Google aktualisiert Crawl-Budget-Anforderungen: 304, Limits

Google hat die offizielle Dokumentation zum Crawl Budget aktualisiert: Sie enthält jetzt eine direkte Empfehlung, Googlebot für unveränderte Seiten den Code 304 (Not Modified) zurückzugeben, und erklärt erstmals ausdrücklich, dass das Crawling-Limit für alle Google-Crawler gemeinsam gilt. Das ist kein neuer Algorithmus und kein einmaliges Ereignis, sondern eine Präzisierung der Regeln, nach denen das technische SEO ohnehin schon lange lebt, nur ist sie jetzt offiziell festgehalten und nicht mehr nur etablierte Branchenpraxis.

Was ist passiert

Am 22. und 23. Juli 2026 hat Google den Abschnitt „Optimize your crawl budget“ in der Search-Central-Dokumentation (Teil des Bereichs Crawling infrastructure) aktualisiert. Die Dokumentation beschreibt drei Präzisierungen.

Erstens startet jede Website mit demselben konservativen Crawl-Capacity-Limit. Google schreibt ausdrücklich: Besteht Bedarf, mehr zu crawlen, und antwortet die Website stabil und schnell auf Anfragen, hebt das System dieses Limit im Laufe der Zeit automatisch an. Das Limit ist also nicht dauerhaft fixiert, es wird durch zuverlässigen Serverbetrieb „erarbeitet“.

Zweitens gilt dieses Limit gleichzeitig für alle Google-Crawler gemeinsam. Jeder Crawler (der gewöhnliche Googlebot, Googlebot-Image, AdsBot und andere) hat seinen eigenen Crawling-Bedarf, aber die Kapazitätsobergrenze gilt für die gesamte Website. Belastet ein Crawler den Server stark, bleibt für die anderen weniger Ressource übrig.

Drittens ist in der Dokumentation eine direkte Empfehlung erschienen: den HTTP-Code 304 (Not Modified) zu unterstützen. Hat sich eine Seite seit dem letzten Crawling nicht verändert, kann der Server statt des vollständigen Inhalts 304 zurückgeben. Google nutzt dann die bereits zwischengespeicherte Version erneut, und der Server spart Traffic und Ressourcen. Der praktische Effekt: Googlebot verwendet das freigewordene Crawl Budget für Seiten, die sich tatsächlich geändert haben, statt für das erneute Laden von Inhalten, die ohnehin unverändert sind.

Diese Empfehlungen gelten nicht ausnahmslos für alle Websites. Google nennt die Zielgruppe ausdrücklich: große Websites mit über einer Million Seiten sowie mittelgroße Websites mit über 10.000 Seiten, die häufig aktualisiert werden.

Warum das wichtig ist

Für Websites, die unter diese Schwellenwerte fallen, Marktplätze, große Kataloge, Nachrichtenportale, wirkt sich das Crawl Budget direkt darauf aus, wie schnell neue oder aktualisierte Seiten überhaupt in die Suchergebnisse gelangen. Verwendet Googlebot Ressourcen auf das wiederholte Crawlen tausender unveränderter Produktseiten statt neuer Angebote oder aktualisierter Preise, verzögert sich die Indexierung neuer Inhalte unbemerkt, ohne jede Fehlermeldung oder Warnung in der Search Console.

Bislang war 304-Caching eine allgemein bekannte Praxis der Web-Performance, die eher unter dem Aspekt der Ladegeschwindigkeit als der SEO empfohlen wurde. Jetzt ist es eine offizielle Empfehlung genau im Kontext des Crawl Budgets, ein Argument, das sich dem Entwicklungsteam leichter vorlegen lässt, wenn man die Priorität einer technischen Aufgabe begründen muss, die in einem einzelnen Sprint kein sichtbares Ergebnis liefert.

So funktioniert es

Vorher	Jetzt	Was zu tun ist
Das Crawl-Capacity-Limit wurde allgemein beschrieben, ohne Details zur gemeinsamen Nutzung durch die Crawler	Das Limit wird jetzt ausdrücklich als gemeinsam für alle Google-Crawler beschrieben	In Search Console → Crawling-Statistiken prüfen, welche Crawler-Typen welchen Anteil des Limits nutzen
304-Caching war eine allgemeine Empfehlung zur Web-Performance	Direkte Google-Empfehlung speziell zur Schonung des Crawl Budgets	Über die Server-Antwort-Header prüfen (curl -I mit If-Modified-Since), ob der Server 304 überhaupt unterstützt
Es war unklar, warum neue große Websites langsamer gecrawlt wurden als erwartet	Erklärt: Jede Website startet mit einem konservativen Limit, das bei stabilem Serverbetrieb im Laufe der Zeit wächst	Das Limit nicht künstlich forcieren: auf die Stabilität der Server-Antworten achten, statt zu versuchen, den konservativen Start zu „umgehen“

Technisch geht nichts kaputt und wird nichts automatisch abgeschaltet, das ist kein erzwungener Übergang wie bei manchen anderen Google-Updates. Es handelt sich um eine Dokumentation, die formalisiert, was ein Teil der technischen SEO-Fachleute ohnehin schon umgesetzt hat, und die einen klareren Orientierungspunkt gibt, wo genau man ansetzen sollte, wenn eine große Website langsamer gecrawlt wird, als gewünscht.

Für wen das relevant ist

Den direkten Schwellenwert für die Anwendbarkeit hat Google selbst genannt: Websites mit über einer Million Seiten und mittelgroße Websites mit über 10.000 Seiten, die sich häufig ändern. Das sind Marktplätze, große E-Commerce-Kataloge, Kleinanzeigenportale, Nachrichtenportale und Aggregatoren.

Für eine typische Business-Website mit einigen Dutzend oder Hundert Seiten, ein Landingpage-Auftritt, eine Dienstleistungswebsite, ein kleiner Online-Shop, ändert dieses Update praktisch nichts: Bei einem solchen Umfang schafft Google auch ohne besondere Maßnahmen problemlos, die gesamte Website zu crawlen, mit deutlichem Puffer. Entwicklungsressourcen für 304-Caching wegen des Crawl Budgets aufzuwenden, ergibt hier keinen Sinn, prioritärer bleiben die Grundlagen: Ladegeschwindigkeit, korrekte Indexierung, keine Duplikate.

Eine eigene Kategorie sind wachsende Websites: Umfasst der Katalog derzeit einige Tausend Produkte und ist in einem halben Jahr der Sprung über 10.000 geplant, lohnt es sich, die Unterstützung von 304 bereits vorab in die Architektur einzuplanen, statt sie im Nachhinein umzubauen.

Redaktionelle Einordnung

Wir haben noch keine gesonderte Messung durchgeführt, wie stark sich die Reindexierungsgeschwindigkeit nach der Einführung von 304 konkret infolge dieses Dokumentations-Updates verbessert. Es ist zu frisch, um Statistiken aus Kundenkonten zu sammeln. Die Prüfung des Server-Antwortcodes selbst ist jedoch bereits ein Standardpunkt des technischen SEO-Audits, das wir für jede Website mit großem Katalog durchführen, weit vor dieser Präzisierung durch Google. Diese Neuigkeit ändert unsere Arbeitsmethodik nicht, sie liefert die offizielle Bestätigung, dass die eingeschlagene Richtung stimmt, und ein Argument, das sich einem Kunden oder dem Entwicklungsteam leichter vorlegen lässt.

Praxisbeispiel

Stellen wir uns einen Katalog mit 40.000 Produktseiten vor, von denen tatsächlich (Preis, Verfügbarkeit, Beschreibung) etwa 5 % pro Woche aktualisiert werden. Gibt der Server für jede Seite unabhängig davon, ob sie sich geändert hat, den Code 200 mit vollständigem Inhalt zurück, verwendet Googlebot dieselbe Ressourcenmenge sowohl für die 2.000 tatsächlich aktualisierten Seiten als auch für die 38.000 unveränderten. Gibt der Server dagegen korrekt 304 für diese 38.000 unveränderten Seiten zurück, lenkt der Crawler die freigewordene Ressource auf ein schnelleres erneutes Crawlen genau der 2.000 geänderten Seiten, und der aktualisierte Preis oder Verfügbarkeitsstatus erscheint schneller in den Suchergebnissen.

Was Sie jetzt schon tun sollten

• Größe und Aktualisierungstempo des Katalogs prüfen: Fällt die Website unter die Schwellenwerte von Google (1 Mio.+ Seiten oder 10.000+ häufig sich ändernde Seiten).
• Falls ja: gemeinsam mit dem Entwickler prüfen, ob der Server für unveränderte Seiten überhaupt 304 zurückgibt oder immer den vollständigen Code 200 liefert.
• In Search Console → Crawling-Statistiken die Verteilung der Antwortcodes und Crawler-Typen ansehen.
• Bei aktiv wachsenden Websites die Unterstützung von 304 frühzeitig in die technische Spezifikation aufnehmen, nicht erst, nachdem der Seitenumfang bereits ein Problem verursacht.
• Bei kleinen Websites das nicht als Erstes angehen: zuerst die Grundlagen prüfen: Ladegeschwindigkeit, doppelte Seiten, Korrektheit von robots.txt und Sitemap.

Experten-Tipp. Bevor Sie 304 flächendeckend einführen, testen Sie es stichprobenartig an unkritischen Seiten, archivierten Produkten, alten Nachrichten, Servicseiten. So stellen Sie sicher, dass das Caching korrekt konfiguriert ist, bevor Sie es auf den gesamten Katalog ausweiten.

Worauf Sie achten sollten. 304 funktioniert nur, wenn der Server präzise feststellt, dass sich eine Seite nicht geändert hat. Ist die Caching-Schicht (CDN, Proxy) falsch konfiguriert und gibt selbst für eine Seite mit aktualisiertem Preis oder aktualisierter Beschreibung 304 zurück, sieht Google die Änderung schlicht nicht, die Reindexierung des tatsächlichen Updates verzögert sich. Prüfen Sie die Logik, die bestimmt, dass „sich eine Seite nicht geändert hat“, getrennt von der reinen Tatsache, dass der Code 304 technisch zurückgegeben wird.

FAQ

Was ist Crawl Budget? Das ist der Umfang an Ressourcen, den Google bereit ist, für das Crawling einer bestimmten Website in einem bestimmten Zeitraum aufzuwenden: wie viele Seiten und wie oft Googlebot sie besuchen kann, unter Berücksichtigung des Crawling-Bedarfs und der Serverkapazität.

Muss man wegen dieses Updates dringend etwas an der Website ändern? Nein, für die meisten Websites nicht. Die Empfehlung betrifft ausdrücklich große Kataloge und Websites mit über 10.000 häufig aktualisierten Seiten; für eine typische Business-Website mit Dutzenden oder Hunderten Seiten ist Crawl Budget in der Regel kein Engpass.

Was ist der Code 304 Not Modified und wie unterscheidet er sich von 200? Der Code 200 bedeutet, dass der Server den vollständigen Seiteninhalt zurückgegeben hat. Der Code 304 bedeutet, dass sich die Seite seit der letzten Anfrage nicht geändert hat und der Client (in diesem Fall Googlebot) die bereits vorhandene zwischengespeicherte Version nutzen kann, ohne den Inhalt erneut zu laden.

Beeinflusst dieses Update die Rankings der Website direkt? Nein, das ist kein Rankingfaktor. Der Effekt ist indirekt: Der korrekte Umgang mit 304 und Crawl Budget beschleunigt, wie schnell Google Änderungen auf der Website bemerkt und reindexiert, beeinflusst aber nicht die Position der Seite selbst.

Wie prüft man, ob der eigene Server 304 unterstützt? Man kann eine Anfrage mit dem Header If-Modified-Since oder If-None-Match an eine konkrete Seite senden (etwa über curl -I) und den Antwortcode prüfen. Hat sich die Seite seit dem angegebenen Datum nicht geändert und gibt der Server trotzdem 200 mit vollständigem Inhalt zurück, gibt es keine Unterstützung für 304.

Betrifft das auch Google Merchant Center und Produkt-Feeds separat? Die Dokumentation bezieht sich auf das Crawling von Website-Seiten durch Googlebot, nicht auf den Produkt-Feed von Merchant Center, das sind unterschiedliche Mechanismen zur Datenaktualisierung. Die direkte 304-Empfehlung betrifft ausdrücklich die HTML-Seiten der Website.

Wo lassen sich in Search Console die aktuellen Crawling-Statistiken einsehen? Im Bereich „Einstellungen → Crawling-Statistiken“ (Crawl Stats) für die jeweilige Property: Dort sieht man die Verteilung nach Antwortcodes, Dateitypen und Google-Crawlern der letzten 90 Tage.

Fazit

Dieses Dokumentations-Update ändert die Spielregeln für die meisten Websites nicht, es formalisiert, was technische SEO-Fachleute großer Projekte ohnehin aus der Praxis wussten, und liefert einen klareren Orientierungspunkt für alle, die mit großen Katalogen oder wachsenden Websites arbeiten. Die zentrale praktische Erkenntnis ist einfach: Ist eine Website groß und wird sie häufig aktualisiert, prüfen Sie, ob der Server für unveränderten Content korrekt 304 zurückgibt, und ob er das nicht fälschlicherweise auch für geänderten Content tut.

Wenn Sie prüfen möchten, ob Crawl Budget für Ihre Website überhaupt ein Engpass ist, und was zuerst behoben werden sollte: Besprechen wir es bei einem technischen Audit. Solche Prüfungen sind Teil unserer SEO-Betreuung, und wenn die Website noch im Aufbau oder in der Überarbeitung ist, lassen sich die Unterstützung von 304 und andere technische Anforderungen direkt in der Phase der Entwicklung einplanen.