DER INDEX SWARM: CRAWL-BUDGET FÜR SEITEN-FABRIKEN

Eine Seiten-Fabrik erzeugt URLs schneller, als irgendein Crawler sie lesen will. Template mal Datensatz, Filter mal Sortierung, Stadt mal Leistung. Der Schwarm ist in Minuten gebaut.

Dann beginnt das Warten. Seiten stehen in der Search Console als gefunden, aber nicht indexiert. Der Reflex lautet: mehr Crawl-Budget. Als gäbe es einen Regler, den man nur finden muss.

Den Regler gibt es nicht. Google beschreibt Crawl-Budget als Ergebnis aus zwei Kräften, und nur eine davon liegt halbwegs in deiner Hand. Wer Seiten in Massen erzeugt, muss deshalb nicht mehr Budget fordern, sondern weniger Verschwendung zulassen.

BRAUCHST DU DAS ÜBERHAUPT?

Die erste Frage ist unbequem, weil die Antwort oft Nein lautet. Googles Leitfaden Optimize your crawl budget richtet sich nach eigener Aussage an drei Typen von Websites:

• große Sites mit mehr als einer Million eindeutiger Seiten, deren Inhalte sich etwa wöchentlich ändern,
• mittlere oder größere Sites mit mehr als 10.000 Seiten und täglich wechselnden Inhalten,
• Sites, bei denen ein großer Teil der URLs in der Search Console als “Discovered - currently not indexed” geführt wird.

Google nennt diese Zahlen ausdrücklich grobe Schätzungen, keine exakten Schwellen. Wer nicht in diese Gruppen fällt oder dessen Seiten am Tag der Veröffentlichung gecrawlt werden, braucht den Leitfaden laut Google nicht. Für die Suche reiche dann eine aktuelle Sitemap und der regelmäßige Blick in den Bericht zur Seitenindexierung.

Für Programmatic SEO ist der dritte Punkt der relevante. Ein ausgedachtes Beispiel: Eine Fabrik mit 30.000 Seiten ohne tägliche Änderungen fällt nach der Faustregel in keine der ersten beiden Gruppen. Liegt aber ein großer Teil davon dauerhaft in “Discovered”, hast du kein Größenproblem, sondern ein Signal.

MACHINE NOTE Crawl-Budget ist selten die Ursache. Meist ist es das Symptom eines Inventars, das niemand kuratiert.

DIE ZWEI KRÄFTE: KAPAZITÄT UND NACHFRAGE

Google zerlegt Crawl-Budget in zwei Größen. Die erste ist das Crawl Capacity Limit, intern auch Hostload genannt. Es begrenzt, wie viel Zeit dein Server mit offenen Verbindungen für Google verbringt, also Zahl und Dauer paralleler Verbindungen. Jede Site startet mit demselben konservativen Standardwert. Antwortet der Server stabil und schnell, steigt die Grenze. Steigen Latenz und Antwortzeiten, oder kommen 5xx-Fehler und 429-Signale zurück, sinkt sie.

Wichtig für Architekten: Google definiert eine Site in diesem Zusammenhang als eindeutigen Hostnamen. www.example.com und code.example.com haben getrennte Budgets. Und die Kapazitätsgrenze teilen sich alle Google-Crawler einer Site. Hohe Nachfrage eines Crawlers kann laut Google die Kapazität für andere verringern.

Die zweite Größe ist die Crawl Demand. Für Googlebot hängt sie laut Leitfaden von Größe, Aktualisierungsfrequenz, Seitenqualität und Relevanz der Site im Vergleich zu anderen ab. Drei Faktoren nennt Google als beeinflussbar:

• Perceived Inventory: Ohne Steuerung versucht Google, alle oder fast alle bekannten URLs zu crawlen. Google bezeichnet diesen Faktor als den, den du am stärksten positiv kontrollieren kannst.
• Popularity: Im Netz populäre URLs werden öfter gecrawlt.
• Staleness: Google will Dokumente oft genug erneut abrufen, um Änderungen zu erkennen.

Das Budget ist am Ende die Menge an URLs, die Google crawlen kann und will. Liegt die Nachfrage niedrig, crawlt Google weniger, auch wenn die Kapazität nicht ausgeschöpft ist. Und nicht jede gecrawlte Seite wird indexiert. Nach dem Crawl wird jede Seite bewertet und konsolidiert.

DER RAHMEN: VIER VENTILE DES INDEX SWARM

Die folgende Matrix ist meine Übertragung der Google-Hinweise auf eine Seiten-Fabrik. Jedes Ventil hat einen Hebel, ein Messsignal und einen typischen Fehler, der Budget verbrennt.

Ventil	Hebel	Woran du es misst	Typischer Fehler
1. Inventar	Duplikate konsolidieren, unwichtige URL-Räume per robots.txt sperren, Entferntes mit 404 oder 410 beantworten	Anteil “Discovered - currently not indexed”, Soft-404 im Indexierungsbericht	Filter- und Sortiervarianten offen lassen, noindex als Crawl-Bremse einsetzen
2. Antwort	Server-Antwortzeit, keine 5xx, kein unnötiges 429	Crawling-Statistik in der Search Console, Server-Logs	Render-Cluster, der unter Crawl-Last langsamer wird
3. Wiederholung	ETag oder Last-Modified, 304 ohne Body, korrektes lastmod	Anteil 304-Antworten an Googlebot in den Logs	lastmod bei jedem Build neu setzen, obwohl sich nichts geändert hat
4. Ressourcen	wenige Render-Ressourcen, stabile Asset-URLs	Ressourcen-Abrufe pro Crawler in Crawling-Statistik und Logs	Cache-Busting-Parameter bei jedem Deploy, gesperrte CSS- oder JS-Dateien

Die Reihenfolge ist Absicht. Ventil 1 entscheidet, wie viele URLs überhaupt in die Warteschlange kommen. Die anderen drei entscheiden, wie teuer jede einzelne davon ist.

VENTIL 1: DAS INVENTAR

Hier passieren die teuersten Fehler, weil sie sich mit jedem Datensatz multiplizieren. Googles Leitfaden ist an drei Stellen schärfer, als viele Operatoren annehmen.

Erstens: noindex spart kein Crawling. Google ruft die Seite trotzdem ab und verwirft sie erst, wenn das noindex im HTML oder im HTTP-Header steht. Wer Facetten-URLs nur auf noindex setzt, bezahlt jeden Abruf weiter.

Zweitens: robots.txt ist kein Umverteiler. Wer URLs sperrt, damit das frei werdende Budget anderen Seiten zugutekommt, wird enttäuscht. Laut Google wird das Budget nur umgeschichtet, wenn die Site bereits an ihre Kapazitätsgrenze stößt. Sperre per robots.txt nur, was Google dauerhaft nicht crawlen soll.

Drittens: 404 schlägt Sperre. Google vergisst eine bekannte URL nicht. Ein 404 ist aber ein starkes Signal, sie nicht erneut abzurufen. Per robots.txt gesperrte URLs bleiben dagegen deutlich länger in der Crawl-Warteschlange und werden wieder gecrawlt, sobald die Sperre fällt. Soft-404-Seiten, also leere Seiten mit Status 200, werden weiter gecrawlt und verschwenden Budget.

Für eine Fabrik heißt das: Eine Kombination ohne ausreichende Daten bekommt keine Seite mit 200 und dünnem Inhalt. Sie bekommt gar keine URL, oder eine ehrliche 404.

MACHINE NOTE Jede URL ist ein Versprechen an den Crawler. Wer Versprechen massenhaft bricht, wird seltener besucht.

VENTIL 2 UND 3: ANTWORT UND WIEDERHOLUNG

Die Kapazitätsgrenze reagiert auf Gesundheit. Ein Server, der unter Last langsamer wird oder mit Fehlern antwortet, senkt sie selbst. Für mehr Budget nennt Google genau zwei Wege: mehr Server-Ressourcen, wenn die Kapazität auf deiner Seite der Engpass ist, und Inhalte, deren Qualität für das jeweilige Google-Produkt zählt. Für die Suche gehören dazu laut Google Popularität, Nutzwert, Einzigartigkeit und Auslieferungskapazität.

Der unterschätzte Hebel ist die Wiederholung. Im Beitrag Crawling December: HTTP caching schreibt Google, dass Googles Crawler bedingte Anfragen nach dem HTTP-Caching-Standard unterstützen, über ETag mit If-None-Match und über Last-Modified mit If-Modified-Since. Google empfiehlt ETag, weil es weniger fehleranfällig ist. Stimmt der Wert überein, soll der Server 304 ohne Body liefern. Nach Googles eigenen Angaben ist der Anteil cachebarer Abrufe gering: vor zehn Jahren rund 0,026 Prozent, heute 0,017 Prozent. Für Fabriken mit vielen selten geänderten Seiten liegt hier also Spielraum.

Dazu passt die Sitemap. Laut Build and submit a sitemap ignoriert Google priority und changefreq. lastmod nutzt Google nur, wenn der Wert konsistent und überprüfbar stimmt. Eine Pipeline, die bei jedem Build alle Datumswerte neu setzt, entwertet damit das einzige Feld, das zählt.

VENTIL 4: DIE RESSOURCEN

Seiten bestehen nicht nur aus HTML. Im Beitrag Crawling December: The how and why of Googlebot crawling beschreibt Google, dass der Web Rendering Service JavaScript und CSS über Googlebot nachlädt und das Budget des Hostnamens belastet, der die Ressource ausliefert. Der WRS speichert Ressourcen laut Google bis zu 30 Tage, unabhängig von HTTP-Caching-Anweisungen.

Daraus folgt: Ändert sich bei jedem Deploy der Dateiname jedes Bundles, obwohl der Inhalt gleich bleibt, muss Google die Ressourcen erneut holen. Google rät, Cache-Busting-Parameter vorsichtig einzusetzen und möglichst wenige Ressourcen zu verwenden. Render-kritische Dateien per robots.txt zu sperren, ist keine Lösung, weil Google den Inhalt dann eventuell nicht korrekt extrahieren kann.

Als beste Analysequelle nennt Google die rohen Access-Logs, als zweitbeste den Bericht zur Crawling-Statistik in der Search Console.

MACHINE NOTE Die Logs sind die Wahrheit. Die Search Console ist die Zusammenfassung.

OPERATOR CHECKLIST: CRAWL-BUDGET IM INDEX SWARM

1. Prüfe zuerst, ob du zu den Site-Typen aus Googles Leitfaden gehörst, bevor du optimierst.
2. Erzeuge URLs nur für Kombinationen, die ein Daten-Gate bestanden haben. Alles andere bekommt keine URL oder eine 404.
3. Setze noindex nicht als Crawl-Bremse ein. Konsolidiere Duplikate oder sperre URL-Räume dauerhaft.
4. Entferne Seiten mit 404 oder 410 statt mit einer robots.txt-Sperre.
5. Liefere ETag aus und beantworte unveränderte Seiten mit 304 ohne Body.
6. Setze lastmod nur bei echten Inhaltsänderungen.
7. Halte Asset-URLs über Deploys stabil, solange sich der Inhalt nicht ändert.
8. Werte Googlebot-Zugriffe in den Server-Logs aus, nicht nur in der Search Console.

FINAL THESIS

Crawl-Budget ist keine Zuteilung, die man erbittet, sondern die Antwort des Crawlers auf dein Inventar und deinen Server. Eine Seiten-Fabrik, die nur Seiten mit Daten erzeugt, Unverändertes mit 304 beantwortet und ehrliche 404 liefert, braucht selten mehr Budget. Sie verschwendet einfach keines.