Server rack with glowing LED lights representing Googlebot crawl budget optimization

Crawl-Budget-Optimierung: Der vollständige Technical-SEO-Leitfaden (2026)

Ihr Content ist erstklassig. Ihre Backlinks sind stark. Aber Google hat 40 % Ihrer Seiten immer noch nicht indexiert. Kommt Ihnen das bekannt vor? Das Problem liegt nicht an Ihrem Content — es liegt weiter oben. Wenn Googlebot sein begrenztes Crawl-Budget für doppelte URLs, Redirect-Ketten und endlose Parameterkombinationen verschwendet, werden Ihre wichtigsten Seiten niemals entdeckt.

Crawl-Budget-Optimierung ist die Disziplin, Suchmaschinen-Crawler gezielt auf Ihre wertvollsten Seiten zu lenken und alles auszuschließen, was ihre Aufmerksamkeit nicht verdient. Für Websites mit Zehntausenden von URLs — E-Commerce-Kataloge, SaaS-Plattformen, Nachrichtenportale — ist dies die wirkungsvollste Investition in Technical SEO, die Sie tätigen können.

Dieser Leitfaden geht über die Grundlagen hinaus. Wir behandeln Diagnose, Priorisierung, CMS-spezifische Konfigurationen, das Management von AI-Crawlern und ein Monitoring-Framework, das Sie noch heute umsetzen können.

Was ist das Crawl-Budget? Die Formel, die Google verwendet

Das Crawl-Budget ist die Anzahl der URLs, die Googlebot innerhalb eines bestimmten Zeitraums auf Ihrer Website crawlt. Googles eigene Dokumentation definiert es anhand von zwei Komponenten:

Crawl-Budget = min(Crawl-Kapazitätslimit, Crawl-Nachfrage)

Komponente Bedeutung Einflussfaktoren
Crawl-Kapazitätslimit Maximale gleichzeitige Verbindungen + Verzögerung zwischen Anfragen, ohne den Server zu überlasten Serverantwortzeit, 5xx-Fehlerrate, Hosting-Infrastruktur
Crawl-Nachfrage Wie sehr Google basierend auf dem wahrgenommenen Wert crawlen möchte Content-Aktualität, Popularität, interne Linksignale, Sitemap-Präsenz

Die entscheidende Erkenntnis: Selbst wenn Ihr Server mehr Crawling verkraften könnte, wird Google nicht mehr crawlen, als es für nötig hält. Und wenn die Nachfrage hoch, aber Ihr Server langsam ist, wird das Crawling gedrosselt. Sie müssen beide Seiten optimieren.

💡 Wichtige Unterscheidung: Crawling und Indexierung sind separate Schritte. Eine Seite kann gecrawlt, aber nicht indexiert werden. Crawl-Budget-Optimierung stellt sicher, dass Google Ihre wichtigen Seiten erreicht; die Content-Qualität entscheidet, ob sie indexiert und gerankt werden.

Wann ist das Crawl-Budget wirklich relevant?

Seien wir ehrlich: Die meisten Websites müssen sich keine Gedanken über das Crawl-Budget machen. Googles Gary Illyes hat dies öffentlich bestätigt. So erkennen Sie, ob es für Sie relevant ist:

Website-Profil Crawl-Budget-Priorität Empfohlene Maßnahme
Unter 1.000 Seiten, einfache Struktur 🟢 Niedrig — kein Handlungsbedarf Fokus auf Content-Qualität und technische Basishygiene
1.000–10.000 Seiten 🟡 Beobachten — potenzielles Thema Grundlegende Crawl-Hygiene, GSC Crawl-Statistiken quartalsweise prüfen
10.000–100.000 Seiten 🟠 Wichtig — aktive Optimierung nötig Vollständiges Crawl-Budget-Audit, Log-File-Analyse, laufendes Monitoring
100.000+ Seiten 🔴 Kritisch — Top-SEO-Priorität Dedizierte Crawl-Budget-Strategie, Edge SEO, automatisiertes Monitoring
⚠️ Warnsignale für verschwendetes Crawl-Budget: Neue Seiten benötigen 2+ Wochen zur Indexierung. Die Google Search Console zeigt eine große Anzahl von „Entdeckt — derzeit nicht indexiert”-URLs. Der Crawl-Statistik-Bericht zeigt, dass Googlebot die meiste Zeit auf minderwertigen oder doppelten Seiten verbringt.

Schritt für Schritt: Crawl-Budget-Probleme diagnostizieren

1. Google Search Console — Crawl-Statistik-Bericht

Navigieren Sie zu Einstellungen → Crawl-Statistiken in der GSC. Dies ist Ihr erstes Diagnosetool. Hier ist genau, worauf Sie achten sollten:

Metrik Gesunder Richtwert Warnsignal
Crawl-Anfragen pro Tag gesamt Konstanter oder wachsender Trend Plötzliche Einbrüche (Serverprobleme) oder Spitzen (Crawl-Fallen)
Durchschnittliche Antwortzeit Unter 200 ms Über 500 ms konstant
Seiten-/tägliches-Crawl-Verhältnis Unter 10:1 Über 10:1 — dringender Handlungsbedarf
Antwortcodes 90 %+ sind 200 OK Hoher Anteil an 301/302/404/5xx
Dateityp-Aufschlüsselung HTML dominiert Bilder, CSS, JS verbrauchen Großteil der Crawl-Anfragen

Prüfen Sie auch den Abdeckungsbericht: Die Kategorie „Entdeckt — derzeit nicht indexiert” ist das direkteste Symptom für unzureichendes Budget. Wenn diese Zahl weiter wächst, während Ihre indexierten Seiten stagnieren, ist das Crawl-Budget Ihr Engpass.

2. Log-File-Analyse — die verlässlichste Quelle

Serverprotokolle zeigen exakt, was Googlebot crawlt, wie häufig und welche Antworten er erhält. Tools wie Screaming Frog Log Analyzer, SEOlyzer oder ein individuelles ELK-Stack-Setup ermöglichen:

  • Tatsächliche Crawl-Rate pro Website-Bereich berechnen (Blog vs. Produkte vs. Kategorieseiten)
  • Verwaiste Seiten identifizieren, die Googlebot nie erreicht
  • Crawl-Fallen aufspüren — URLs, die tausendfach gecrawlt werden, ohne Indexierungswert
  • Bot-Traffic-Verteilung messen: Googlebot vs. AI-Crawler vs. andere Bots
💡 Profi-Tipp: Vergleichen Sie die Anzahl der URLs in Ihrer Sitemap mit der Anzahl der einzigartigen URLs, die Googlebot tatsächlich in einem 30-Tage-Fenster crawlt. Wenn nur 60 % Ihrer Sitemap-URLs gecrawlt werden, ist das ein klares Signal für Budget-Engpässe.

3. Crawl-to-Index-Ratio

Diese Metrik wird oft übersehen, ist aber äußerst aussagekräftig. Berechnen Sie sie wie folgt:

Crawl-to-Index-Ratio = (Indexierte Seiten / Gecrawlte Seiten gesamt) × 100

Leistungsstarke Websites halten ein Verhältnis von über 85 %. Liegt Ihres unter 70 %, besteht erhebliches Optimierungspotenzial — Googlebot verbringt Zeit mit Seiten, die nie in den Index gelangen.

Die 12 größten Crawl-Budget-Killer (und wie Sie jeden beheben)

1. Facettierte Navigation — der #1 URL-Multiplikator

Ein Katalog mit 5.000 Produkten und 10 Filterkombinationen kann über 50.000 einzigartige URLs generieren. Die meisten davon sind Beinahe-Duplikate, die sich gegenseitig kannibalisieren und Crawl-Budget im großen Stil verbrauchen.

Lösung: Entscheiden Sie explizit, welche Facetten SEO-wertvoll sind (indexierbar, in der Sitemap, durch interne Links verstärkt) und welche nur der UX dienen (per robots.txt blockiert oder via JavaScript ohne crawlbare Links gerendert). Nutzen Sie Canonical Tags, um Filtervarianten auf die Hauptkategorieseite zurückzuverweisen.

2. Redirect-Ketten

Jede Weiterleitung in einer Kette erfordert eine separate HTTP-Anfrage. Eine Kette aus 3+ Redirects verschwendet Crawl-Ressourcen und kann dazu führen, dass Googlebot die Kette komplett abbricht.

Lösung: Alle Weiterleitungen auditieren. Ketten durch direkte Weiterleitungen zum endgültigen Ziel ersetzen. Nach einer Website-Migration regelmäßig Ketten entfernen, die sich im Laufe der Zeit ansammeln.

3. Doppelte Inhalte ohne Canonicals

HTTP vs. HTTPS. www vs. non-www. Trailing Slash vs. kein Slash. Tracking-Parameter wie ?utm_source=.... Jede Variante ist eine separate URL, die Googlebot unabhängig crawlt.

Lösung: Server-seitige Redirects (nicht nur Canonical Tags) für Protokoll- und Subdomain-Varianten implementieren. Canonical Tags für Parametervariationen nutzen. Tracking-Parameter über das URL-Parameter-Tool der Google Search Console oder auf Serverebene entfernen.

4. Soft 404s

Seiten, die einen 200-Statuscode zurückgeben, aber „keine Ergebnisse” oder leeren Content anzeigen. Google crawlt sie weiter, weil der Server signalisiert, dass alles in Ordnung ist.

Lösung: Korrekte 404- oder 410-Statuscodes für tatsächlich leere Seiten zurückgeben. Bei nicht vorrätigen Produkten entweder die Seite mit alternativen Empfehlungen live lassen oder 410 (Gone) zurückgeben, wenn das Produkt nicht zurückkehrt.

5. Serverantwortzeit über 500 ms

Langsame Server reduzieren direkt Ihr Crawl-Kapazitätslimit. Google drosselt die Crawl-Rate, um Ihre Infrastruktur nicht zu überlasten.

Lösung: TTFB unter 200 ms anstreben. Server-seitiges Caching implementieren (Redis, Varnish), Datenbankabfragen optimieren und sicherstellen, dass Ihr Hosting für Ihren Traffic plus Crawl-Last dimensioniert ist.

6. Verwaiste Seiten (Orphaned Pages)

Seiten ohne interne Links. Sie existieren in Ihrer Sitemap, aber es gibt keinen strukturellen Pfad von der Startseite. Googlebot priorisiert diese herunter, da fehlende interne Link-Equity niedrige Wichtigkeit signalisiert.

Lösung: Crawl mit Screaming Frog oder Sitebulb durchführen und gecrawlte URLs mit Sitemap-URLs abgleichen. Jede URL in der Sitemap, die beim Crawl nicht entdeckt wird, ist verwaist. Kontextuelle interne Links von relevanten Seiten hinzufügen.

7. Endloses Scrollen und Paginierungsfallen

Paginierung, die eine unbegrenzte Anzahl crawlbarer Seiten-URLs erzeugt (/page/2/, /page/3/, … /page/9999/) oder JavaScript-basiertes endloses Scrollen, das überhaupt keine crawlbaren Links erzeugt (das gegenteilige Problem).

Lösung: Für Paginierung rel="next"/"prev" verwenden (immer noch ein Signal, keine Direktive) und die Paginierungstiefe begrenzen. Für endloses Scrollen sicherstellen, dass paginierte HTML-Versionen als Fallback für Crawler existieren.

8. Session-IDs und dynamische Parameter

URLs wie /product?session_id=abc123 erzeugen für jede Benutzersitzung eine neue „Seite”. Multipliziert über Tausende von Produkten entstehen Millionen crawlbarer Duplikate.

Lösung: Session-Tracking auf Cookies umstellen. Falls Parameter in URLs bleiben müssen, diese per robots.txt blockieren oder URL-Parameter in der GSC konfigurieren.

9. Aufblähung durch Tags und Archivseiten

WordPress und ähnliche CMS-Plattformen erstellen automatisch Tag-Seiten, Datumsarchive und Autorenarchive. Bei einem Blog mit 500 Beiträgen und 200 Tags sind das über 200 dünne Seiten, die um Crawl-Budget konkurrieren.

Lösung: Minderwertige Archive (Datum, Autor) auf noindex setzen und letztlich per robots.txt blockieren. Tag-Seiten nur behalten, wenn sie einen echten Navigationszweck erfüllen und genug Content bieten, um wertvoll zu sein.

10. Große XML-Sitemaps mit veralteten URLs

Sitemaps, die mit 404-Seiten, weitergeleiteten URLs, nicht-kanonischen URLs oder noindex-Seiten aufgebläht sind, senden irreführende Signale darüber, welche URLs wichtig sind.

Lösung: Nur indexierbare, kanonische URLs mit 200-Status in die Sitemap aufnehmen. Jede Sitemap unter 10.000 URLs halten für optimale Verarbeitung. Korrekte <lastmod>-Daten setzen — nicht bei jedem Build automatisch aktualisieren. Sitemaps über GSC einreichen und in der robots.txt referenzieren.

11. JavaScript-gerenderte Inhalte

Google muss JS-gerenderte Seiten crawlen, für das Rendering in die Warteschlange stellen und dann erneut verarbeiten — ein zweistufiger Prozess, der deutlich mehr Crawl-Ressourcen kostet als reines HTML.

Lösung: Server-Side Rendering (SSR) oder Static Site Generation (SSG) für Schlüsselseiten implementieren. Sicherstellen, dass kritischer Content in der initialen HTML-Antwort enthalten ist. Dynamic Rendering als Übergangslösung für große JS-lastige Websites nutzen.

12. HTML-Seitengewicht über 2 MB

Eine Tatsache, die die meisten Leitfäden übersehen: Googlebot schneidet HTML-Inhalte ab einer Größe von ca. 2 MB ab. Schwere Seiten mit Inline-CSS, Base64-Bildern und Inline-SVGs erreichen dieses Limit und können abgeschnittenen Content haben.

Lösung: Inline-CSS und JavaScript externalisieren. Base64-Bilder und große Inline-SVGs entfernen. HTML minifizieren. Seitenquelltext unter 500 KB halten als Best Practice — weit unter dem Abschneidungslimit.

CMS-spezifische robots.txt-Vorlagen

Die meisten Leitfäden empfehlen „optimieren Sie Ihre robots.txt”, ohne zu zeigen, wie das für Ihre spezifische Plattform konkret aussieht. Hier sind produktionsreife Vorlagen:

WordPress

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-json/
Disallow: /wp-login.php
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /*?s=
Disallow: /*?replytocom
Disallow: /tag/
Disallow: /author/
Allow: /wp-admin/admin-ajax.php
Allow: /wp-content/uploads/

Sitemap: https://example.com/sitemap_index.xml

Shopify

User-agent: *
Disallow: /admin
Disallow: /cart
Disallow: /orders
Disallow: /checkouts/
Disallow: /checkout
Disallow: /account
Disallow: /collections/*sort_by*
Disallow: /collections/*+*
Disallow: /collections/*%2B*
Disallow: /collections/*%2b*
Disallow: /search
Disallow: /apple-app-site-association
Disallow: /.well-known

Sitemap: https://example.com/sitemap.xml

Magento 2

User-agent: *
Disallow: /checkout/
Disallow: /customer/
Disallow: /catalogsearch/
Disallow: /wishlist/
Disallow: /review/
Disallow: /sendfriend/
Disallow: /*?dir=
Disallow: /*?limit=
Disallow: /*?mode=
Disallow: /*?p=
Disallow: /*?price=
Disallow: /*?q=
Disallow: /*?SID=
Disallow: /catalog/product/view/
Allow: /media/

Sitemap: https://example.com/sitemap.xml
⚠️ Wichtig: Diese Vorlagen sind Ausgangspunkte. Passen Sie diese immer an Ihre spezifische Seitenstruktur an. Das Hinzufügen von noindex zu Seiten spart kein Crawl-Budget — Google ruft noindex-Seiten trotzdem ab, bevor es sie verwirft. Verwenden Sie robots.txt Disallow für permanentes Blockieren.

AI-Crawler 2026: Die neue Crawl-Budget-Herausforderung

Im Jahr 2026 haben Bots erstmals den menschlichen Web-Traffic überholt. AI-Crawler — GPTBot, ClaudeBot, PerplexityBot und andere — konkurrieren nun mit Googlebot um die Ressourcen Ihres Servers.

Das schafft ein echtes Problem: Wenn AI-Bots zu viel Serverkapazität verbrauchen, sinkt Ihr Crawl-Kapazitätslimit, und Google drosselt seine eigene Crawl-Rate. Das Ergebnis? Langsamere Indexierung Ihres tatsächlichen Contents.

Das AI-Crawler-Dilemma

Die naheliegende Reaktion ist, AI-Crawler in der robots.txt zu blockieren. Doch das hat einen dokumentierten Preis: Untersuchungen zeigen, dass Websites, die GPTBot blockieren, deutlich seltener in ChatGPT-Antworten zitiert werden. Für Unternehmen, die auf AI-generierte Sichtbarkeit setzen, ist das ein erheblicher Kompromiss.

Zudem blockieren ca. 38 % der Websites versehentlich Bingbot in ihrer robots.txt — und da ChatGPT Search auf dem Bing-Index basiert, sind diese Seiten für ChatGPT Search komplett unsichtbar.

Eine ausgewogene Strategie

AI-Bot Empfohlener Ansatz Begründung
GPTBot (OpenAI) Rate-Limiting via CDN, nicht komplett blockieren Erhält ChatGPT-Zitationssichtbarkeit
ClaudeBot (Anthropic) Rate-Limiting via CDN, nicht komplett blockieren Erhält Sichtbarkeit in Claude-basierten Tools
PerplexityBot Rate-Limiting via CDN, nicht komplett blockieren Erhält Sichtbarkeit in Perplexity AI
Bingbot Niemals blockieren Unverzichtbar für Bing-Rankings UND ChatGPT Search
Aggressive Scraper Über CDN/WAF blockieren Kein SEO-Nutzen, reiner Ressourcenverbrauch
💡 So implementieren Sie Rate-Limiting: Nutzen Sie Cloudflares Bot Management, die Rate-Limiting-Regeln Ihres CDNs oder Server-Level-Konfiguration (nginx limit_req_zone), um die Anfragehäufigkeit von AI-Bots zu drosseln, ohne sie komplett zu blockieren. Prüfen Sie Ihre Serverprotokolle auf AI-Bot-User-Agents, die unverhältnismäßig viele Ressourcen verbrauchen.

Edge SEO mit Cloudflare Workers

Edge SEO ermöglicht die Modifikation von HTTP-Antworten auf CDN-Ebene — bevor sie den Browser oder Crawler erreichen — ohne Ihren Anwendungscode zu ändern. Das ist besonders wirkungsvoll für die Crawl-Budget-Optimierung:

  • Canonical Tags injizieren bei parameterlastigen Seiten ohne Code-Deployments
  • X-Robots-Tag: noindex-Header hinzufügen für bestimmte URL-Muster am Edge
  • Redirects am Edge — schneller als Application-Level-Weiterleitungen, reduziert Antwortzeit und schafft Crawl-Kapazität
  • robots.txt dynamisch modifizieren basierend auf dem User Agent des anfragenden Bots
  • Hreflang-Tags automatisch injizieren für internationale Websites ohne CMS-Änderungen

Edge SEO ist besonders wertvoll, wenn Sie mit einem Legacy-CMS arbeiten, bei dem direkte Code-Änderungen langsam oder teuer sind. Ein Cloudflare Worker, der Redirects und Canonical-Injection handhabt, kann Crawl-Budget-Probleme in Stunden statt in wochenlangen Entwicklungssprints lösen.

Aufbau eines Crawl-Budget-Monitoring-Dashboards

Einmalige Optimierung reicht nicht aus. Crawl-Budget-Probleme kehren zurück, wenn Websites wachsen, Content sich ansammelt und neue Features unerwartete URL-Muster einführen. Hier ist ein Monitoring-Framework:

Wöchentliche Monitoring-Checkliste

Metrik Quelle Alarm-Schwellenwert
Tägliche Googlebot-Crawl-Anfragen GSC Crawl-Statistiken 20 %+ Rückgang Woche über Woche
Durchschnittliche Antwortzeit GSC Crawl-Statistiken Über 500 ms an 3+ aufeinanderfolgenden Tagen
Anzahl „Entdeckt — nicht indexiert” GSC Abdeckung Wachsend seit 2+ aufeinanderfolgenden Wochen
5xx-Fehlerrate Serverprotokolle / Uptime-Monitor Über 1 % der Gesamtanfragen
Indexierungsgeschwindigkeit neuer Seiten GSC URL-Prüfung (Stichprobe) Dauert konstant länger als 7 Tage
Crawl-to-Index-Ratio Log-Files + GSC Unter 70 %

Automatisierte Alerts

Richten Sie automatisiertes Monitoring ein mit:

  • GSC API + Google Sheets/Looker Studio — Crawl-Statistiken täglich abrufen und E-Mail-Alerts bei Schwellenwertüberschreitungen auslösen
  • Server-Monitoring (Datadog, New Relic, UptimeRobot) — TTFB und 5xx-Raten mit Alerting überwachen
  • Geplante Screaming-Frog-Crawls — wöchentliche Crawls, die URL-Anzahlen vergleichen und neue Redirect-Ketten, verwaiste Seiten oder doppelte Inhalte markieren

Praxisbeispiel: ROI einer Crawl-Budget-Optimierung

So sieht Crawl-Budget-Optimierung in der Praxis aus. Ein mittelgroßer E-Commerce-Kunde mit 85.000 Produktseiten erlebte massive Indexierungsverzögerungen — neue Produkte brauchten 3–4 Wochen, um in den Suchergebnissen zu erscheinen.

Was wir festgestellt haben

  • 45 % der täglichen Crawl-Anfragen gingen an facettierte Navigations-URLs ohne Indexierungswert
  • 12 % gingen an Redirect-Ketten, die von einer Migration 18 Monate zuvor übriggeblieben waren
  • 8 % gingen an Session-ID-Parameter-URLs
  • Nur 35 % des Crawl-Budgets erreichten tatsächliche Produkt- und Kategorieseiten

Was wir behoben haben (in Prioritätsreihenfolge)

  1. Facettierte Navigationsmuster per robots.txt blockiert und interne Links zu Filterkombinationen entfernt
  2. Alle Redirect-Ketten zu direkten 301-Weiterleitungen bereinigt
  3. Session-Tracking von URLs auf Cookies umgestellt
  4. XML-Sitemaps bereinigt, sodass nur indexierbare, kanonische URLs enthalten sind
  5. Serverantwortzeit von durchschnittlich 650 ms auf 180 ms TTFB verbessert

Ergebnisse nach 90 Tagen

Metrik Vorher Nachher Veränderung
Crawl-Budget für wertvolle Seiten 35 % 88 % +151 %
Indexierungsgeschwindigkeit neuer Seiten 3–4 Wochen 2–3 Tage ~10× schneller
„Entdeckt — nicht indexiert”-URLs 23.000 4.200 −82 %
Indexierte Produktseiten 52.000/85.000 78.000/85.000 +50 %

Der Compounding-Effekt: 26.000 zusätzliche Seiten im Google-Index → mehr Long-Tail-Keyword-Abdeckung → signifikanter Anstieg von organischem Traffic und Umsatz im ersten Quartal.

Starten Sie noch heute mit der Crawl-Budget-Optimierung

Crawl-Budget-Optimierung ist nicht glamourös, aber für große Websites ist sie das technische Fundament, das jede andere SEO-Investition wirksam macht. Ohne sie arbeiten Ihre Content-Strategie, Ihr Linkaufbau und Ihre On-Page-Optimierung mit einem Handicap.

Die Prioritätsreihenfolge ist klar: Zuerst Serverfehler beheben, dann doppelte URL-Varianten eliminieren, Redirect-Ketten bereinigen und erst danach zu fortgeschrittenen Taktiken wie Edge SEO und AI-Crawler-Management übergehen. Starten Sie mit Ihrem Crawl-Statistik-Bericht in der Google Search Console — das dauert fünf Minuten und zeigt Ihnen, ob dies ein lohnendes Problem für Ihre Website ist.

Brauchen Sie Expertenhilfe bei Ihrem Crawl-Budget?

Unser Technical-SEO-Team hat Crawl-Budgets für E-Commerce-Kataloge, SaaS-Plattformen und Enterprise-Websites optimiert. Lassen Sie uns Ihre Website auditieren und eine Crawl-Optimierungs-Roadmap erstellen.

Crawl-Budget-Audit anfordern →

Antwort innerhalb von 24 Stunden · Keine Verpflichtung

Häufig gestellte Fragen

Spart noindex Crawl-Budget?

Nein. Google crawlt noindex-Seiten trotzdem — es verwirft sie erst nach dem Abruf aus dem Index. Wenn Sie verhindern möchten, dass Googlebot eine Seite überhaupt crawlt, nutzen Sie robots.txt Disallow. Verwenden Sie noindex nur, wenn eine Seite crawlbar sein muss (z. B. zur Weitergabe von Link-Equity), aber nicht in den Suchergebnissen erscheinen soll.

Erhöht ein CDN das Crawl-Budget?

Indirekt ja. Ein CDN reduziert die Serverantwortzeit (die Hauptkomponente des Crawl-Kapazitätslimits), was es Googlebot ermöglicht, seine Crawl-Rate zu erhöhen. Ein CDN beeinflusst jedoch nicht direkt die Crawl-Nachfrage — Google entscheidet weiterhin selbst, wie viel es basierend auf dem Content-Wert crawlen möchte.

Wie oft sollte ich Crawl-Budget-Metriken prüfen?

Für Websites mit 10.000+ Seiten: GSC-Crawl-Statistiken wöchentlich prüfen und monatlich ein umfassendes Crawl-Audit durchführen. Für Websites über 100.000 Seiten: automatisiertes tägliches Monitoring mit schwellenwertbasierten Alerts einrichten.

Ist das Crawl-Budget für Google Desktop und Mobile gleich?

Googlebot Desktop und Mobile teilen sich das Gesamtbudget, werden aber in der GSC separat erfasst. Da Google Mobile-First-Indexierung nutzt, erhält der mobile Crawler typischerweise den größeren Anteil. Konzentrieren Sie Ihre Optimierungsmaßnahmen auf die mobile Rendering-Performance.

Kann ich Google bitten, meine Website häufiger zu crawlen?

Sie können einzelne URLs über das URL-Prüftool in der GSC zum Crawlen anfordern, aber es gibt keine Möglichkeit, Ihr gesamtes Crawl-Budget direkt zu erhöhen. Die Verbesserung der Servergeschwindigkeit und Content-Qualität sind die einzigen verlässlichen Hebel.

Sollte ich AI-Crawler blockieren, um mein Crawl-Budget zu schützen?

Komplettes Blockieren ist ein Kompromiss. AI-Crawler, die um Serverressourcen konkurrieren, können Ihr Crawl-Kapazitätslimit senken, aber sie zu blockieren kann Ihre Sichtbarkeit in AI-gestützten Suchtools (ChatGPT, Perplexity, Claude) verringern. Rate-Limiting über CDN-Regeln ist für die meisten Websites der bessere ausgewogene Ansatz.

Klucco