Google hat seine Leitfaden zum Crawl-Budget am 22. Juli 2026, und fast jede Seite, auf der derzeit das Crawl-Budget für E-Commerce-Websites erläutert wird, stammt aus der Zeit davor. Die für einen Shop wichtigste Information ist neu: Ihre Crawl-Kapazität ist ein einziger Pool, der von allen Crawlern von Google gemeinsam genutzt wird, sodass das Crawlen Ihrer Feeds, Bilder und Anzeigen mit der Produktsuche konkurriert.
Hier ist meine ehrliche Einschätzung, nachdem ich das neue Dokument vollständig gelesen und auf unserer eigenen Website getestet habe. Die meisten Online-Shops haben überhaupt kein Problem mit dem Crawl-Budget, und diejenigen, bei denen dies der Fall ist, haben in der Regel ein Problem mit doppelten URLs, das sich als Crawl-Budget-Problem tarnt.
Wichtigste Erkenntnisse
- Google hat sein Dokument zum Crawl-Budget am 22. Juli 2026 überarbeitet und gibt nun an, dass alle Crawler gemeinsam eine einzige Crawl-Kapazitätsgrenze nutzen.
- Google Shopping crawlt intensiver, wenn Sie Händler-Feeds haben, und AdsBot crawlt intensiver bei dynamischen Anzeigen, sodass beide aus demselben Pool für die Produktsuche schöpfen.
- Die meisten Websites haben kein Problem mit dem Crawl-Budget; laut Google können Sie dieses Thema getrost außer Acht lassen, wenn Ihre Seiten noch am Tag ihrer Veröffentlichung gecrawlt werden.
- Wenn ein Shop ein solches Problem aufweist, liegt die Ursache in der Regel in der Erzeugung doppelter URLs (Tags, Filter, Sortierparameter, Paginierung) und nicht in einer niedrigen Obergrenze.
- Die Unterstützung von HTTP 304 spart Crawling-Aufwand, aber ob Sie “304 unterstützen”, hängt davon ab, welchen Validator Ihr Server sendet; unser Origin berücksichtigt dies anhand des ETag und nicht anhand von „If-Modified-Since“.
- Sie können kein höheres Crawl-Budget beantragen; Google erhöht das Limit nur, wenn Ihr Server kontinuierlich schnell und einwandfrei reagiert.
Was das Crawl-Budget für einen Online-Shop eigentlich ist
Das Crawl-Budget bezeichnet die Gesamtheit der URLs, die Google auf Ihrer Website crawlen kann und will. Es wird durch zwei Faktoren bestimmt: Ihre Grenzwert für die Crawl-Kapazität (wie viel Crawling Ihr Server verkraften kann) und Googles Crawl-Nachfrage (inwieweit Google Ihre Seiten tatsächlich crawlen möchte).
Stellen Sie sich die Kapazitätsgrenze wie die Tür eines gut besuchten Ladens vor. Sie gibt an, wie viele Personen Google gleichzeitig hereinlässt und wie lange es zwischen den Besuchen wartet – so eingestellt, dass Ihr Server nicht überlastet wird. Diese Zahl steigt nur, wenn Ihr Server weiterhin schnell antwortet, und sinkt, wenn Ihr Server ins Stocken gerät.
Die Crawl-Nachfrage ist die andere Hälfte: Wie sehr Google an Ihren Seiten interessiert ist, hängt davon ab, wie beliebt sie sind und wie oft sie aktualisiert werden. Ein Shop, der täglich Produkte hinzufügt und bearbeitet, erzeugt echte Nachfrage; eine statische Broschüren-Website hingegen nur sehr wenig. Wenn Sie sich für die messbare Seite dieses Themas interessieren, finden Sie in unserem älteren Leitfaden zu Auffinden des Kriechbudgets und seiner Anwendungsfälle führt Schritt für Schritt durch das Auslesen der Zahlen in der Search Console.
Hat Ihr Shop überhaupt ein Problem mit dem Crawl-Budget?
Die meisten Shops tun dies nicht, und Google weist darauf auf derselben Seite hin, die jeder nutzt, um die Optimierung des Crawl-Budgets zu vermarkten. In der überarbeiteten Dokumentation heißt es ganz klar: “Wenn Ihre Seiten offenbar noch am Tag ihrer Veröffentlichung gecrawlt werden, brauchen Sie diesen Leitfaden nicht zu lesen.”
Google stellt den gesamten Leitfaden als fortgeschrittenes Material für drei Arten von Websites dar: große Websites mit einer Million oder mehr URLs, die sich wöchentlich ändern, mittlere oder größere Websites mit 10.000 oder mehr URLs, die sich täglich ändern, sowie Websites, bei denen ein großer Teil der URLs in der Search Console als Entdeckt, derzeit nicht indexiert. Außerdem wird darauf hingewiesen, dass es sich bei diesen Zahlen um “eine grobe Schätzung” und “keine genauen Grenzwerte” handelt; betrachten Sie sie daher eher als Anhaltspunkt und nicht als feste Regel.
| Sie können das Crawl-Budget ignorieren, wenn | Sie sollten darauf achten, wenn |
|---|---|
| Neue Produkte werden noch am selben Tag, an dem Sie sie veröffentlichen, von Suchmaschinen erfasst. | Sie verwalten einen umfangreichen Katalog (etwa 1 Million oder mehr URLs), der sich wöchentlich ändert |
| Ihr Shop ist klein bis mittelgroß (weniger als etwa 10.000 URLs) | Sie haben 10.000 oder mehr URLs, und die Inhalte ändern sich täglich |
| Nur wenige URLs befinden sich im Status “Entdeckt, derzeit nicht indexiert” | Ein großer Teil Ihrer URLs befindet sich im Status “Entdeckt, derzeit nicht indexiert” |
Was sich durch Googles überarbeitetes Dokument zum Crawl-Budget im Juli 2026 geändert hat
Der Großteil der Überarbeitung vom 22. Juli betraf rein redaktionelle Änderungen. Google beschrieb dies als Verbesserung der “Klarheit, terminologischen Konsistenz und des Leseflusses” sowie als Maßnahme, um sicherzustellen, dass ein Begriff wie Grenzwert für die Crawl-Kapazität wird durchgehend auf dieselbe Weise verwendet, was Suchmaschinen-Rundtischgespräch wurde am Morgen seiner Landung markiert.
Einige Zeilen sind jedoch tatsächlich neu, und eine davon ist der Grund, warum dieser Beitrag überhaupt entstanden ist. Das Dokument wurde zudem stillschweigend verschoben: Früher war es unter der Dokumentation zu „Search“ zu finden, jetzt befindet es sich in einem umfassenderen Abschnitt zum Thema Crawling, was gut zu der darin enthaltenen Aussage passt, dass das Budget von den Crawlern für „Search“, „Shopping“ und „Ads“ gemeinsam genutzt wird.
| Neue oder geschärfte Linie | Warum das für ein Geschäft wichtig ist |
|---|---|
| Eine Crawling-Kapazitätsgrenze gilt für alle Crawler gemeinsam | Das Crawling Ihrer Feeds, Bilder und Anzeigen steht im Wettbewerb mit der Produktsuche |
| Google Shopping indexiert Händler-Feeds intensiver; AdsBot indexiert dynamische Anzeigen intensiver | Gibt die genauen Store-Crawler an, die auf den gemeinsamen Pool zugreifen |
| Jede Website beginnt mit derselben standardmäßigen, konservativen Kapazitätsgrenze | Google erhöht die Kapazität nur, wenn Ihr Server nachweist, dass er mehr bewältigen kann. |
| Unterstützung von HTTP 304 (Not Modified), um das erneute Herunterladen unveränderter Seiten zu vermeiden | Das lässt sich auf Ihrer eigenen Origin-Domain testen, und die meisten Shops geben niemals einen 304-Status zurück. |
Warum für alle Crawler von Google ein gemeinsames Crawling-Kapazitätslimit gilt
In Googles überarbeiteter Dokumentation heißt es nun ganz direkt: “Die Crawling-Kapazitätsgrenze gilt für alle Crawler gemeinsam”, und “eine hohe Auslastung durch einen Crawler kann die für andere verfügbare Kapazität verringern.” Das ist nur ein Satz, der jedoch Ihre Herangehensweise beim Crawling eines Online-Shops grundlegend verändert.
Das Dokument nennt anschließend die Crawler, die für einen Online-Shop von Bedeutung sind. Dort heißt es, dass AdsBot “in der Regel eine höhere Auslastung aufweist, wenn eine Website dynamische Anzeigenziele verwendet, und dass Google Shopping eine höhere Auslastung bei Produkten aufweist, die Sie in Ihren Händler-Feeds haben.” Liest man diese beiden Zeilen zusammen, ergibt sich ein klares Bild: Googlebot für die Seitenerkennung, Googlebot-Image für Ihre Produktfotos, Google Shopping für Ihren Feed und AdsBot für Ihre Anzeigen-Landingpages – sie alle greifen auf dasselbe Host-Budget zurück.
Hier beschreibt Google seine eigenen Systeme – das ist zwar die aussagekräftigste Form einer Herstellerangabe, aber dennoch nur eine Herstellerangabe. Daher betrachte ich dies eher als eine Darstellung der Funktionsweise des Crawlings und nicht als feststehende Tatsache. Was wir aus erster Hand belegen können, ist die Aufteilung auf unserer eigenen Website. Selbst wenn kein Merchant-Center-Feed läuft, schlüsselt unsere Search-Console-Crawling-Statistik das Crawling nach Crawler-Typ auf, und allein auf AdsBot entfallen 9% davon, wobei das Abrufen von Bildern und Seitenressourcen einen großen Teil davon ausmacht.
Bei einem Online-Shop liegt der Schwerpunkt dieser Mischung stärker auf dem Crawling von Feeds und Bildern als bei einer Content-Website wie der unseren. Wenn Sie sehen möchten, wie sich einer dieser shopspezifischen Crawler in der Praxis verhält, haben wir dies separat in unserem Beitrag zu Google StoreBot.
Wie ein Shop die Auffindbarkeit seiner eigenen Produkte untergraben kann
Bei einem Shop mit einem umfangreichen Bildkatalog, einem aktiven Händler-Feed und „Shopping“- oder „Performance Max“-Anzeigen kann es vorkommen, dass die Produktseiten nur langsam indexiert werden – und zwar nicht aufgrund von Fehlern bei der On-Page-SEO. Der Grund dafür ist, dass das Crawling des eigenen Feeds, der Bilder und der Anzeigen den gemeinsamen Pool aufbraucht, bevor Googlebot zu den neuen Produkten gelangt.
Unsere eigenen Daten lassen erahnen, warum das so ärgerlich ist. In den Crawl-Statistiken, 90% Ein Teil des Crawlings durch Google auf unserer Website besteht darin, bereits bekannte Seiten neu zu laden, und zwar nur 10% ist die Erkennung – der Teil, der brandneue URLs aufspürt. Bei einem Shop, der täglich neue Produkte veröffentlicht, ist genau dieser kleine Teil der Erkennung das, womit Ihr Feed und Ihr Bild-Crawling konkurrieren.
Wie ein Shop sein gemeinsames Crawl-Budget einsetzt
- Googlebot, Googlebot-Image, Google Shopping und AdsBot greifen alle auf einen gemeinsamen Kapazitätspool zurück
- Das Crawling von großen Bild-, Feed- und Anzeigenmengen beansprucht einen großen Teil dieses Pools
- Googlebot hat weniger Kapazität, um Seiten zu finden und zu aktualisieren
- Neue und aktualisierte Produktseiten werden langsamer gefunden und aktualisiert
Spart die Unterstützung von HTTP 304 tatsächlich Crawl-Budget?
Ja, wenn es tatsächlich funktioniert. In Googles Dokument wurde eine neue Zeile hinzugefügt, in der Websites aufgefordert werden, “HTTP-Statuscodes 304 (Not Modified) zu unterstützen”, da ein 304-Code Google anweist, die bereits vorhandene Kopie wiederzuverwenden, anstatt die Seite erneut herunterzuladen. Aber “304 zu unterstützen” ist nicht einfach nur ein Schalter, den man umlegt; es hängt davon ab, welchen Validator Ihr Server sendet.
Ein 304-Status wird durch bedingte Anfragen ausgelöst. Google speichert den ETag einer Seite (einen Fingerabdruck des Inhalts) oder deren “Last-Modified”-Datum und fragt dann: „Hat sich dies seitdem geändert?“ Wenn sich nichts geändert hat, sollte der Server mit einem 304-Status antworten und keinen Body senden. Genau das haben wir auf unserem eigenen Origin-Server getestet, der über einen LiteSpeed-Seiten-Cache bereitgestellt wird, und das Ergebnis fiel gemischter aus, als die einzeilige Anleitung vermuten lässt.
| Von uns gesendete bedingte Anfrage | Was unser Ursprung zurückgegeben hat |
|---|---|
| „If-None-Match“ mit dem ETag des jeweiligen Blogbeitrags | HTTP 304 Nicht geändert |
| „If-None-Match“ mit dem ETag der Startseite | HTTP 304 Nicht geändert |
| „If-Modified-Since“ mit einem aktuellen Datum | HTTP 200, wieder die gesamte Seite |
Wir “unterstützen also 304” anhand des ETag und nicht anhand von If-Modified-Since, und zwar einzig und allein deshalb, weil unsere Seiten einen ETag-Header, aber keinen Last-Modified-Header enthalten. Da es für eine If-Modified-Since-Anfrage nichts gibt, womit sie den Vergleich anstellen könnte, gibt der Server die gesamte Seite zurück. Unsere Crawl-Statistiken bestätigen dies: „Nicht modifiziert (304)“ fällt unter 1% aller Crawl-Antworten auf unserer Website, was bedeutet, dass Google fast alles erneut herunterlädt, auch wenn sich nichts geändert hat.
Die wichtigste Erkenntnis für einen Online-Shop lautet: Testen Sie es lieber selbst, anstatt einfach von etwas auszugehen. Senden Sie die beiden bedingten Anfragen an eine Produktseite und prüfen Sie, welche Ihre Plattform berücksichtigt, denn ein bild- oder feedlastiger Shop, der niemals einen 304-Status zurückgibt, verschwendet Kapazitäten durch das erneute Abrufen von Bytes, die sich nicht geändert haben. Dies ist dieselbe Überprüfung auf Header-Ebene, die wir in unserem Leitfaden zu So überprüfen Sie, ob Ihr CDN Daten zwischenspeichert.
Das eigentliche Problem für die meisten Shops ist die Erstellung doppelter URLs
Bei den meisten Websites, die tatsächlich nur langsam indiziert werden, liegt das Problem nicht in einer niedrigen Deckenhöhe, sondern in zu vielen URLs mit geringem Wert. In dem Dokument von Google wird dies als “wahrgenommener Bestand” bezeichnet und als “der Faktor, den Sie am stärksten positiv beeinflussen können” beschrieben – was eine höfliche Art ist, zu sagen, dass Sie in der Regel selbst für diesen Ballast verantwortlich sind.
In einem Online-Shop tauchen diese URLs auf, ohne dass sie von jemandem erstellt wurden. Jedes Tag einer Kollektion erhält eine eigene URL, jeder Filter im Shop fügt eine hinzu, jede Sortierreihenfolge eine weitere, und jede dieser Sortierungen wird paginiert. Google verbraucht dann seine Crawling-Ressourcen für nahezu identische Seiten, anstatt für Ihre tatsächlichen Produkte. Wir haben diesen Mechanismus für eine Plattform in unserem Artikel über […] ausführlich analysiert. Shopify: Doppelte Inhalte aus Kollektionen, und die Darstellung ist bei WooCommerce identisch.
So betrachtet ist das Crawl-Budget das Symptom und die Erstellung doppelter URLs die Ursache. Behebt man die URL-Explosion, löst sich das “Budgetproblem” in der Regel von selbst auf. Deshalb würde ich mich zuerst damit befassen, lange bevor ich mir Gedanken über die Kapazitätsgrenze mache.
So verwalten Sie das Crawl-Budget in einem Online-Shop
Die Möglichkeiten, die Ihnen das Google-Dokument tatsächlich bietet, sind begrenzt: Entfernen Sie doppelte und unbrauchbare URLs, sorgen Sie dafür, dass der Server schnell und einwandfrei läuft, und lenken Sie das Crawling auf das Wesentliche. Es gibt keinen Knopf, um mehr Budget zu beantragen – ignorieren Sie also jeden, der so tut, als gäbe es einen.
- Doppelte Inhalte zusammenführen Google konzentriert sich also, wie das Unternehmen selbst sagt, beim Crawling “auf einzigartige Inhalte statt auf einzigartige URLs”. Canonical-Tags, eine übersichtliche facettierte Navigation sowie der Verzicht auf die Indizierung von Filter- und Sortier-URLs leisten hier den größten Beitrag.
- Geben Sie für Produkte, die Sie dauerhaft entfernt haben, einen 404- oder 410-Fehlercode zurück., denn Google bezeichnet einen 404-Fehler als “ein deutliches Signal, diese URL nicht erneut zu crawlen”, sodass keine Abrufe mehr für nicht mehr verfügbare Artikel verschwendet werden.
- Vermeiden Sie lange Weiterleitungsketten, die laut Google “sich negativ auf das Crawling auswirken”; ein migrierter Shop voller Weiterleitungen mit Umwegen belastet das Crawling bei jeder einzelnen. Unser Leitfaden zu Erkennen und Auflösen von Weiterleitungsketten übernimmt die Aufräumarbeiten.
- Sorgen Sie dafür, dass der Server schnell und stabil läuft, denn der Crawl-Status ist der einzige Faktor, der Ihr Limit erhöht; konstante Antwortzeiten und die Zeit bis zum ersten Byte erhöhen es, während 5xx-Fehler und 429-Rate-Limit-Antworten es senken.
- Verlassen Sie sich nicht auf die robots.txt, um “Budget freizusetzen”. Google betont ausdrücklich, dass es “dieses neu verfügbare Crawl-Budget nicht auf andere Seiten verlagern wird, es sei denn, Google stößt bereits an die Crawl-Kapazitätsgrenze Ihrer Website”, sodass das Blockieren von unerwünschten URLs dazu beiträgt, den Fokus zu schärfen, und nicht, Spielraum zu schaffen.
- Verwenden Sie „noindex“ nicht, um das Crawlen zu vermeiden Auch das nicht; Google ruft die Seite zwar weiterhin ab, bricht den Vorgang aber ab, sobald es das Tag erkennt – du hast den Abruf also bereits verbraucht.
All dies können Sie dort einsehen, wo die tatsächlichen Zahlen zu finden sind: in den Crawling-Statistiken der Search Console und in Ihren Server-Logs. Auf unserer eigenen Website wird der Host-Status als „intakt“ angezeigt, mit einem 460 ms durchschnittliche Antwortzeit und keine Host-Probleme – das ist der Zustand, bei dem der Grenzwert eher steigt als sinkt.
Wenn Sie über die Zusammenfassung hinausgehen möchten, zeigen Ihre Server-Rohprotokolle genau, welcher Crawler wann welche URL aufgerufen hat. Wie man diese Protokolle auswertet – einschließlich der Unterscheidung zwischen den verschiedenen Crawler-Typen – haben wir in unserem Leitfaden zu Analyse von Protokolldateien für KI- und Such-Crawler.
Sollte sich Ihr Shop also Gedanken über das Crawl-Budget machen?
Ehrlich gesagt lautet die Antwort für die meisten Shops “Nein”, und das überarbeitete Dokument bestätigt dies stillschweigend. Wenn Ihre Produkte bereits am Tag ihrer Veröffentlichung gecrawlt werden und die Search Console nicht voller URLs mit dem Status „Entdeckt, derzeit nicht indexiert“ ist, sollten Sie Ihre Zeit lieber für Inhalte und Links nutzen, anstatt einer Crawling-Obergrenze hinterherzujagen, die Sie ohnehin nicht erreichen.
Die Händler, die sich darüber Gedanken machen sollten, sind die großen, schnelllebigen Versandhändler, und für sie ist die eigentliche Neuigkeit vom Juli 2026 der gemeinsame Pool: Euer Feed, eure Bilder und Anzeigen stehen nun in offensichtlicher Konkurrenz zur Produktsuche. Ein überladener URL-Satz oder ein schwerfälliger Feed ist also kein separates Problem neben “Google findet meine Produkte nur langsam”, sondern die Ursache dafür. Mein Rat ist absichtlich langweilig. Prüfen Sie zunächst, ob Sie das Problem überhaupt haben, und beheben Sie dann doppelte URLs und Serverprobleme, bevor Sie sich an ausgeklügelte Maßnahmen wagen – denn genau dafür ist das eigentliche Budget vorgesehen.
Häufige Fragen zum Crawl-Budget für Shops
Wie kann ich das Crawl-Budget meines Shops überprüfen?
Öffnen Sie die Search Console, gehen Sie zu „Einstellungen“ und dann zu „Crawl-Statistiken“. Dort werden die Gesamtzahl der Crawl-Anfragen, die durchschnittliche Antwortzeit, der Host-Status sowie eine Aufschlüsselung nach Googlebot-Typ angezeigt – dies kommt einer Echtzeit-Übersicht darüber, wie Ihr Budget verwendet wird, am nächsten, die Google Ihnen bietet.
Wird durch das Blockieren von Filter-URLs in der robots.txt-Datei Crawl-Budget für meine Produkte freigesetzt?
Nicht von selbst. Google gibt an, dass es die frei gewordenen Crawling-Kapazitäten nicht auf andere Seiten umverteilt, es sei denn, Sie haben bereits Ihre Kapazitätsgrenze erreicht. Das Blockieren von unerwünschten URLs hilft Google zwar dabei, sich auf die richtigen Seiten zu konzentrieren, verschafft Ihnen jedoch keinen zusätzlichen Spielraum.
Wie hoch ist die maximale Crawl-Kapazität?
Dies ist die maximale Anzahl an gleichzeitigen Crawling-Vorgängen, die Google auf Ihrer Website durchführt, zuzüglich der Verzögerung zwischen den einzelnen Abrufen, die so festgelegt ist, dass Ihr Server nicht überlastet wird. Jede Website beginnt mit derselben konservativen Standardeinstellung, und Google erhöht diese erst, wenn Ihr Server nachweist, dass er mehr bewältigen kann.
Zusammenarbeit mit WpConsults
Sind Sie sich nicht sicher, ob Ihr Shop ein Problem mit dem Crawl-Budget hat?
Falls Ihre Produktseiten nur langsam gefunden werden oder ein großer Teil davon unter “Entdeckt, derzeit nicht indexiert” aufgeführt ist, kann ich Ihre Crawl-Statistiken und Protokolle auswerten und Ihnen sagen, ob es sich tatsächlich um ein Crawl-Budget-Problem handelt oder um ein verstecktes Problem mit doppelten URLs.
Änderungsprotokolle
23. Juli 2026
- Erstveröffentlichung, basierend auf Googles Überarbeitung des Crawl-Budgets vom 22. Juli 2026, ergänzt durch unsere eigenen Crawl-Statistiken und einen HTTP-304-Test aus erster Hand auf unserem Origin-Server.
Möchtest du, dass unsere Beiträge öfter bei Google erscheinen?
Ein Schritt – und Google zeigt diese Seite in Ihren „Top Stories“ an.
