Crawl-Budget: Praxisleitfaden für große Plattformen

Das Crawl-Budget ist die Anzahl der Seiten, die der Googlebot innerhalb eines bestimmten Zeitraums auf Ihrer Website crawlen will. Auf kleinen Websites ist es praktisch unbegrenzt. Auf Plattformen mit Millionen URLs wird es zu einer strategischen Ressource: Der Bot verbraucht es für Filter, Paginierung, leere Templates und Staging-Seiten, statt priorisierte Inhalte zu crawlen. Die Folgen sind eine verzögerte Indexierung neuer Produkte, eine lückenhafte Abdeckung des Katalogs und verlorene Rankings.

zoom_in

Schritt 1: Crawler-Logs erfassen und auswerten

Die Server-Logs des Webservers sind die wichtigste Quelle, um zu sehen, was der Googlebot tatsächlich crawlt. Sie zeigen die reale Anfragehäufigkeit, die Bereiche, die der Bot ignoriert oder an denen er hängen bleibt, und die HTTP-Antworten des Servers. Ohne Logs ist jede Optimierung Raterei.

Googlebot-Anfragen aus Nginx und Apache extrahieren

# Filter only Googlebot requests from the last 7 days
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn \
  | head -50

# HTTP status codes seen by Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# Top URLs returning 404 to Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '$9 == "404" {print $7}' \
  | sort | uniq -c | sort -rn | head -30

Für die strukturierte Analyse großer Logmengen eignen sich spezialisierte Werkzeuge: Screaming Frog Log File Analyser, der Semrush Log Analyser oder ein ELK-Stack (Elasticsearch + Kibana). Sie gruppieren URLs automatisch nach Mustern und zeichnen die Crawling-Rate über die Zeit auf.

Schritt 2: Google Search Console und Analyse der Serverantworten

Die Google Search Console liefert aggregierte Crawling-Daten, auch ohne Zugriff auf die Server-Logs. Der Bericht Crawling-Statistiken ist der wichtigste Einstieg. Er zeigt die durchschnittliche Zahl der Anfragen pro Tag, die wahrgenommene Ladezeit der Seiten und die Verteilung der Statuscodes.

• GSC → Einstellungen → Crawling-Statistiken: Diagramm der Crawling-Anfragen, aufgeschlüsselt nach Dateityp und Statuscode. Achten Sie auf Spitzen bei 404/500 und auf Einbrüche nach Deployments.
• GSC → Indexierung → Seiten: Zahl der indexierten URLs im Vergleich zu den Gründen für fehlende Indexierung. „Gefunden – zurzeit nicht indexiert“ ist ein direktes Signal für das Crawl-Budget.
• GSC → URL-Prüfung: manuelle Statusprüfung einer bestimmten Seite: wann sie zuletzt gecrawlt wurde und was der Googlebot gesehen hat.
• GSC → Einstellungen → Crawling-Rate: Sie können die Crawling-Rate drosseln, wenn der Bot den Server überlastet. Meist ist das nicht nötig; begrenzen Sie nur bei messbaren Performance-Problemen.

Quellen der Crawl-Budget-Verschwendung

Auf einer großen Plattform verliert der Bot Budget an sechs typischen Quellen. Identifizieren Sie jede davon in Ihren Logs und schätzen Sie den Umfang. So ergibt sich die Reihenfolge der Optimierung.

zoom_in

URL-Parameter und Duplikate: Maßnahmen

Parametrische URLs sind die größte Quelle der Verschwendung auf E-Commerce-Plattformen. Es gibt keine universelle Lösung. Die richtige Maßnahme hängt von der Art des Parameters ab.

# robots.txt — blocking parametric URLs
User-agent: *

# Sort and filter parameters
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /*?filter=
Disallow: /*?color=
Disallow: /*?size=

# Pagination deeper than page 3 (Allow/Disallow approach)
Disallow: /*?page=
Allow: /*?page=1
Allow: /*?page=2
Allow: /*?page=3

# Session and tracking parameters
Disallow: /*?sessionid=
Disallow: /*?token=
Disallow: /*?ref=
Disallow: /*?utm_

# Preview and drafts
Disallow: /*?preview=
Disallow: /*?draft=

Filter, Facetten und Paginierung

Die Facettennavigation ist der komplexeste Fall. Sie erzeugt eine kombinatorische Explosion von URLs: 10 Filter mit je 5 Werten können über eine Million Kombinationen ergeben. Ziel ist, wertvolle Facetten (z. B. Marke und Kategorie) zu erhalten und nutzlose Kombinationen zu blockieren.

1. Wertvolle Facetten identifizieren: Seiten mit hohem organischem Traffic oder eigenem SEO-Inhalt (z. B. /catalog/nike/ mit markenspezifischem Text) bleiben im Index, mit einem Canonical auf sich selbst.
2. noindex + follow für geringwertige Kombinationen setzen: Die Seite wird gerendert (Links werden verfolgt), gelangt aber nicht in den Index. Verwenden Sie <meta name="robots" content="noindex, follow"> im Template, sobald mehr als eine Facette aktiv ist.
3. Rein technische Parameter per Disallow sperren: Sortierung, Farbe und Größe blockieren Sie über die robots.txt, sofern sie keinen SEO-Wert haben.
4. AJAX-geladene Facetten: Werden Facetten per JavaScript geladen und nicht in der URL abgebildet, sieht der Bot keine zusätzlichen URLs. Damit ist das Problem auf Architekturebene gelöst.

Paginierung: Canonical oder Disallow?

Die optimale Paginierungsstrategie hängt vom Umfang ab: Bei bis zu 10 Seiten lassen Sie das Crawling zu und setzen auf Seite 2 und folgenden ein Canonical auf Seite 1. Bei Hunderten Paginierungsseiten sperren Sie alles ab Seite 3–5 per Disallow. Infinite Scroll ohne URL-Parameter behandelt der Bot als eine einzige Seite. Das ist gut für das Budget.

Temporäre Seiten: Webinare, Mockups, Demos

Temporäre Seiten sind ein verborgener Budgetfresser auf Plattformen mit aktiven Marketingteams. Landingpages für Webinare, Demo-Mockups, Vorschauseiten für Kunden und Varianten von A/B-Tests erscheinen schnell und bleiben oft für immer bestehen. Dabei verbrauchen sie still das Crawl-Budget.

• meta robots noindex: Fügen Sie <meta name="robots" content="noindex, nofollow"> im Template aller temporären Seiten ein. Der Bot besucht die Seite, liest die Anweisung und nimmt die URL aus dem Index. Das ist die einfachste Methode, wenn Sie Zugriff auf das Template haben.
• X-Robots-Tag im HTTP-Header: Haben temporäre Seiten kein eigenes HTML-Template (z. B. erzeugte PDFs oder Dateien), verwenden Sie den HTTP-Antwort-Header: X-Robots-Tag: noindex, nofollow.
• Disallow nach Pfadpräfix: Liegen temporäre Seiten unter vorhersehbaren Pfadpräfixen, sperren Sie diese in der robots.txt. Eine bereits indexierte URL wird dadurch nicht sicher entfernt, neue URLs werden aber nicht mehr gecrawlt.
• HTTP-Authentifizierung: Für Staging- und Vorschauseiten ist das die einzige zuverlässige Methode zur vollständigen Abschottung. Der Googlebot hat keine Zugangsdaten und crawlt die Seite nicht.

# robots.txt — patterns for temporary pages
User-agent: *

# Webinars and events
Disallow: /webinars/
Disallow: /events/draft-
Disallow: /landing/test-

# Mockups and previews
Disallow: /_preview/
Disallow: /mockups/
Disallow: /demo/

# A/B tests and experiments
Disallow: /*?variant=
Disallow: /*?experiment=
Disallow: /*?ab_test=

# Template preview parameters
Disallow: /*?preview=
Disallow: /*?draft=
Disallow: /*?revision=

Sitemap-Index bei großen Datenmengen

Bei Millionen URLs ist eine einzelne XML-Sitemap unpraktisch: Sie ist auf 50.000 URLs und 50 MB begrenzt. Ein Sitemap-Index ist eine Inhaltsübersicht, die auf untergeordnete Sitemaps verweist. So strukturieren Sie Prioritäten und lenken das Budget dorthin, wo es am meisten gebraucht wird.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!-- Priority sections — crawled first -->
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-categories.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <!-- Lower-priority sections -->
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-05-10</lastmod>
  </sitemap>
  <!-- Do NOT include noindex pages or duplicates! -->
</sitemapindex>

• Sitemaps nach Inhaltstyp aufteilen: Produkte, Kategorien, Blog und statische Seiten jeweils in einer eigenen Datei. So sehen Sie die Indexierungsstatistik je Bereich in der GSC.
• lastmod ehrlich pflegen: lastmod signalisiert dem Bot, wie aktuell ein Inhalt ist. Tragen Sie das Datum der letzten echten Änderung ein, nicht das heutige Datum. Sonst vertraut der Bot diesem Signal nicht mehr.
• Gesperrte URLs ausschließen: Seiten mit noindex oder Disallow dürfen nicht in der Sitemap stehen. Sonst senden Sie dem Bot widersprüchliche Signale.
• Limit untergeordneter Sitemaps: Jede untergeordnete Datei umfasst höchstens 50.000 URLs oder 50 MB (komprimiert). Bei Überschreitung teilen Sie sie auf, z. B. in sitemap-products-1.xml und sitemap-products-2.xml.

Serverkonfiguration und Rate Limiting

Der Server beeinflusst das Crawl-Budget in beide Richtungen: Langsame Antworten zwingen den Googlebot, die Crawling-Intensität zu senken, während 5xx-Fehler den Bot warten lassen und Zeit für Wiederholungen verschwenden. Eine Serveroptimierung verbessert die Crawling-Effizienz unmittelbar.

# Nginx: return 429 when any crawler sends too many requests
limit_req_zone $http_user_agent zone=crawlers:10m rate=10r/s;

location / {
    limit_req zone=crawlers burst=20 nodelay;
    limit_req_status 429;
    # ... other settings
}

KPIs und Monitoring

Das Crawl-Budget braucht laufendes Monitoring: Jedes Deployment kann versehentlich Tausende neue parametrische URLs freigeben. Richten Sie ein wöchentliches Dashboard ein und überprüfen Sie die folgenden Kennzahlen einmal im Monat.

• Wöchentlich: Vergleichen Sie die Crawling-Anfragen in der GSC für die aktuelle und die Vorwoche. Ein plötzlicher Anstieg weist auf neue Duplikate hin, die ein Deployment eingeführt hat.
• Monatlich: Prüfen Sie in der GSC unter „Seiten“ die Angabe „Gefunden – zurzeit nicht indexiert“. Wächst diese Zahl bei unveränderter Größe der Website, liegt ein Problem mit dem Crawl-Budget vor.
• Nach jedem größeren Deployment: Crawlen Sie die Website mit Screaming Frog und prüfen Sie die Zahl eindeutiger URLs. Vergleichen Sie sie mit dem vorherigen Stand.
• Vierteljährlich: vollständige Logfile-Analyse über 30 Tage. Suchen Sie nach neuen Mustern parametrischer URLs, die der aktualisierte Code erzeugt.
• Warnungen: Richten Sie eine Benachrichtigung ein, wenn 5xx-Antworten an einem Tag mehr als 1 % aller Googlebot-Anfragen ausmachen.

Quick Wins und Roadmap

Die Optimierung des Crawl-Budgets ist keine einmalige Aufgabe, sondern ein Prozess. Teilen Sie die Arbeit in schnelle Maßnahmen (Wirkung nach 1–2 Wochen) und systemische Änderungen (1–3 Monate) auf.

Checkliste für Quick Wins

• noindex in alle Templates für temporäre Seiten (Webinare, Mockups, Demos) eingefügt
• Disallow für ?preview=, ?draft=, ?sessionid= und ?utm_ in der robots.txt
• Canonical auf saubere URLs auf allen parametrischen Seiten (Sortierung, Paginierung ab Seite 2)
• noindex- und Disallow-Seiten aus der Sitemap entfernt
• Sitemap-Index nach Bereichen aufgeteilt, mit korrektem lastmod
• Weiterleitungsketten auf einen einzigen Sprung reduziert
• 404 in den Googlebot-Logs unter 5 % – defekte Links entfernt
• Wöchentliches Monitoring-Dashboard in der GSC eingerichtet

FAQ