Wer sich mit Technischer SEO beschäftigt, kommt früher oder später an einen Punkt, an dem einzelne URLs nicht mehr das eigentliche Problem sind. Das Problem ist dann die Masse an URLs.
Ein großer Onlineshop kann einige Hunderttausend relevante Produkt- und Kategorieseiten besitzen und gleichzeitig Millionen weiterer URLs erzeugen. Filter, Sortierungen, Parameter, nicht mehr verfügbare Produkte oder technisch unterschiedliche Varianten derselben Inhalte sorgen dafür, dass Googlebot weit mehr URLs entdecken kann, als für die organische Suche eigentlich notwendig wären.
Genau hier beginnt die Diskussion über das Crawl-Budget.
Der Begriff wird im SEO gern so verwendet, als würde Google jeder Website morgens einen festen Vorrat an Crawls zuweisen, der anschließend möglichst effizient aufgebraucht werden müsse. Tatsächlich ist das Modell etwas komplexer. Google beschreibt das Crawl-Budget als Zusammenspiel aus der Kapazität, mit der eine Website gecrawlt werden kann, und dem Bedarf, den Google für das Crawling dieser Website sieht. Vereinfacht gesagt geht es darum, wie viele URLs Googlebot crawlen kann und möchte. Google beschreibt diese beiden Faktoren als „Crawling-Kapazitätslimit (crawl capacity limit)“ und „Crawling-Bedarf (crawl demand)“.
Für die meisten kleinen und mittelgroßen Websites ist das überhaupt kein Thema, über das man sich viele Gedanken machen müsste. Interessant wird es bei großen Websites, bei ständig aktualisierten Inhalten oder dort, wo technisch ein riesiges URL-Inventar entsteht.
Und genau dort lohnt sich eine andere Sichtweise auf das Thema Crawl-Budget.
Die entscheidende Frage lautet nicht unbedingt:
Wie bringe ich Google dazu, mehr zu crawlen?
Sondern vielmehr:
Warum biete ich Google überhaupt so viele URLs zum Crawlen an?
Wenn 500.000 Seiten plötzlich 12 Millionen Requests erzeugen
Nehmen wir einen größeren Mode-Shop. Für Nutzer und Suchmaschinen existieren 500.000 relevante Produkt- und Kategorieseiten. Bei einer Analyse der Server-Logs stelle ich jedoch fest, dass Googlebot innerhalb eines Monats zwölf Millionen Requests erzeugt hat.
Davon entfallen 4,5 Millionen auf Filter-URLs, weitere zwei Millionen auf Sortierparameter und eine Million auf Produkte, die längst nicht mehr verfügbar sind. Nur 4,5 Millionen Requests betreffen die eigentlich aktuellen Produkt- und Kategorieseiten.
Schon diese Verteilung erzählt eine Geschichte.
Sie bedeutet nicht automatisch, dass Google die wichtigen Seiten nicht ausreichend crawlt. Aber sie zeigt sehr deutlich, dass ein erheblicher Teil der Crawling-Aktivität auf URLs entfällt, deren Wert zumindest hinterfragt werden sollte.
Google selbst bezeichnet das wahrgenommene URL-Inventar einer Website als einen der Bereiche, auf die Websitebetreiber besonders großen Einfluss haben. Wenn Google sehr viele doppelte, entfernte oder unwichtige URLs kennt, kann erhebliche Crawling-Zeit auf genau diese Adressen entfallen. In seiner aktuellen Dokumentation zum Crawl-Budget nennt Google ein unnötig großes URL-Inventar ausdrücklich als wichtigen Ansatzpunkt zur Verbesserung der Crawling-Effizienz.
Damit wird Crawl-Budget weniger zu einer Frage darüber, wie viel Google crawlt, sondern zunehmend zu einer Frage darüber, was Google crawlt.
Nicht mehr verfügbare Produkte: 404 oder 410?
Ein offensichtlicher Ansatzpunkt sind URLs von Produkten, die dauerhaft nicht mehr verfügbar sind.
Wenn ein Produkt nicht nur vorübergehend ausverkauft ist, sondern endgültig aus dem Sortiment verschwunden ist und keine wirklich passende Ersatzseite existiert, sollte die URL auch technisch klar kommunizieren, dass dieser Inhalt nicht mehr vorhanden ist und auch nicht wiederkehren wird.
Dafür kommen insbesondere die HTTP-Statuscodes 404 Not Found und 410 Gone infrage.
Ein 404 bedeutet vereinfacht, dass die angeforderte Ressource nicht gefunden wurde. Ein 410 signalisiert noch ausdrücklicher, dass die Ressource absichtlich entfernt wurde und nicht wiederkommen wird.
Für Google sind beide Statuscodes geeignete Signale, wenn eine Seite dauerhaft nicht mehr existiert. Google empfiehlt ausdrücklich, für entfernte Inhalte ohne geeigneten Ersatz entweder einen 404 oder einen 410 zurückzugeben. Beide Statuscodes zeigen Google, dass die URL nicht mehr indexiert werden soll.
Wichtig ist dabei weniger die Diskussion darüber, ob 410 grundsätzlich „besser“ als 404 ist. Viel wichtiger ist, dass tatsächlich ein korrekter Fehlerstatus zurückgegeben wird.
Problematisch wird es beispielsweise, wenn die alte Produktseite weiterhin einen HTTP-Status 200 OK ausliefert und lediglich den Hinweis „Produkt nicht verfügbar“ zeigt. Google kann eine solche Seite als Soft-404 interpretieren. Solche URLs können weiterhin gecrawlt werden und unnötig Ressourcen beanspruchen. Google nennt Soft-404s deshalb ausdrücklich als einen Bereich, den Betreiber großer Websites bereinigen sollten. Auch dauerhaft entfernte URLs sollten aus internen Links und XML-Sitemaps verschwinden.
Natürlich gilt das nicht für jedes ausverkaufte Produkt. Wenn ein Artikel nur vorübergehend nicht verfügbar ist oder regelmäßig zurückkehrt, wäre es unsinnig, die URL zu entfernen. Und wenn es einen echten Nachfolger gibt, kann ein sauberer Redirect die bessere Lösung sein.
Die technische Maßnahme muss deshalb immer der tatsächlichen Situation folgen.
Sortierparameter haben selten einen eigenen Suchwert
Noch eindeutiger wird die Situation häufig bei Sortierparametern.
Ein Nutzer möchte Produkte vielleicht nach Preis, Bewertung oder Neuheit sortieren. Daraus können URLs entstehen wie:
/schuhe?sort=preis
/schuhe?sort=bewertung
/schuhe?sort=neueste
Aus Nutzersicht sind diese Zustände sinnvoll. Aus Sicht der organischen Suche enthalten sie aber häufig exakt dieselben Produkte wie die ursprüngliche Kategorie – lediglich in anderer Reihenfolge.
Die Suchintention verändert sich dadurch nicht.
Ich benötige normalerweise keine eigene Landingpage für „Schuhe nach Preis aufsteigend sortiert“.
Wenn solche URLs massenhaft gecrawlt werden, entsteht deshalb ein vergleichsweise klarer Fall für Crawl-Steuerung. Google nennt unterschiedlich sortierte Versionen derselben Seite sogar ausdrücklich als Beispiel für URLs, deren Crawling über die robots.txt blockiert werden kann. Google empfiehlt bei solchen dauerhaft unwichtigen Varianten eine Blockierung des Crawlings statt eines noindex.
Der Unterschied ist wichtig.
Wenn ich einer URL ein noindex mitgebe, muss Googlebot sie zunächst abrufen, um dieses Signal überhaupt lesen zu können. Möchte ich dagegen dauerhaft verhindern, dass Google Zeit mit einer reinen Sortiervariante verbringt, kann eine gezielte Regel in der robots.txt wesentlich konsequenter sein.
Die robots.txt ist dabei allerdings kein Instrument zur Deindexierung.
Google weist ausdrücklich darauf hin, dass eine robots.txt-Datei primär den Zugriff von Crawlern steuert. Soll eine bereits bekannte Seite zuverlässig aus dem Index entfernt werden, ist robots.txt allein nicht die richtige Maßnahme. Google trennt deshalb ausdrücklich zwischen Crawling-Steuerung und Indexierungssteuerung.
Genau diese Unterscheidung zieht sich durch fast alle Entscheidungen im Crawl-Management.
Bei Filter-URLs wird es komplizierter
Bei Filter-URLs würde ich dagegen deutlich vorsichtiger vorgehen.
Stellen wir fest, dass Googlebot innerhalb eines Monats 4,5 Millionen Requests auf URLs der Facettensuche erzeugt hat, ist die Versuchung groß, diese URLs pauschal als wertlos einzustufen.
Doch die Zahl selbst sagt zunächst nichts darüber aus, ob eine Filterkombination für die organische Suche wertvoll ist.
Sie sagt lediglich, dass Google diese URLs entdeckt und crawlt.
Das ist ein wichtiger Unterschied.
Wenn eine Website etwa eine Filterseite für
/schuhe?marke=nike
erzeugt, könnte dahinter durchaus eine relevante Suchintention stehen. Menschen suchen nach „Nike Schuhe“. Vielleicht wäre es deshalb sinnvoll, diesen Zustand nicht einfach wegzublocken, sondern daraus eine bewusst gepflegte Landingpage wie
/schuhe/nike/
zu entwickeln.
Genau darüber ging es bereits bei der Frage der Facettensuche: Einige Facetten sind lediglich Funktionen der Benutzeroberfläche. Andere bilden reale Suchbedürfnisse ab und können deshalb eine eigene Rolle innerhalb der Informationsarchitektur verdienen.
Google bezeichnet die Facettensuche inzwischen ausdrücklich als eine der häufigsten Ursachen für übermäßiges Crawling. Jede zusätzliche Filterkombination kann eine neue URL erzeugen. Dadurch kann ein nahezu unbegrenzter URL-Raum entstehen, den Googlebot theoretisch erkunden könnte. Google empfiehlt deshalb, klar zu entscheiden, ob solche URLs überhaupt gecrawlt werden sollen.
Die richtige Reaktion lautet deshalb nicht: „Alle Filter blockieren.“
Sie lautet vielmehr: Filter klassifizieren.
Welche Kombinationen besitzen eine eigene Suchnachfrage und Suchintention? Welche könnten zu stabilen SEO-Landingpages werden? Welche dienen ausschließlich der Nutzerführung? Und welche erzeugen lediglich unnötige Kombinationen ohne eigenständigen Wert?
Erst wenn diese Fragen beantwortet sind, sollte die technische Steuerung folgen.
Crawl-Budget ist auch Informationsarchitektur
An diesem Punkt wird deutlich, dass Crawl-Budget kein isoliertes Thema der Technischen SEO ist.
Es hängt unmittelbar mit der Informationsarchitektur zusammen.
Wenn jede beliebige Kombination aus Marke, Farbe, Größe, Preis, Verfügbarkeit und Sortierung über normale HTML-Links erreichbar ist, sagt die Website selbst zu Google:
Hier gibt es sehr viele URLs, die du entdecken kannst.
Googlebot folgt diesen Pfaden und versucht zunächst, herauszufinden, was sich dahinter befindet. Erst nach dem Abruf kann Google in vielen Fällen erkennen, dass mehrere URLs denselben oder sehr ähnlichen Inhalt darstellen.
Das bedeutet: Eine Website kann ihr eigenes Crawl-Problem erzeugen.
Deshalb ist die interne Verlinkung ein zentraler Bestandteil der Crawl-Steuerung. Wichtige Kategorien und Landingpages sollten klar erreichbar sein. Belanglose technische Zustände müssen dagegen nicht dieselbe strukturelle Bedeutung erhalten.
Genau deshalb ist es gefährlich, Crawl-Budget ausschließlich über die robots.txt lösen zu wollen.
Die robots.txt kann ein wichtiges Werkzeug sein. Aber sie korrigiert im Zweifel nur ein Problem, das bereits vorher in der Websitearchitektur entstanden ist.
Eine saubere Architektur fragt zuerst:
- Welche URLs möchte ich überhaupt erzeugen?
- Welche davon möchte ich intern verlinken?
- Welche sollen Google als eigenständige Ziele angeboten werden?
- Und welche existieren lediglich, weil ein Nutzer gerade einen bestimmten Zustand innerhalb einer Oberfläche erzeugt hat?
XML-Sitemaps sind ebenfalls Teil dieser Kommunikation
Auch XML-Sitemaps spielen dabei eine wichtige Rolle.
Eine Sitemap sollte Google nicht einfach jede technisch erreichbare URL einer Website präsentieren. Sie sollte vielmehr diejenigen URLs enthalten, die ich tatsächlich als relevante, kanonische Inhalte verstanden wissen und auch im Index sehen möchte.
Google empfiehlt für große Websites ausdrücklich, Sitemaps aktuell zu halten und insbesondere die Inhalte aufzunehmen, die tatsächlich gecrawlt werden sollen. Bei häufig aktualisierten Inhalten kann zusätzlich das lastmod-Datum helfen, relevante Änderungen zu kommunizieren. Google nennt aktuelle Sitemaps deshalb als einen Baustein für effizientes Crawling.
Wenn ich eine URL gleichzeitig aus der internen Architektur herausnehmen möchte, sie aber weiterhin täglich in meiner XML-Sitemap aufführe, sende ich widersprüchliche Signale.
Auch hier zeigt sich: Crawl-Steuerung besteht selten aus einer einzelnen Einstellung.
Sie entsteht aus dem Zusammenspiel von Informationsarchitektur, interner Verlinkung, HTTP-Statuscodes, Canonicals, robots.txt, Sitemaps und Indexierungssteuerung.
Weniger Crawling bedeutet nicht automatisch mehr Crawling an anderer Stelle
Es gibt noch einen wichtigen Punkt, der schnell übersehen wird.
Wenn ich zwei Millionen Sortier-URLs erfolgreich aus dem Crawling entferne, bedeutet das nicht automatisch, dass Google anschließend exakt zwei Millionen zusätzliche Requests auf meine wichtigen Produktseiten verteilt.
Crawl-Budget funktioniert nicht wie ein Kontostand, bei dem eingesparte Ressourcen zwangsläufig an anderer Stelle ausgegeben werden.
Google weist ausdrücklich darauf hin, dass durch robots.txt eingesparte Crawling-Kapazität nur dann automatisch auf andere Bereiche übergehen kann, wenn Google die technische Kapazitätsgrenze der Website bereits erreicht hat. Das Blockieren unnötiger URLs sollte deshalb nicht als Methode verstanden werden, um Google künstlich zu mehr Crawling zu zwingen.
Das eigentliche Ziel ist ein anderes.
Ich möchte die Wahrscheinlichkeit erhöhen, dass Googlebot seine Zeit mit URLs verbringt, die für meine Website tatsächlich relevant sind.
Es geht um Effizienz, nicht um möglichst hohe Crawl-Zahlen.
Was ich aus einem Crawl-Audit eigentlich wissen möchte
Wenn ich Server-Logs analysiere und feststelle, dass Googlebot zwölf Millionen Requests produziert hat, ist die absolute Zahl deshalb nur der Anfang.
Interessanter wird die Verteilung.
Wie viel Crawling entfällt auf indexierbare Produkt- und Kategorieseiten? Wie viel auf Parameter? Wie viel auf Redirects? Wie häufig werden Fehlerseiten erneut angefragt? Welche Bereiche werden intensiv gecrawlt, obwohl sie für die organische Suche kaum Bedeutung besitzen? Und welche wichtigen Bereiche werden überraschend selten besucht?
Erst daraus entsteht ein tatsächliches Crawl-Audit.
Die Logfiles zeigen mir nicht nur, wie Google meine Website crawlt. Sie zeigen mir indirekt auch, welche Websitearchitektur ich Google anbiete.
Und manchmal liegt das größte SEO-Problem deshalb nicht darin, dass Google zu wenig crawlt.
Es liegt daran, dass meine Website Google viel zu viel zum Crawlen gibt.
Mein Fazit
Crawl-Budget ist für mich weniger eine Frage danach, wie ich mehr Crawling bekomme, sondern wie ich Crawling sinnvoller mache.
Eine dauerhaft entfernte Produktseite sollte ihren Zustand technisch eindeutig kommunizieren. Sortierparameter ohne eigenen Suchwert müssen Google nicht dauerhaft beschäftigen. Bei Filter-URLs muss dagegen sorgfältiger unterschieden werden, weil einzelne Facetten durchaus relevante Suchintentionen abbilden können.
Genau deshalb kann man Crawl-Steuerung nicht auf eine einzelne Regel reduzieren.
404, 410, robots.txt, Canonicals oder noindex sind keine konkurrierenden Lösungen für dasselbe Problem. Sie erfüllen unterschiedliche Aufgaben.
Die eigentliche Arbeit findet davor statt.
Ich muss verstehen, welche URLs meine Website erzeugt, warum sie existieren und welchen Wert sie für Nutzer und Suchmaschinen haben.
Erst danach kann ich entscheiden, welche Google crawlen soll.
Und vielleicht ist genau das der wichtigste Perspektivwechsel beim Crawl-Budget:
Nicht jede URL, die technisch existieren kann, muss auch Teil der Website sein, die ich Google zeigen möchte.
Weiterführende Quellen
Google Search Central: Crawl-Budget für große Websites optimieren
Google Search Central: Facettensuche und Crawling
Google Search Central: Crawling von Facettensuchen verwalten
Google Search Central: Fehler beim Crawling und entfernte URLs
Google Search Central: Einführung in robots.txt
