2021 übernahm ich einen Kunden, einen E-Commerce-Händler in Birmingham mit etwa 52.000 indizierten URLs, der nicht herausfinden konnte, warum rund 18.000 seiner Produktseiten über drei Monate hinweg nicht gecrawlt worden waren. Sein Dev-Team hatte geraten. XML-Sitemaps hinzugefügt. Google Search Console gepingt. Nichts funktionierte. Dann zog ich die Raw-Server-Logs und innerhalb von etwa vierzig Minuten war die Antwort völlig offensichtlich: Googlebot verbrauchte sein tägliches Crawl-Budget auf paginierte Filter-URLs, Session-Parameter und eine fehlerhafte interne Such-Facette, die etwa 4.000 einzigartige, aber nutzlose URLs pro Woche generierte. Totale Verschwendung. Kompletter Unsinn.
Wichtigste Erkenntnis: Server-Logs zeigen genau, welche Seiten Googlebot auf einer 50.000-Seiten-Website wirklich liest; Log-Analyse ist die einzige Quelle der Wahrheit für Crawl-Budget-Entscheidungen.
Das ist wirklich der Zweck der Log-Datei-Analyse, nicht Eitelkeitskennzahlen, nicht Präsentationen für den Vorstand, sondern herauszufinden, was ein Crawler an einem bestimmten Dienstag auf deiner Website macht und unerbittlich das Fett abzuschneiden.
Warum das Crawl-Budget bei großen Websites wirklich wichtig ist
Hier ist das, was die meisten Menschen falsch verstehen. Crawl-Budget ist kein Problem für eine 200-Seiten-Broschüren-Website. Googlebot wird das in Minuten erledigen. Aber sobald du über etwa 20.000 URLs hinausgehst, und definitiv wenn du bei 50.000 oder darüber bist, trifft Googles Crawler explizite Entscheidungen darüber, was priorisiert wird. Googles eigene Dokumentation nennt das „Crawl Budget" und unterteilt es in zwei Komponenten: Crawl-Ratengrenzwert (wie schnell Googlebot crawlt, ohne deinen Server zu überlasten) und Crawl-Nachfrage (wie sehr Google tatsächlich basierend auf Beliebtheit und Frische-Signalen crawlen möchte).
Beides lässt sich manipulieren. Aber du kannst nicht manipulieren, was du nicht messen kannst. Und du kannst es ohne die Protokolle nicht richtig messen.
Analytics-Tools wie Google Search Console geben dir einen Crawl-Stats-Report. Ein guter Anfang. Aber die Daten sind aggregiert und zeitverzögert, und sie zeigen dir nicht, welche spezifischen URLs dein Budget aufzehren. Server Logs dagegen schon. Sie dokumentieren jeden einzelnen Request von Googlebot: welche URL, wann und welcher HTTP-Statuscode zurückkam. Das Rohmaterial eben.
Die Logs beschaffen
Klingt offensichtlich, aber hier bleiben die meisten stecken. Je nach Hosting-Setup liegen Logs an verschiedenen Orten.
Auf einem verwalteten WordPress-Host wie WP Engine oder Kinsta kannst du Raw-Access-Logs aus dem Dashboard oder über SFTP abrufen und im /logs/-Verzeichnis nachschauen. Auf einem VPS mit Nginx befindet sich dein Access-Log typischerweise unter /var/log/nginx/access.log. Apache legt es unter /var/log/apache2/access.log ab. Wenn du auf einem CDN wie Cloudflare bist, benötigst du Cloudflare Logpush (Enterprise-Tier) oder du siehst nur CDN-Edge-Anfragen, nicht Origin – wichtiger Unterschied.
Für meinen Birmingham-Kunden liefen die Server auf Kinsta. Ich habe 30 Tage Logs gezogen, das waren etwa 4,2 GB komprimierte .gz-Dateien. Das ist eine normale Größe für eine aktive 50K-Seiten-Website.
Raw-Logs parsen ohne den Verstand zu verlieren
Hier hast du zwei echte Optionen:
- Screaming Frog Log File Analyser, Das verwende ich 90 % der Zeit. Du importierst die Log-Dateien direkt, filterst nach dem Googlebot User-Agent, und es liefert dir eine sortierbare Übersicht der gecrawlten URLs, Crawl-Häufigkeit, Status-Codes und Antwortzeiten. Ehrlich gesagt ist es für die meisten Agentur-Arbeiten das richtige Tool. Screaming Frogs Log-Analyser verarbeitet Dateien bis zu mehreren GB, ohne zusammenzubrechen – das ist wichtig.
- ELK Stack (Elasticsearch, Logstash, Kibana), Mehr Setup, deutlich mehr Leistung. Wenn du für einen großen Kunden oder einen Enterprise-Vertrag laufende Überwachung brauchst, lohnt sich diese Investition. Seahawk hat ein paar Kunden, bei denen wir Logs direkt in ein Kibana-Dashboard pipen. Echtzeit, wunderschön, und du kannst Warnungen setzen, wenn die Googlebot-Crawl-Häufigkeit plötzlich sinkt.
Für ein einmaliges Audit reicht Screaming Frog Log File Analyser. Für laufende Aufgaben solltest du den ELK Stack aufbauen oder zumindest GoAccess in Betracht ziehen – es ist Open Source, läuft im Terminal und verarbeitet große Log-Dateien schneller als fast alles andere, das ich getestet habe.
Worauf du wirklich achten solltest
Sobald die Daten geladen sind, starren die meisten Leute sie an und wissen nicht, welche Fragen sie stellen sollen. Hier ist, worauf ich in einem Log-Audit wirklich achte:
Crawl-Häufigkeitsverteilung
Sortiere deine URLs nach Crawl-Häufigkeit, wie oft Googlebot jede URL im 30-Tage-Fenster erreicht hat. Du wirst fast immer eine bimodale Verteilung finden. Ein Cluster von wichtigen URLs, die häufig gecrawlt werden (gut) und ein langer Schwanz von Junk-URLs, die auch häufig gecrawlt werden (sehr schlecht). Dieser Junk-Schwanz ist dein Problem.
Auf der Birmingham-Website waren in den Top 500 gecrawlten URLs 340 Filter/Facet-Kombinationen. Keine davon waren indexiert. Keine davon hatten Suchvolumen. Googlebot besuchte ?colour=red&size=M&sort=price_asc häufiger als die eigentlichen Kategorieseiten. Verrückt.
Status-Code-Übersicht
Filtere alles heraus, das keine 200 ist. Besonders:
- 404s, die wiederholt gecrawlt werden, Das ist eine Crawl-Budget-Blutung. Behebe sie mit 301-Weiterleitungen oder korrigiere die internen Links, die darauf verweisen.
- 301-Ketten – Eine Umleitung A → B → C verschlingt zwei unnötige Hops. Googlebot folgt ihnen, aber es kostet Budget und PageRank leckt bei jedem Sprung.
- 500-Fehler – Wenn Googlebot auf Seiten trifft, die 500er zurückgeben, und diese dann erneut aufruft, verschwendest du Budget UND beschädigst deine Crawlability-Bewertung bei Google über Zeit.
- 304 Not Modified – Eigentlich in Ordnung. Bedeutet, Google prüft die Aktualität und deine Caching-Header funktionieren korrekt.
Spitzen bei der Antwortzeit
Google hat öffentlich gesagt, dass langsame Server-Response-Zeiten Googlebot dazu bringen, weniger aggressiv zu crawlen. Wenn deine Logs durchschnittliche Response-Zeiten über 500ms für gecrawlte URLs zeigen, besonders bei Kategorie- oder Produktseiten, ist das ein Signal, erst die serverseitige Cachesteuerung zu reparieren.
Die Budget-Killer identifizieren
Ich gebe dir eine Liste der Dinge, die ich auf großen Websites Crawl-Budget aufzehren sehe, ungefähr in der Reihenfolge, wie oft ich ihnen begegne:
- Facettierte Navigation ohne noindex oder disallow – Filter, Farbwähler, Größenselektoren, Sortierreihenfolgen. Diese multiplizieren deine URL-Anzahl geometrisch. Eine Produktkategorie mit 10 Filteroptionen und 5 Sortierreihenfolgen erzeugt 50+ doppelte URL-Varianten. Über eine 50K-Seiten-Website verteilt sind das potenziell hunderttausende URLs.
- Paginierten Archive endlos gecrawlt – /page/2, /page/3 … /page/847. Wenn der Inhalt auf Seite 200 deines Blog-Archivs keinen organischen Suchenwert hat, musst du entweder noindex setzen oder den Paginierungspfad in robots.txt disallowed.
- Session-IDs in URLs – Alte CMS-Plattformen (und manche Legacy-WooCommerce-Setups) hängen Session-Token wie ?sessionid=abc123def456 an URLs an. Jede Session erzeugt eine eindeutige URL. Googlebot crawlt alle davon. Das ist ein katastrophales Budget-Leck auf älteren Seiten.
- Duplikatinhalte über URL-Parameter – ?utm_source=email in internen Links, Tracking-Parameter, die in crawlbare URLs lecken, ?ref=homepage von Affiliate-Plugins angehängt. Repariere in der URL-Parameter-Tools von Google Search Console und nutze Canonicalisation auf HTML-Ebene.
- Verwaiste Seiten ohne interne Links, aber noch in der Sitemap – Googlebot findet sie über die Sitemap, crawlt sie, findet kein internes Signal und stuft sie mit der Zeit herab. Problem: Sie verbrauchen trotzdem noch Crawl-Budget bei Discovery-Crawls.
- Soft-404-Seiten mit 200-Status zurückgegeben – Suchseiten ohne Ergebnisse, leere Kategorieseiten, Benutzerprofil-Seiten für gelöschte Konten. Google verschwendet Zeit beim Crawlen und indexiert sie manchmal.
Behebung der gefundenen Probleme
Ehrlich gesagt ist die Analyse der einfachere Teil. Die Umsetzung ist dort, wo Projekte politisch werden.
So sieht mein tatsächlicher Workflow aus, wenn ich ein Log-Audit abgeschlossen habe und Empfehlungen präsentieren muss:
- Robots.txt Disallow für URL-Muster, die nie gecrawlt werden sollten, Session-Parameter, Filter-Kombinationen, interne Such-Ergebnis-URLs. Ich verwende Disallow: /*?sessionid=style Wildcard-Regeln. Teste jede Regel im robots.txt-Tester der Google Search Console, bevor du sie einsetzt.
- Noindex + nofollow auf paginierten Seiten jenseits von Seite 2 oder 3, je nach Content-Aktualität. Deaktiviere die Paginierung nicht vollständig, sonst beschädigst du Googlebots Fähigkeit, verlinkte Inhalte zu entdecken.
- Canonical Tags auf allen parametrisierten URL-Varianten, die auf die saubere kanonische URL zeigen. Das ist zusätzliche Absicherung neben robots.txt.
- Behebe 404er an der Quelle, entweder aktualisiere die internen Links oder implementiere 301-Weiterleitungen. Ich nutze Screaming Frog's Hauptcrawler zusammen mit den Log-Daten, um herauszufinden, welche Seiten auf tote URLs verlinken.
- XML-Sitemap-Hygiene: Entferne jede URL aus deiner Sitemap, die nicht mit 200 antwortet, noindexiert ist oder eine Weiterleitung darstellt. Deine Sitemap sollte eine kuratierte Liste der Seiten sein, die du indexiert haben möchtest – nichts anderes.
Seahawk hatte letztes Jahr einen Fintech-Kunden mit etwa 65.000 Seiten, überwiegend dynamische Inhalte, wo allein die Korrektur der robots.txt zur Blockierung interner Such-URL-Muster Googlebots Crawling von Junk-URLs um 61 % innerhalb von sechs Wochen reduziert hat. Die restlichen 39 % des Crawl-Budgets verschoben sich zu Produkt- und Kategorienseiten. Die Indexierung neuer Inhalte sank von durchschnittlich 23 Tagen auf 6 Tage. Das ist die Auswirkung in der Praxis.
Laufende Überwachung einrichten
Ein Log-Audit ist eine Momentaufnahme. Gutes Crawl-Budget-Management ist ein fortlaufender Prozess. Wie sieht das in der Praxis tatsächlich aus?
Mindestens würde ich empfehlen, monatlich Logs zu ziehen und zu analysieren für jede Website über 30.000 Seiten. Schau dir den Crawl-Häufigkeitstrend für deine Top 100 umsatzgenerierenden URLs an. Falls Googlebots Besuchshäufigkeit bei diesen Seiten sinkt, hat sich etwas geändert – neue Crawl-Budget-Lecks, Server-Performance-Probleme oder ein Rückgang des PageRank-Signals.
Wenn du es anspruchsvoller haben möchtest, richte GoAccess als Cron-Job ein, um tägliche Log-Snapshots zu verarbeiten und dir einen Zusammenfassungsbericht per E-Mail zu senden. Die Konfiguration dauert etwa zwei Stunden und spart dir davor, langsame Crawl-Budget-Erosion zwischen quartalsweisen Audits zu übersehen.
FAQ
Spielt Crawl-Budget eine Rolle, wenn mein Site bereits vollständig indexiert ist?
Gewissermaßen ja. Vollständige Indexierung heute bedeutet nicht, dass es so bleibt. Wenn du regelmäßig neue Inhalte veröffentlichst, neue Produkte, neue Blog-Posts, neue Landing Pages – Crawl-Budget bestimmt, wie schnell dieser frische Content gefunden wird. Eine Website mit leckem Crawl-Budget kann neue Seiten wochenlang ungeprüft herumliegen haben. Das ist ein echter Wettbewerbsnachteil, wenn du in einer schnelllebigen Nische tätig bist.
Sollte ich Googlebot mithilfe von robots.txt komplett von bestimmten Unterordnern blockieren?
Ja, in bestimmten Fällen. Admin-Bereiche, Staging-Pfade, interne Suchergebnisse und parameterreiche Filter-URLs sind alle angemessene Kandidaten für Disallow-Regeln. Das eine, wogegen ich warnen würde: JavaScript oder CSS-Dateien zu blockieren. Googlebot braucht die, um deine Seiten korrekt zu rendern. Ein Großteil älterer SEO-Ratschläge sagt, JS zu blockieren – ignoriere das.
Wie viele Log-Daten sollte ich analysieren?
30 Tage ist der Sweet Spot für die meisten Websites. Weniger als das und du wirst die Low-Frequency-Crawl-Muster nicht sehen. Mehr als das und die Dateigrößen werden unhandlich, es sei denn, du betreibst einen ordentlichen ELK Stack. Für saisonale E-Commerce-Websites schaue ich mir manchmal 60 Tage an, die eine Spitzenperiode umfassen, um das Crawl-Verhalten unter Lastbedingungen zu verstehen.
Was ist, wenn mein Host keinen Raw-Zugriff auf Logs bereitstellt?
Druck auf deinen Hosting-Provider aus – die meisten verwalteten Hosts haben das verfügbar, auch wenn es im Dashboard nicht prominent sichtbar ist. Falls du wirklich keine Raw-Logs bekommen kannst, kann dir Cloudflares Bot-Analytics für Websites hinter dem Cloudflare-Proxy ein Teilbild geben, obwohl es ein schwacher Ersatz für echte Log-Daten ist. Erwäge einen Hostwechsel, wenn das bei einem großen Kundenkonto ein wiederkehrendes Hindernis ist.
Reichen die Crawl-Statistiken der Google Search Console aus?
Für eine kleine Website argumentativ ja. Für alles über 20.000 Seiten: nein. GSC Crawl-Statistiken sind nach Tag aggregiert und zeigen keine URL-Level-Daten. Du kannst sehen, dass Googlebot am Dienstag 12.000 Seiten gecrawlt hat, aber nicht welche 12.000 Seiten. Log-Dateien geben dir diese Auflösung. Beide Tools zusammen – das ist das vollständige Bild.
---
Schau, die meisten SEOs überspringen die Log-Datei-Analyse, weil es sich wie DevOps-Gebiet anfühlt. Es ist nicht glamourös. Du suchst dich durch Gigabytes von Timestamps und User-Agent-Strings. Aber bei großen Websites ist es der Unterschied zwischen dem Raten, wo dein Crawl Budget hingeht, und dem tatsächlichen Wissen. Und Wissen ist meiner Erfahrung nach immer die zwei Stunden wert, die es dauert, die Daten zu ziehen.
Weiterführende Lektüre: KI-gestützte Keyword-Recherche 2026: Was es ist, warum traditionelle, KI-Suche und mehrsprachiges SEO.