Logdatei-Analyse für das Crawl-Budget bei 50.000-Seiten-Websites

2021 übernahm ich einen Kunden – einen E-Commerce-Einzelhändler aus Birmingham mit etwa 52.000 indexierten URLs – der nicht herausfinden konnte, warum rund 18.000 seiner Produktseiten über drei Monate lang nicht gecrawlt worden waren. Sein Dev-Team hatte geraten. XML-Sitemaps hinzugefügt. Google Search Console gepingt. Nichts funktionierte. Dann zog ich die rohen Server-Logs heran und nach etwa vierzig Minuten war die Antwort völlig offensichtlich: Googlebot verschleuderte sein tägliches Crawl-Budget auf paginierte Filter-URLs, Session-Parameter und eine fehlerhafte interne Such-Facette, die etwa 4.000 eindeutige, aber nutzlose URLs pro Woche generierte. Totale Verschwendung. Vollständiger 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.Server logs show exactly which pages Googlebot actually reads on a 50,000-page site; log analysis is the only ground truth for crawl-budget decisions.

Genau dafür ist Log-Datei-Analyse eigentlich da – nicht für Eitelkeitsmetriken, nicht für Vorstandspräsentationen, sondern um herauszufinden, was ein Crawler an irgendeinem beliebigen Dienstag auf deiner Website tut, und das Überflüssige rücksichtslos zu streichen.

Warum das Crawl-Budget bei großen Websites wirklich wichtig ist

Das ist das, was die meisten Leute falsch verstehen. Crawl-Budget ist für eine 200-Seiten-Broschüren-Website kein Problem. Googlebot erledigt das in Minuten. Aber wenn du erst mal über etwa 20.000 URLs hinaus bist – und definitiv wenn du bei 50.000 oder mehr bist – trifft Googles Crawler explizite Entscheidungen darüber, was Priorität hat. Googles eigene Dokumentation nennt das „Crawl-Budget" und teilt es in zwei Komponenten auf: Crawl-Rate-Limit (wie schnell Googlebot crawlt, ohne deinen Server zu überlasten) und Crawl-Demand (wie viel Google basierend auf Popularitäts- und Aktualitätssignalen tatsächlich crawlen möchte).Google's own documentation calls this "crawl budget" and breaks it down into two components: crawl rate limit (how fast Googlebot crawls without hammering your server) and crawl demand (how much Google actually wants to crawl based on popularity and freshness signals).

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. Das ist ein guter Anfang. Aber die Daten sind aggregiert, verzögert, und sie zeigen dir nicht, welche spezifischen URLs das Budget aufbrauchen. Server Logs tun das. Sie zeigen dir jeden einzelnen Request, den Googlebot gemacht hat — zu welcher URL, zu welchem Zeitpunkt und welchen HTTP-Statuscode er zurückbekommen hat. Das ist das Rohmaterial.which specific URLs are eating the budget. Server logs do. They show you every single request Googlebot made, to which URL, at what time, and what HTTP status code it received back. That's the raw material.

Die Logs beschaffen

Klingt offensichtlich, aber hier bleiben die meisten stecken. Je nach Hosting-Setup liegen Logs an verschiedenen Orten.

Bei einem verwalteten WordPress-Host wie WP Engine oder Kinsta kannst du rohe Access-Logs vom Dashboard oder per SFTP abrufen – schau im /logs/-Verzeichnis. Bei einem VPS mit Nginx befindet sich dein Access-Log normalerweise unter /var/log/nginx/access.log. Apache legt ihn unter /var/log/apache2/access.log ab. Wenn du auf einem CDN wie Cloudflare bist, brauchst du Cloudflare Logpush (Enterprise-Stufe) oder du siehst nur CDN-Edge-Anfragen, nicht Origin – wichtiger Unterschied.WordPress host like WP Engine or Kinsta, you can pull raw access logs from the dashboard or via SFTP -- look in the/logs/directory. On a VPS running Nginx, your access log is typically at/var/log/nginx/access.log. Apache puts it at/var/log/apache2/access.log. If you're on a CDN like Cloudflare, you'll need Cloudflare Logpush (enterprise tier) or you'll only see CDN-edge requests, not origin -- important distinction.

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..gz files. That's a normal size for a busy 50K-page site.

Raw-Logs parsen ohne den Verstand zu verlieren

Hier hast du zwei echte Optionen:

1. Screaming Frog Log File Analyser – Das verwende ich 90 % der Zeit. Du importierst die Log-Dateien direkt, filterst nach dem Googlebot-User-Agent und erhältst eine sortierbare Übersicht crawlter URLs, Crawl-Häufigkeit, Status-Codes und Antwortzeiten. Ehrlich gesagt, für die meiste Agenturarbeit ist das das richtige Werkzeug. Screaming Frogs Log-Analyser verarbeitet Dateien bis zu mehreren GB ohne abzustürzen, was zählt. -- This is what I use 90% of the time. You import the log files directly, filter by Googlebot user agent, and it gives you a sortable breakdown of crawled URLs, crawl frequency, status codes, and response times. Honestly, for most agency work it's the right tool.Screaming Frog's log analyser handles files up to several GB without falling over, which matters.
2. ELK Stack (Elasticsearch, Logstash, Kibana) – Mehr Setup, bedeutend mehr Power. Wenn du laufende Überwachungsanforderungen für einen großen Kunden oder einen Enterprise-Vertrag hast, lohnt sich die Investition. Seahawk hat ein paar Kunden, bei denen wir Logs direkt in ein Kibana-Dashboard leiten. Echtzeit, schön aussehend, und du kannst Alerts setzen, wenn die Googlebot-Crawl-Häufigkeit plötzlich sinkt. -- More setup, significantly more power. If you've got ongoing monitoring needs for a large client or an enterprise contract, this is worth the investment. Seahawk has a couple of clients where we pipe logs directly into a Kibana dashboard. Real-time, beautiful, and you can set alerts when Googlebot crawl frequency drops suddenly.

Für ein einmaliges Audit reicht der Screaming Frog Log File Analyser. Für alles Fortlaufende baue den ELK Stack auf oder erwäge zumindest GoAccess – es ist Open Source, läuft im Terminal und verarbeitet große Log-Dateien schneller als fast alles andere, das ich getestet habe.GoAccess -- it's open source, runs in the terminal, and processes large log files faster than almost anything else I've tested.

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 angesteuert hat. Du wirst fast immer eine bimodale Verteilung finden. Ein Cluster wichtiger URLs, die häufig gecrawlt werden (gut) und ein langer Schwanz von Müll-URLs, die auch häufig gecrawlt werden (sehr schlecht). Dieser Müll-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.?colour=red&size=M&sort=price_asc more often than it was visiting the actual category pages. Wild.

Status-Code-Übersicht

Filtere alles heraus, das keine 200 ist. Besonders:

• 404s werden wiederholt gecrawlt – Das ist eine Crawl-Budget-Verschwendung. Beheben Sie das mit 301-Redirects oder reparieren Sie die internen Links, die auf sie verweisen. -- These are a crawl budget haemorrhage. Fix them with 301 redirects or patch the internal links that point to them.
• 301-Ketten – Ein Redirect, der A → B → C läuft, sind zwei verschwendete Hops. Googlebot folgt ihnen, aber es kostet Budget und PageRank geht bei jedem Sprung verloren. -- A redirect that goes A → B → C is two wasted hops. Googlebot follows them but it costs budget and PageRank leaks at each jump.
• 500-Fehler – Wenn Googlebot auf Seiten trifft, die 500er zurückgeben, und sie dann erneut versucht, verschwenden Sie Budget UND beschädigen Ihre Crawlability-Score bei Google über Zeit. -- If Googlebot is hitting pages that return 500s and then retrying them, you're wasting budget AND damaging your crawlability score with Google over time.
• 304 Not Modified – Eigentlich in Ordnung. Bedeutet, dass Google die Aktualität prüft und Ihre Caching-Header funktionieren richtig. -- Actually fine. Means Google is checking freshness and your caching headers are working correctly.

Spitzen bei der Antwortzeit

Google hat öffentlich gesagt, dass langsame Server-Antwortzeiten Googlebot dazu bringen, weniger aggressiv zu crawlen. Wenn Ihre Logs durchschnittliche Antwortzeiten über 500 ms für gecrawlte URLs zeigen – besonders für Kategorie- oder Produktseiten – ist das ein Signal, Ihr Server-seitiges Caching zu beheben, bevor Sie alles andere tun. that slow server response times cause Googlebot to crawl less aggressively. If your logs show average response times above 500ms for crawled URLs -- particularly category or product pages -- that's a signal to fix your server-side caching before anything else.

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:

1. Facettierte Navigation ohne noindex oder disallow – Filter, Farbwähler, Größenselektoren, Sortierreihenfolgen. Diese multiplizieren Ihre URL-Anzahl exponentiell. Eine Produktkategorie mit 10 Filteroptionen und 5 Sortierreihenfolgen generiert 50+ doppelte URL-Varianten. Über eine 50.000-Seiten-Website hinweg sind das möglicherweise hunderttausende URLs. -- Filters, colour pickers, size selectors, sort orders. These multiply your URL count geometrically. A product category with 10 filter options and 5 sort orders generates 50+ duplicate URL variants. Across a 50K-page site, that's potentially hundreds of thousands of URLs.
2. Paginierten Archive ohne Limit gecrawlt – /page/2, /page/3.../page/847. Wenn der Inhalt auf Seite 200 Ihres Blog-Archivs keinen organischen Suchwert hat, müssen Sie entweder noindex setzen oder den Paginierungspfad in robots.txt disallow. -- /page/2,/page/3.../page/847. If the content on page 200 of your blog archive has zero organic search value, you need to either noindex it or disallow the pagination path in robots.txt.
3. Session-IDs in URLs – Alte CMS-Plattformen (und einige Legacy-WooCommerce-Setups) hängen Session-Token wie ?sessionid=abc123def456 an URLs an. Jede Session generiert eine eindeutige URL. Googlebot crawlt alle. Das ist ein katastrophales Budget-Leck auf älteren Websites. -- Old CMS platforms (and some legacy WooCommerce setups) append session tokens like?sessionid=abc123def456 to URLs. Every session generates a unique URL. Googlebot crawls all of them. This is a catastrophic budget leak on older sites.
4. Duplizierter Inhalt via URL-Parameter – ?utm_source=email in internen Links, Tracking-Parameter, die in crawlbare URLs lecken, ?ref=homepage von Affiliate-Plugins angehängt. Beheben Sie das in Google Search Console's URL-Parameter-Tool und canonicalizeieren Sie auf HTML-Ebene. -- ?utm_source=email in internal links, tracking parameters leaking into crawlable URLs,?ref=homepage appended by affiliate plugins. Fix in Google Search Console's URL parameter tool and canonicalise at the HTML level.
5. Verwaiste Seiten ohne interne Links, aber noch in der Sitemap – Googlebot findet sie via Sitemap, crawlt sie, findet kein internes Signal, priorisiert sie über Zeit herab. Aber sie verbrauchen dennoch Budget bei Discovery-Crawls. -- Googlebot finds them via sitemap, crawls them, finds no internal signal, deprioritises them over time. But they still eat budget on discovery crawls.
6. Soft-404-Seiten, die den Status 200 zurückgeben – Suchseiten ohne Ergebnisse, leere Kategorieseiten, Benutzerprofilseiten gelöschter Konten. Google verschwendet Zeit damit, diese zu crawlen, und indexiert sie manchmal. -- Search pages with no results, empty category pages, user profile pages for deleted accounts. Google wastes time crawling these and sometimes indexes them.

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 niemals gecrawlt werden sollten – Session-Parameter, Filterkombinationen, interne Such-URLs. Ich nutze Disallow: /*?sessionid=style Wildcard-Regeln. Teste jede Regel in Google Search Console's robots.txt-Tester, bevor du sie einsetzt. for URL patterns that should never be crawled -- session parameters, filter combinations, internal search result URLs. I use Disallow: /*?sessionid=style wildcard rules. Test every rule in Google Search Console's robots.txt tester before deploying.
• 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. on paginated pages beyond page 2 or 3, depending on content freshness. Don't disallow pagination entirely or you break Googlebot's ability to discover linked content.
• Canonical Tags auf allen parametrisierten URL-Varianten, die auf die saubere kanonische URL zeigen. Das ist zusätzliche Absicherung neben robots.txt. on all parameterised URL variants pointing to the clean canonical URL. This is belt-and-braces alongside robots.txt.
• 404er an der Quelle beheben – Entweder aktualisiere die internen Links oder implementiere 301-Weiterleitungen. Ich nutze Screaming Frog's Haupt-Crawler zusammen mit Log-Daten, um zu finden, welche Seiten auf tote URLs verlinken. -- Either update the internal links or implement 301 redirects. I use Screaming Frog's main crawler alongside the log data to find which pages are linking to dead URLs.
• XML-Sitemap-Hygiene – Entferne jede URL aus deiner Sitemap, die einen Nicht-200-Status zurückgibt, noindexed ist oder eine Weiterleitung darstellt. Deine Sitemap sollte eine kuratierte Liste von Seiten sein, die du indexiert haben möchtest – nichts anderes. -- Remove any URL from your sitemap that returns a non-200, is noindexed, or is a redirect. Your sitemap should be a curated list of pages you want indexed, nothing else.

Seahawk hatte letztes Jahr einen Fintech-Client – etwa 65.000 Seiten, größtenteils dynamische Inhalte – wo allein die Behebung der robots.txt zum Blockieren von internen Such-URL-Mustern Googlebots Crawl von Junk-URLs um 61% innerhalb von sechs Wochen reduzierte. Die restlichen 39% des Crawl-Budgets verschoben sich zu Produkt- und Kategorieseiten. Die Indexierung neuer Inhalte sank von durchschnittlich 23 Tagen auf 6 Tage. Das ist die reale Auswirkung.

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?

Ich würde mindestens empfehlen, Logs monatlich zu ziehen und zu analysieren für Seiten über 30.000 Seiten. Schau dir den Crawl-Häufigkeitstrend für deine Top 100 umsatzgenerierenden URLs an. Wenn Googlebots Besuchshäufigkeit auf 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. Vollständige Indexierung heute bedeutet nicht, dass sie so bleibt. Wenn du regelmäßig neue Inhalte veröffentlichst – neue Produkte, neue Blog-Beiträge, neue Landing Pages – bestimmt das Crawl-Budget, wie schnell diese frischen Inhalte gefunden werden. Eine Seite mit einem löchrigen Crawl-Budget kann neue Seiten wochenlang ungeprüft liegen 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 speziellen Fällen. Admin-Bereiche, Staging-Pfade, interne Suchergebnisse und Parameter-lastige Filter-URLs sind alle angemessene Kandidaten für Disallow-Regeln. Das eine, wovor ich dich warnen würde, ist das Blockieren von JavaScript- oder CSS-Dateien – Googlebot braucht diese, um deine Seiten korrekt zu rendern. Viele ältere SEO-Ratschläge sagen, 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üben – die meisten verwalteten Hosts haben das verfügbar, auch wenn es im Dashboard nicht prominent angezeigt wird. Falls du wirklich keine Raw-Logs bekommst, kann Cloudflare's Bot-Analytik dir für Seiten hinter dem Cloudflare-Proxy ein teilweises Bild geben, obwohl es ein schlechter Ersatz für echte Log-Daten ist. Erwäge einen Hosting-Wechsel, wenn das bei einem großen Client-Konto ein wiederkehrendes Problem ist.Cloudflare's bot analytics can give you a partial picture for sites behind the Cloudflare proxy, though it's a pale substitute for real log data. Consider switching hosts if this is a recurring blocker on a large client account.

Reichen die Crawl-Statistiken der Google Search Console aus?

Bei einer kleinen Seite, wohl ja. Bei allem über 20.000 Seiten, nein. GSC Crawl-Statistiken sind pro Tag aggregiert und zeigen keine URL-Ebenen-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.which 12,000 pages. Log files give you that resolution. Both tools together -- that's the complete picture.

---

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.