Crawl Budget 2026: Multi-Bot-Governance für AI-Crawler

Crawl Budget galt lange als Nischenthema für sehr grosse Websites. Das hat sich 2026 geändert. Neben dem Googlebot greift inzwischen ein ganzes Feld von KI-Crawlern auf Websites zu, mit eigenen Zielen, eigener Last und eigenem Nutzen. Crawl Budget ist damit von einer reinen Google-Frage zu einem Multi-Bot-Governance-Problem geworden. Dieser Artikel erklärt, wie Crawl Budget technisch funktioniert, ab wann es im DACH-B2B wirklich relevant wird und wie eine differenzierte Steuerung von Googlebot, Bingbot und KI-Crawlern in der Praxis aussieht.

Warum Crawl Budget 2026 ein Multi-Bot-Problem ist

Klassisch beschreibt Crawl Budget, wie viele Seiten eine Suchmaschine pro Zeitraum von einer Website abruft. Solange nur der Googlebot relevant war, betraf das fast ausschliesslich sehr grosse Websites. Diese Annahme greift 2026 zu kurz, weil die Crawler-Landschaft sich grundlegend verbreitert hat.

Der Anstieg ist messbar. Laut der internationalen Cloudflare-Auswertung machten KI-Bots 2025 im Jahresdurchschnitt 4,2 Prozent aller HTML-Requests aus, der Googlebot 4,5 Prozent, womit dieser nur noch knapp größer war als alle KI-Bots zusammen. Besonders dynamisch ist das nutzergetriebene KI-Crawling: Es wuchs 2025 um mehr als das 15-Fache, also jenes Crawling, bei dem ein Bot eine Seite in Echtzeit als Reaktion auf eine Chatbot-Frage besucht. Innerhalb der reinen KI-Crawler verschob sich das Gewicht stark in Richtung OpenAI: Der GPTBot stieg zwischen Mai 2024 und Mai 2025 von 5 auf 30 Prozent Anteil unter den KI-Crawlern, bei einem Request-Wachstum von 305 Prozent, während Bytespider im selben Zeitraum von 42 auf 7,2 Prozent fiel.

Für den österreichischen B2B-Markt bleibt der Googlebot zwar der wichtigste Crawler, weil Google im Mai 2026 mit 81,87 Prozent Marktanteil vor Bing mit 9,01 Prozent und DuckDuckGo mit 2,75 Prozent klar dominiert. Doch die KI-Crawler kommen on top: Sie verbrauchen Server-Ressourcen, beanspruchen Edge- und CDN-Kapazität und stellen die Frage, welcher Bot welchen Gegenwert liefert. Genau das macht Crawl Budget zu einem Steuerungsthema für alle Stakeholder, nicht nur für Google.

Crawl Capacity Limit und Crawl Demand: ab wann es relevant wird

Google definiert das Crawl Budget einer Website als die Menge an URLs, die Google crawlen kann und will. Es ergibt sich aus zwei Komponenten: dem Crawl Capacity Limit und dem Crawl Demand.

• Crawl Capacity Limit: Die Obergrenze dessen, was der Server ohne Überlastung verkraftet. Antwortet eine Website schnell und fehlerfrei, steigt das Limit. Wird sie langsam oder liefert Serverfehler, drosselt Google das Crawling, um die Website zu schonen.
• Crawl Demand: Der Bedarf, eine URL zu crawlen. Er hängt von der Popularität einer Seite und davon ab, wie oft sich ihr Inhalt ändert. Veraltete oder unveränderte Seiten werden seltener besucht.

Entscheidend ist die Frage, ab wann das überhaupt eine Rolle spielt. Google ist hier eindeutig: Der eigene Leitfaden richtet sich an grosse Websites mit über 1 Million einzigartigen Seiten und wöchentlich änderndem Content sowie an mittlere und größere Websites mit über 10.000 einzigartigen Seiten und sehr häufig, etwa täglich, änderndem Inhalt. Für die typische DACH-B2B-Website mit einigen Hundert Seiten ist Crawl Budget aus reiner Googlebot-Sicht also selten der Engpass.

Diese Entwarnung gilt jedoch nur für den Googlebot und nur für das klassische Crawling. Sobald facettierte Navigation, Filter-URLs oder ein grosser Produktkatalog die URL-Menge künstlich aufblähen, kann auch eine mittelgrosse Website ein Budget-Problem bekommen. Und die KI-Crawler folgen einer eigenen Logik, die mit Googles Schwellen nichts zu tun hat.

Multi-Bot-Governance: differenzierte robots.txt-Strategie

Der erste Hebel ist die robots.txt. Sie ist 2026 kein simples Erlauben oder Sperren mehr, sondern eine Steuerungstabelle für unterschiedliche Bot-Klassen. International ist die robots.txt langst zum Schauplatz des KI-Crawler-Managements geworden. Laut dem Web Almanac 2025 werden die wichtigsten KI-Crawler dort bereits gezielt adressiert: GPTBot in 4,5 Prozent, ClaudeBot in 3,6 Prozent, CCBot in 3,5 Prozent und Google-Extended in 3,4 Prozent der Desktop-robots.txt-Dateien, wobei GPTBot sich gegenüber 2024 nahezu verdoppelt hat. Die mit Abstand häufigste Direktive bleibt der Platzhalter: Der Catch-all-User-Agent Stern (*) tauchte 2025 in 77 Prozent der Dateien auf.

Eine durchdachte Strategie unterscheidet die Bots nach ihrem Zweck:

• Suchmaschinen-Crawler (Googlebot, Bingbot): Vollzugriff. Sie liefern den organischen Traffic und sind im DACH-Raum die Geschäftsgrundlage. Hier wird nie pauschal gesperrt, sondern nur gezielt Crawl-Verschwendung vermieden.
• KI-Such-Crawler (OAI-SearchBot, PerplexityBot): Bedienen Echtzeit-Antworten mit Quellenangabe und potenziellem Referral-Traffic. Wer in KI-Antworten sichtbar sein will, lässt sie in der Regel zu.
• KI-Training-Crawler (GPTBot, ClaudeBot, CCBot, Google-Extended, Meta-ExternalAgent): Sammeln Daten fürs Modelltraining. Hier ist eine bewusste Abwägung nötig, weil dem Ressourcenverbrauch oft kein direkter Gegenwert gegenübersteht.

Wichtig ist die saubere Trennung der User Agents. Google-Extended steuert ausschliesslich die Nutzung für KI-Training und Gemini, nicht das normale Google-Such-Crawling. Wer Google-Extended sperrt, behält also seine Google-Sichtbarkeit und schliesst nur die Trainingsnutzung aus. Diese Differenzierung ist der Kern der Multi-Bot-Governance.

KI-Crawler-Lasttypen unterscheiden: Training, Suche, Echtzeit

Pauschales Blocken oder Erlauben verkennt, dass KI-Crawler drei völlig verschiedene Aufgaben erfüllen. Die internationale Cloudflare-Datenanalyse quantifiziert das Verhältnis klar: Training treibt mittlerweile nahezu 80 Prozent der KI-Bot-Aktivität, 18 Prozent entfallen auf Suche und nur 2 Prozent auf nutzergetriebene Aktionen.

• Training-Crawling: Bots wie GPTBot, ClaudeBot oder CCBot laden Inhalte für das Modelltraining. Dieser Zugriff erzeugt Last, führt aber selten zu direkt zurechenbarem Traffic. Es ist der Lasttyp mit dem schwächsten unmittelbaren Gegenwert.
• Such-Crawling: KI-Suchsysteme rufen Inhalte ab, um sie in Antworten zu zitieren. Hier besteht die Chance auf Referral-Traffic und Markensichtbarkeit, vergleichbar mit klassischer Suche.
• Nutzergetriebenes Echtzeit-Crawling: Bots wie ChatGPT-User besuchen eine Seite live, weil ein Nutzer im Chat eine Frage gestellt hat. Dieser Lasttyp ist klein im Volumen, signalisiert aber konkretes Nutzerinteresse an genau diesem Inhalt im Moment der Anfrage.

Die praktische Konsequenz: Wer Server-Kosten senken will, ohne Sichtbarkeit zu opfern, drosselt zuerst das Training-Crawling und behält Such- sowie Echtzeit-Crawling. Eine pauschale Sperre aller KI-Bots würde dagegen auch die potenziell wertvollen Zugriffe abschneiden.

Crawl-Budget-Verschwendung eliminieren

Bevor man über Bot-Management nachdenkt, sollte die hausgemachte Verschwendung beseitigt sein. Sie ist in der Praxis das größte Problem, und sie betrifft alle Crawler gleichermassen. Wie dramatisch das Verhältnis kippen kann, zeigt eine internationale Botify-Fallstudie: Dort waren 97 Prozent von rund 1 Million gecrawlten Seiten nicht-kanonisch, bei nur etwa 25.000 indexierbaren URLs, von denen Google im Monat nur gut die Hälfte crawlte. Branchenweit werden bei unoptimierten Websites laut derselben Quelle im Schnitt nur 40 Prozent der strategischen URLs pro Monat von Google gecrawlt, 60 Prozent bleiben uncrawled.

Die typischen Quellen der Verschwendung lassen sich gezielt schliessen:

• Facettierte Navigation und Parameter-URLs: Filter- und Sortier-Kombinationen erzeugen nahezu unbegrenzt viele URLs mit kaum unterschiedlichem Inhalt. Steuerung über Canonical-Tags, gezieltes noindex oder das Sperren ganzer Parameter-Pfade in der robots.txt.
• Duplicate Content: Mehrere URLs mit identischem Inhalt, etwa durch Gross- und Kleinschreibung, Trailing Slashes oder Session-IDs. Eine konsequente Canonical-Strategie bündelt die Signale auf eine bevorzugte URL.
• Soft-404s: Seiten ohne echten Inhalt, die fälschlich einen Status 200 liefern statt 404 oder 410. Sie binden Crawl-Budget für Inhalte ohne Wert.
• Endlose Crawl-Pfade: Kalender, Pagination ohne Ende oder verschachtelte Filter, die Crawler in immer neue Tiefen führen.

Der Grundsatz lautet: Crawler sollen ihre begrenzte Zeit auf den Seiten verbringen, die ranken oder zitiert werden sollen, nicht auf technischem Ballast.

Aktive Index-Steuerung: Sitemaps und IndexNow

Statt nur Verschwendung zu vermeiden, kann man Crawler aktiv zu den richtigen URLs lenken. Zwei komplementäre Instrumente stehen dafür zur Verfügung.

• XML-Sitemaps: Sie listen die kanonischen, indexierungswürdigen URLs samt Aktualisierungsdatum. Eine gepflegte Sitemap hilft Suchmaschinen, neue und geänderte Seiten effizient zu finden, ohne die gesamte Website abzulaufen. Sie ist die Basis jeder Crawl-Schonung.
• IndexNow: Ein Push-Protokoll, mit dem eine Website Suchmaschinen aktiv über neue oder geänderte URLs informiert, statt auf den nächsten Crawl zu warten. Die Adoption ist erheblich: Laut Bing werden über IndexNow mehr als 3,5 Milliarden URLs pro Tag eingereicht, und 18 Prozent aller neu in den Web-Suchergebnissen geklickten URLs stammen daraus.

Der entscheidende Vorbehalt für den DACH-Raum: IndexNow wird von Bing, Yandex und weiteren unterstützt, nicht aber von Google. Da Google in Österreich den Markt dominiert, ist IndexNow hier eine sinnvolle Ergänzung für die Bing-Sichtbarkeit, ersetzt aber keine saubere Sitemap- und Crawl-Strategie für Google. Beide Instrumente wirken komplementär: Sitemaps für Google, IndexNow zusätzlich für die IndexNow-Teilnehmer.

Edge-, CDN- und Server-Layer-Bot-Management

Die robots.txt ist eine Bitte, kein Zwang. Seriose Crawler halten sich daran, andere nicht. Wer Crawl-Überlast technisch durchsetzen oder unerwünschte Bots zuverlässig stoppen will, braucht eine Steuerung auf Edge-, CDN- und Server-Ebene.

• Verifizierung legitimer Bots: Echte Crawler lassen sich über ihre offiziell publizierten IP-Bereiche oder per Reverse-DNS verifizieren. So trennt man den echten Googlebot von Bots, die seinen User Agent nur fälschen.
• Rate-Limiting: Begrenzt die Request-Frequenz pro Bot oder IP-Bereich. Das schützt den Ursprungsserver vor Lastspitzen, ohne legitime Crawler komplett auszusperren.
• Selektives Blocking und Allowing: Auf CDN-Ebene lassen sich KI-Trainings-Bots gezielt blockieren, während Such- und Echtzeit-Bots durchgelassen werden. Das ist präziser und durchsetzungsstärker als die robots.txt allein.
• Schutz des Caches: KI-Crawler greifen häufig auf selten besuchte Long-Tail-Inhalte zu, die nicht im Edge-Cache liegen. Solche Zugriffe gehen direkt an den Ursprungsserver und konkurrieren mit menschlichem Traffic um Ressourcen. Rate-Limiting und gezieltes Routing entlasten hier.

Diese Ebene ist besonders für ressourcensensible B2B-Websites relevant, bei denen Serverkapazität und stabile Antwortzeiten für zahlende Kunden Vorrang vor unkontrolliertem Bot-Zugriff haben.

Log-File-Analyse als Steuerungsinstrument

Ohne Messung ist jede Crawl-Steuerung Blindflug. Standard-Webanalyse wie GA4 erfasst KI-Crawler praktisch nicht, weil diese kein JavaScript ausführen und keine Cookies setzen. Die einzige verlässliche Datenquelle ist die Server-Log-Datei. Sie zeigt, welcher Bot wann welche URL mit welchem Statuscode abgerufen hat.

Aus den Logs lassen sich die entscheidenden Steuerungsgrößen ableiten:

• Crawl-Frequenz pro Bot: Wie oft besucht Googlebot, GPTBot oder ClaudeBot die Website, und welche URL-Bereiche? So erkennt man, ob Budget auf wertlose Seiten fliesst.
• Crawl-to-Refer-Wert: Das Verhältnis aus gecrawlten Seiten zu tatsächlich vermittelten Besuchern bewertet den Gegenwert eines Bots. Die internationalen Cloudflare-Werte für Juli 2025 zeigen die enorme Spreizung: Anthropic crawlte rund 38.065 Seiten pro vermitteltem Besucher, OpenAI rund 1.091 und Google nur 5,4. Je höher dieser Wert, desto schlechter das Verhältnis von Last zu Nutzen.
• Statuscode-Verteilung: Häufen sich 404 oder 5xx im Bot-Traffic, deutet das auf Crawl-Verschwendung oder Serverprobleme hin, die das Crawl Capacity Limit drücken.

Auf dieser Datenbasis lässt sich Budget gezielt umlenken: Bots mit schlechtem Crawl-to-Refer-Verhältnis drosseln, wertvolle Crawler auf die strategischen URLs lenken. Log-File-Analyse ist damit das zentrale Messinstrument der Multi-Bot-Governance.

Next.js und JavaScript-SEO: Rendering-Budget mitdenken

Crawl Budget hat eine zweite, oft übersehene Dimension: das Render-Budget. Wer Inhalte erst clientseitig per JavaScript aufbaut, verlangt vom Crawler einen zweiten, teuren Schritt. Google muss die Seite nicht nur crawlen, sondern auch rendern, um den Inhalt zu sehen. Das verbraucht zusätzliche Ressourcen und verzögert die Indexierung.

Für eine moderne Next.js-Architektur ergibt sich daraus eine klare Rangordnung der Rendering-Strategien:

• SSG (Static Site Generation): Seiten werden zum Build-Zeitpunkt vorgerendert und als fertiges HTML ausgeliefert. Crawl- und render-effizientester Ansatz, ideal für stabile Inhalte wie Fachartikel oder Leistungsseiten.
• ISR (Incremental Static Regeneration): Statische Seiten werden im Hintergrund periodisch neu generiert. Verbindet die Effizienz von SSG mit Aktualität, gut für häufig, aber nicht sekündlich ändernde Inhalte.
• SSR (Server-Side Rendering): Das HTML wird pro Anfrage auf dem Server erzeugt. Der Crawler erhält vollständiges HTML, ohne selbst rendern zu müssen. Sinnvoll für personalisierte oder hochdynamische Seiten.
• CSR (Client-Side Rendering): Der Inhalt entsteht erst im Browser. Für SEO der ungünstigste Fall, weil er Crawl- und Render-Budget doppelt belastet und besonders KI-Crawler, die oft gar kein JavaScript ausführen, leer ausgehen lässt.

Die Faustregel für crawl-effiziente DACH-B2B-Websites lautet: indexierungsrelevante Inhalte serverseitig oder statisch bereitstellen, damit jeder Crawler den vollständigen Inhalt direkt im HTML vorfindet. Das spart Render-Budget und macht Inhalte auch für JavaScript-blinde KI-Crawler zugänglich.

KI-Crawler, GEO und Monetarisierung: llms.txt und Pay-per-Crawl

Mit der Last der KI-Crawler stellt sich die strategische Frage nach dem Gegenwert. Hier entstehen 2026 neue Mechanismen, die noch jung und uneinheitlich sind.

• llms.txt: Eine vorgeschlagene Datei, die KI-Systemen kuratierte, gut strukturierte Inhalte gebündelt anbietet. Die Verbreitung ist allerdings noch gering: Laut Web Almanac 2025 stellen nur 2,13 Prozent der Desktop-Websites eine gültige llms.txt bereit, davon 39,6 Prozent generiert über das All-in-One-SEO-Plugin. Ein verbindlicher Standard ist daraus bislang nicht geworden.
• Pay-per-Crawl-Ansätze: Modelle, bei denen KI-Anbieter für den Zugriff auf Inhalte zahlen, statt sie kostenlos zu crawlen. Sie adressieren genau das Ungleichgewicht aus hoher Crawl-Last und geringem Referral, das die Crawl-to-Refer-Werte offenlegen.

Im Kern ist es eine Abwägung: Sichtbarkeit in KI-Antworten (GEO) auf der einen Seite, Server-Kosten und Kontrolle über die eigenen Inhalte auf der anderen. Für DACH-B2B-Unternehmen, deren Fachinhalte ein zentrales Asset sind, lohnt eine bewusste Entscheidung pro Crawler-Klasse, statt alles undifferenziert zuzulassen oder zu sperren.

DSGVO, TDM-Vorbehalt und rechtliche Dimension

Im DACH-Raum hat der Umgang mit KI-Crawlern auch eine rechtliche Ebene. Sie ist für österreichische Unternehmen relevant, weil sie über blosse technische Steuerung hinausgeht.

• Opt-out für KI-Training: Mit Direktiven wie der Sperre von Google-Extended oder GPTBot in der robots.txt signalisiert eine Website, dass ihre Inhalte nicht für KI-Training genutzt werden sollen. Das ist die technische Umsetzung eines Nutzungsvorbehalts.
• TDM-Vorbehalt (Text and Data Mining): Das EU-Urheberrecht erlaubt Rechteinhabern, die Nutzung ihrer Werke für kommerzielles Text- und Data-Mining maschinenlesbar zu untersagen. Ein in robots.txt oder als maschinenlesbare Erklärung hinterlegter Vorbehalt ist die Grundlage, um KI-Training rechtlich auszuschliessen.
• DSGVO-Bezug: Enthalten öffentliche Seiten personenbezogene Daten, berührt deren Aufnahme in Trainingskorpora datenschutzrechtliche Fragen. Eine bewusste Crawler-Steuerung ist damit Teil einer sauberen Compliance.

Die Verbindung von technischer und rechtlicher Steuerung ist hier der Punkt: Die robots.txt ist nicht nur ein Crawl-Werkzeug, sondern dokumentiert zugleich den Willen des Rechteinhabers. Für die DSGVO-Compliance im österreichischen Kontext sollte diese Steuerung bewusst und nachvollziehbar erfolgen, idealerweise abgestimmt mit der Rechtsabteilung.

Weiterführendes und Fazit

Crawl Budget ist 2026 kein reines Grossseiten-Thema mehr, sondern ein aktiv zu steuerndes Multi-Bot-Problem. Aus reiner Googlebot-Sicht bleiben die Schwellen hoch, doch die Breite der KI-Crawler, ihre unterschiedliche Last und ihr stark schwankender Gegenwert machen eine differenzierte Governance auch für mittelgrosse DACH-B2B-Websites sinnvoll.

Die Prioritäten in der Praxis sind klar: erstens hausgemachte Crawl-Verschwendung durch Canonical-, noindex- und robots.txt-Hygiene eliminieren; zweitens eine differenzierte robots.txt aufsetzen, die Suchmaschinen, KI-Such-Crawler und KI-Trainings-Crawler unterschiedlich behandelt; drittens Server-Logs auswerten, um Crawl-Frequenz und Crawl-to-Refer-Werte zu messen und Budget umzulenken; viertens die Rendering-Architektur so wählen, dass Inhalte ohne Render-Aufwand zugänglich sind. Wer diese vier Ebenen verbindet und die rechtliche Dimension mitdenkt, behält die Kontrolle über den eigenen Server und entscheidet bewusst, für welchen Bot welcher Inhalt offensteht. Vertiefen lässt sich das Thema in den verwandten Artikeln zu robots.txt, XML-Sitemaps, Canonical-Tags und KI-Crawler-Management.