Logfile-Analyse

TL;DR — Ihr Webserver protokolliert jede eingehende Anfrage, auch die von Suchmaschinen-Bots wie Googlebot. Bei der Logfile-Analyse lesen Sie dieses Protokoll, um genau zu sehen, welche Seiten Bots tatsächlich wie oft abgerufen haben und ob Fehler auftraten. Nur hier steht, was wirklich geschehen ist – die meisten kleinen Websites benötigen diese Analyse allerdings nicht.

Zum Vergrößern tippen

The four-week chart compares automated and human requests to HTML content. Bot share is higher in the captured worldwide Cloudflare traffic period.

Was ein Logfile ist

Sobald jemand – ein Mensch, Googlebot oder irgendein anderer Bot – eine Seite Ihrer Website anfordert, schreibt der Server eine Zeile in eine Datei. Diese Datei ist das Zugriffsprotokoll. Jede Zeile enthält ungefähr dieselben Angaben:

• wer angefragt hat (IP-Adresse und User-Agent wie Googlebot),
• was angefragt wurde (die URL),
• wann die Anfrage erfolgte (Zeitstempel) und
• welche Antwort zurückkam (HTTP-Statuscode, etwa 200 für OK oder 404 für nicht gefunden).

Über mehrere Wochen entsteht daraus ein vollständiger, unverfälschter Nachweis, wie Suchmaschinen Ihre Website crawlen. Keine Schätzung, sondern die tatsächlichen Anfragen.

Warum sich das Lesen lohnt

Andere SEO-Tools schätzen entweder, wie Bots Ihre Website crawlen – ein Crawl-Tool gibt sich als Suchmaschine aus und folgt den Seiten – oder sie fassen die Aktivität zusammen, wie die stichprobenartige, gerundete Ansicht in der Google Search Console. Ihre Logs zeigen dagegen jede echte Anfrage. Damit beantworten Sie Fragen wie:

• Welche Seiten besucht Googlebot tatsächlich, welche ignoriert er?
• Verschwendet der Bot Zeit mit nutzlosen URLs statt mit wichtigen Seiten?
• Treffen Bots auf defekte Seiten (404) oder Serverfehler (5xx)?
• Gibt es Seiten, die Bots noch nie erreicht haben?

Die unverzichtbare Regel

Jeder kann sich als Googlebot ausgeben. Der User-Agent in einer Logzeile ist nur Text; ein Scraper kann dort Googlebot eintragen, um Schutzmaßnahmen zu umgehen. Bevor Sie auch nur einer „Googlebot“-Zeile vertrauen, müssen Sie daher prüfen, ob die Anfrage wirklich von Google stammt. In den Tabs „Fortgeschritten“ und „Skripte“ finden Sie dafür einen einfachen DNS-Test. Ohne Prüfung ziehen Sie Schlüsse aus gefälschtem Traffic.

Brauchen Sie diese Analyse überhaupt?

Ehrlich gesagt wahrscheinlich nicht, wenn Sie eine kleine Website betreiben. Logfile-Analysen lohnen sich bei großen Websites mit Zehntausenden URLs, Onlineshops mit vielen Filterseiten, laufenden Migrationen oder Seiten, die Google als „gefunden“ meldet, aber nicht indexiert. Hat Ihre Website nur einige Hundert Seiten und werden diese problemlos gecrawlt, ist Ihre Zeit anderswo besser investiert. Wie beim Crawl-Budget müssen sich die meisten Websites darum nicht kümmern.

Möchten Sie den vollständigen Ablauf kennenlernen – Bots korrekt prüfen, Crawl-Verschwendung finden und verwaiste Seiten erkennen? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — Logs sind der ungekürzte Tatsachennachweis für Crawling: jede Anfrage, jeder Bot und jeder Statuscode. Prüfen Sie zuerst Googlebot und Bingbot per Reverse- und Forward-DNS oder anhand von Googles veröffentlichten IP-Bereichen. User-Agents werden ständig gefälscht; berechnen Sie deshalb alles ausschließlich mit dem verifizierten Datensatz. Untersuchen Sie danach häufig und selten gecrawlte URLs und Bereiche, die Crawl-Frequenz, Statuscodes nach Häufigkeit, Crawl-Verschwendung durch Parameter, Facetten, interne Suche und endlose Seitennummerierung, verwaiste beziehungsweise nie gecrawlte Seiten sowie den Mobil-Desktop-Anteil von Googlebot. Bing veröffentlicht offiziell keine IP-Bereiche, daher ist dort DNS zu *.search.msn.com maßgeblich. Logs ergänzen die Crawl-Statistiken der Search Console, ersetzen sie aber nicht. 2026 machen zudem KI-Bots einen erheblichen Anteil der Anfragen aus.

Warum Logs der Tatsachennachweis sind

Es gibt drei Wege, um zu „sehen“, wie Suchmaschinen Ihre Website crawlen. Sie sind nicht gleichwertig:

• Ein Crawl-Tool wie Screaming Frog SEO Spider oder Ahrefs Site Audit simuliert einen Crawl. Es zeigt, was ein Bot finden könnte, nicht was Google tatsächlich abgerufen hat.
• Die GSC-Crawl-Statistiken fassen reale Daten zusammen, sind jedoch stichprobenartig, aggregiert und begrenzt – auf ungefähr 1 000 Zeilen, rund 90 Tage und ohne Export pro URL.
• Server-Logs zeichnen die Realität auf: jede Anfrage jedes Bots mit genauer URL, Zeitstempel und Statuscode.

Der von mir geprüfte Ahrefs-Leitfaden formuliert es klar: Server-Logs sind “the most trustworthy source of information to understand the URLs that search engines have crawled.” (Übersetzung) „die vertrauenswürdigste Informationsquelle, um zu verstehen, welche URLs Suchmaschinen gecrawlt haben“. Genau deshalb gibt es diese Methode. Wenn ich wissen will, was Googlebot wirklich getan hat – nicht, was er tun könnte, und keine gerundete Zusammenfassung –, lese ich die Logs.

Eine typische Logzeile enthält IP-Adresse, User-Agent, URL-Pfad, Zeitstempel, Anfragemethode (GET/POST) und HTTP-Statuscode. Alles Weitere besteht darin, diese Felder sinnvoll auszuwerten.

Wann Sie die Analyse wirklich brauchen – und wann nicht

Seien Sie ehrlich: Die Logfile-Analyse ist ein Werkzeug für große Websites. Sie lohnt sich bei Zehntausenden URLs, Onlineshops und Facettennavigation, laufenden Migrationen oder Seiten, die bei Discovered – currently not indexed festhängen. Wie ich in meinem Leitfaden zum Crawl-Budget schrieb: “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look.” (Übersetzung) „Die meisten Websites müssen sich nicht um ihr Crawl-Budget sorgen, doch in einigen Fällen lohnt ein Blick.“ Daniel Waisberg von Google äußerte sich ähnlich zu den Crawl-Statistiken: Laut Search Engine Journal ist der Bericht für Websites mit weniger als ungefähr 1 000 Seiten kaum ein Thema.

Wird Ihre Website mit einigen Hundert Seiten problemlos gecrawlt, überspringen Sie diese Analyse und arbeiten Sie an etwas Wirkungsvollerem.

So erhalten Sie Ihre Logs – der Zugriff ist oft das Schwierigste

Logs liegen dort, wo die Anfrage tatsächlich endete:

• Apache und Nginx → Apache-Format „combined“ (am häufigsten).
• Microsoft IIS → W3C-Format.
• AWS ELB/ALB → ELB-Format.
• CDNs wie Cloudflare, Fastly und Akamai → eigene Log-Exporte. Das ist wichtig: Bei einer Website hinter einem CDN fehlen in einem reinen Origin-Log alle am Edge aus dem Cache bedienten Anfragen. Ziehen Sie die Logs daher an der Schicht, die der Bot tatsächlich erreicht hat.

Planen Sie mindestens 30 Tage, idealerweise 90 Tage ein, um Schwankungen der Crawl-Frequenz abzubilden. Rechnen Sie mit Reibung: Der Zugriff auf Server-Logs ist wegen organisatorischer DevOps-Hürden oft der wirklich schwierige Teil. Selbst Google-Mitarbeitende wiesen in einer Migrationsfolge von Search Off the Record darauf hin, wie schwer Logfiles praktisch zu beschaffen sein können. Reservieren Sie Zeit für die Anfrage.

Logs enthalten nicht nur Bot-Traffic, sondern jede Anfrage echter Besuchender. Neben dem URL-Pfad können Query-String-Werte, Sitzungskennungen oder andere sensible Daten stehen. Die OWASP-Empfehlungen sind eindeutig: Zugangsdaten, Zugriffstoken und personenbezogene Informationen gehören grundsätzlich nicht direkt in Logs. Solche Werte sollten Sie zuerst entfernen, maskieren oder hashen. Verankern Sie das in Zugriffssteuerung und Exportprozess, bevor Sie Logdateien zur Analyse weitergeben.

Schritt 1 – Prüfen, ob die Bots echt sind

Viele Leitfäden handeln diesen Schritt in einem Satz ab. Tun Sie das nicht. Viele Bots geben sich als Googlebot aus, um Firewalls zu überwinden (Ahrefs). Der User-Agent ist nicht authentifizierter Text. Behandeln Sie jede „Googlebot“-Zeile als Behauptung, die erst belegt werden muss.

Googlebot – zwei gültige Methoden:

1. Reverse- und Forward-DNS, also die beidseitige Prüfung. Googles eigene Schritte: Führen Sie mit host eine Reverse-DNS-Abfrage für die IP aus Ihren Logs aus. Prüfen Sie, ob die Domain googlebot.com, google.com oder googleusercontent.com ist. Führen Sie anschließend eine Forward-DNS-Abfrage für diesen Hostnamen aus und prüfen Sie, ob sie wieder zur ursprünglichen IP führt. Erst dieser Rückweg macht den Test zuverlässig. Ein Angreifer kann Reverse-DNS auf einen Namen unter *.googlebot.com zeigen lassen; nur die Rückauflösung zur identischen IP belegt die Anfrage. Befehle für macOS/Linux und Windows stehen im Tab Skripte.
2. Abgleich mit Googles veröffentlichten IP-Bereichen. Google veröffentlicht JSON-Dateien mit Crawler-IP-Adressen im CIDR-Format: common-crawlers.json für Googlebot und verwandte Crawler, außerdem special-crawlers.json, Dateien für nutzerausgelöste Fetcher und goog.json für sämtliche Google-IP-Adressen. Wie ich in meinem Googlebot-Leitfaden schrieb, hat Google “provided a list of public IPs you can use to verify the requests are from Google… You can compare this to the data in your server logs.” (Übersetzung) Google stellt öffentliche IPs bereit, mit denen sich Anfragen anhand der Server-Logs verifizieren lassen.

Bingbot – nur DNS. Hier liegt der entscheidende Unterschied: Bing veröffentlicht offiziell keine IP-Bereiche. Bing formuliert es so: “…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet,” (Übersetzung) „Wie andere Suchmaschinen veröffentlicht Bing keine Liste der IP-Adressen oder -Bereiche, von denen aus das Internet gecrawlt wird“, weil “the IP addresses or ranges we use can change any time.” (Übersetzung) „Die verwendeten IP-Adressen oder -Bereiche können sich jederzeit ändern.“ Bing veröffentlicht keine Liste der zum Crawlen verwendeten IP-Adressen oder -Bereiche, weil sie sich jederzeit ändern können. Prüfen Sie Bingbot daher per Reverse- und Forward-DNS auf einen Hostnamen unter *.search.msn.com, etwa msnbot-157-55-33-18.search.msn.com, oder mit dem Verify-Bingbot-Tool. Microsoft hat später zwar eine Bingbot-IP-JSON veröffentlicht, die offizielle Anleitung setzt wegen der veränderlichen IPs aber weiterhin auf DNS.

Entfernen Sie anschließend die Fälschungen. Berechnen Sie sämtliche Crawl-Kennzahlen ausschließlich mit dem verifizierten Datensatz. Ein nicht bestätigter „Googlebot“ ist fast immer ein Scraper oder gefälschter Bot und gehört in eine Sicherheitsprüfung, nicht in die Crawl-Verschwendungsanalyse.

Schritt 2 – Worauf Sie achten sollten

Sobald Sie mit verifizierten Treffern arbeiten, untersuchen Sie Folgendes:

• Am häufigsten und seltensten gecrawlte URLs und Bereiche. Ordnen Sie Anfragen nach URL und Verzeichnis. So sehen Sie, wohin Ihr Crawl-Budget tatsächlich fließt – das Ergebnis überrascht oft.
• Crawl-Frequenz im Zeitverlauf. Zeichnen Sie Crawls pro URL oder Bereich auf, um Einbrüche durch Migrationsfehler und Spitzen durch neue Bereiche oder Spider-Traps mit endlosen URLs zu erkennen.
• Von Bots aufgerufene Statuscodes, nach Häufigkeit priorisiert. Vergleichen Sie 200 mit 301/302 samt Ketten, 404 und 5xx. Ein 404, das 5 000-mal pro Woche aufgerufen wird, ist ein anderes Problem als ein 404 mit einmaligem Treffer: Priorisieren Sie nach Crawl-Häufigkeit, nicht nach bloßer Existenz.
• Crawl-Verschwendung. Facettennavigation, URL-Parameter, interne Suchergebnisse und endlose Kalender oder Seitennummerierungen können auf problematischen Websites viel Crawl-Budget verbrauchen. Logs zeigen genau, welche wertlosen Muster Bot-Zeit kosten.
• Verwaiste und nie gecrawlte Seiten. Dafür benötigen Sie beide Datensätze. Gleichen Sie Logs mit einem Website-Crawl ab: URLs im Log, aber nicht im Crawl, sind verwaiste Seiten, alte Weiterleitungen oder extern verlinkte Seiten. URLs im Crawl, aber nicht im Log, hat Google noch nie abgerufen.
• Mobiler gegenüber Desktop-Googlebot. Trennen Sie die User-Agents. Nach der Umstellung auf Mobile-first sollte Googlebot Smartphone überwiegen; ein hoher Desktop-Anteil verdient Prüfung.
• Antwortzeit und Crawl-Gesundheit. Steigende durchschnittliche Antwortzeiten korrelieren mit weniger Crawling. In SEJs Wiedergabe von Waisbergs Empfehlung heißt es: “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (Übersetzung) Achten Sie auf einen dauerhaften Anstieg der durchschnittlichen Antwortzeit; er beeinflusst die Crawl-Rate womöglich nicht sofort, deutet aber darauf hin, dass die Server die Last nicht bewältigen.

Was Logs nicht verraten

Trennen Sie diese Aussagen sauber, damit Sie die Daten nicht überinterpretieren:

• Crawl ≠ Indexierung. Eine täglich von Googlebot abgerufene URL kann dauerhaft unindexiert bleiben. Logs belegen den Abruf, nicht den Indexierungsstatus. Verbinden Sie die Logs mit Seitenindexierung und URL-Prüfung der Search Console.
• Crawl ≠ Ranking; mehr Crawling hilft nicht. Wie ich wiederholt sagte: “The rate of crawling isn’t going to impact your rankings.” (Übersetzung) „Die Crawl-Rate wirkt sich nicht auf Ihre Rankings aus.“ Behandeln Sie Crawl-Volumen nicht wie einen Rankinghebel.
• noindex verringert Crawling nicht. noindex steuert die Indexierung, nicht den Crawl. Um den Abruf tatsächlich zu stoppen, benötigen Sie robots.txt oder einen Statuscode.
• Crawl ≠ Modelltraining oder Zitat. Ein verifizierter Treffer von GPTBot, ClaudeBot oder PerplexityBot belegt nur, dass diese Anfrage auf dieser Schicht stattfand. Er beweist weder, dass die Seite zum Modelltraining verwendet oder später gespeichert wurde, noch dass sie in einer Chat-Antwort zitiert wurde. Das sind getrennte, unbeobachtete Ergebnisse.

Die Besonderheit 2026: KI-Bots stehen überall in den Logs

Die Akteure in modernen Logfiles haben sich verändert. In meiner Analyse von Cloudflare-Radar-Daten (Neue Webcrawler kennenlernen) crawlen Suchmaschinen-Bots weiterhin am meisten. KI-Bots liegen jedoch klar auf Platz zwei und könnten sie innerhalb weniger Jahre überholen. GPTBot, ClaudeBot, PerplexityBot und ähnliche Crawler erscheinen inzwischen häufig. Wenn Sie verifizierte Treffer nach User-Agent segmentieren, können KI-Crawler beim Anfrageanteil mit Suchmaschinen konkurrieren. Screaming Frogs Log File Analyser bietet deshalb inzwischen ein eigenes Tutorial zur KI-Bot-Überwachung.

Wie die Analyse in das übrige Crawling passt

Logs bilden die Diagnoseschicht unter dem gesamten Themenbereich Crawling. Mit ihnen messen Sie den Verbrauch des abstrakt beschriebenen Crawl-Budgets. Gary Illyes definiert es als “the number of URLs Googlebot can and is willing or is instructed to crawl” (Übersetzung) „die Anzahl der URLs, die Googlebot crawlen kann, will oder soll“. Logs überführen auch Spider-Traps: Ein unendlicher URL-Raum aus Kalendern oder Facetten erscheint als Flut nahezu identischer Anfragen. Zudem prüfen Sie damit, ob Maßnahmen zur Crawl-Frequenz, etwa ein korrektes lastmod oder interne Links auf wichtige Seiten, das Bot-Verhalten verändert haben. Logs ergänzen die GSC-Crawl-Statistiken, ersetzen sie aber nicht: Die Crawl-Statistiken sind der stichprobenartige Einstieg, Logs liefern ungekürzte Details pro URL und Bot.

KI-Zusammenfassung

Die Kurzfassung der fortgeschrittenen Version:

• Logs = Tatsachennachweis. Crawl-Tools simulieren, GSC nutzt Stichproben; Server-Zugriffslogs zeichnen jede Anfrage jedes Bots mit URL, Zeitstempel und Statuscode auf.
• Vor der Analyse verifizieren. User-Agents werden ständig gefälscht. Prüfen Sie Googlebot per Reverse- und Forward-DNS oder anhand von Googles IP-Bereichs- JSON, Bingbot per DNS zu *.search.msn.com – Bing veröffentlicht offiziell keine IP-Bereiche. Berechnen Sie alles nur mit dem verifizierten Datensatz.
• Auswerten: häufig und selten gecrawlte URLs und Bereiche, Crawl-Frequenz im Zeitverlauf, nach Häufigkeit priorisierte Statuscodes – ein 404 mit 5 000 Treffern pro Woche ist nicht mit einem Einzelfall gleichzusetzen –, Verschwendung durch Parameter, Facetten, interne Suche und endlose Seitennummerierung, verwaiste und ungecrawlte Seiten im Abgleich mit einem Crawl, Mobil-Desktop- Anteil von Googlebot sowie steigende Antwortzeiten als Warnsignal.
• Nicht überinterpretieren: Crawl ≠ Indexierung ≠ Ranking. Mehr Crawling verbessert keine Rankings, noindex reduziert Crawling nicht, und ein verifizierter KI-Bot-Treffer belegt einen Abruf – weder Modelltraining noch ein Zitat in einer Antwort.
• Einsatzbereich: große Websites, Onlineshops und Migrationen. Die meisten kleinen Websites benötigen das nicht.
• 2026: KI-Bots wie GPTBot, ClaudeBot und PerplexityBot bilden einen großen und wachsenden Anteil des Log-Traffics.
• Ergänzt die GSC-Crawl-Statistiken – verwenden Sie beides.

Offizielle Dokumentation

Primärquellen zur Verifizierung von Crawlern und Auswertung von Crawl-Daten.

Dokumentation des Suchmaschinenanbieters

• Anfragen automatisierter Abrufprogramme prüfen – die beiden offiziellen Methoden: manuelle Namensauflösung in beide Richtungen sowie Abgleich mit veröffentlichten Adressbereichen.
• Prüfung im Blog von Search Central – der ältere, weiterhin zitierte Begleitbeitrag.
• common-crawlers.json – IPs von Googlebot und allgemeinen Crawlern im CIDR-Format; laut Dokumentation werden “the IP addresses in the JSON files … represented in CIDR format”. (Übersetzung) „Die IP-Adressen in den JSON-Dateien werden im CIDR-Format dargestellt.“ Ergänzend: special-crawlers.json, user-triggered-fetchers.json und goog.json für alle Google-IPs.
• Übersicht der Google-Crawler und -Fetcher – alle Google-User-Agents, die in Logs erscheinen können.
• Crawl-Statistikbericht (Hilfe) und Einführungsbeitrag – die offizielle Stichprobenansicht, die Logs ergänzt.

Bing / Microsoft

• Bingbot verifizieren (Webmaster-Hilfe) – die offizielle Prüfseite.
• Bingbot per DNS verifizieren (Blog) – die maßgebliche Reverse- und Forward-DNS-Methode sowie Bings Aussage zu nicht veröffentlichten IP-Bereichen.
• Verify-Bingbot-Tool – IP einfügen und prüfen.

Zitate aus den Quellen

Nachprüfbare Aussagen. Soweit unterstützt, führt jeder Link direkt zur zitierten Passage auf der Quellseite.

Google – Crawler verifizieren

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command.” (Übersetzung) Führen Sie mit dem Befehl host eine Reverse-DNS-Abfrage für die zugreifende IP-Adresse aus Ihren Logs aus. — Google Search Central. Zum Zitat
• “Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (Übersetzung) Prüfen Sie, ob der Domainname googlebot.com, google.com oder googleusercontent.com ist. Zum Zitat
• “Run a forward DNS lookup on the domain name retrieved in step 1 using the host command on the retrieved domain name.” (Übersetzung) Führen Sie mit dem Befehl host eine Forward-DNS-Abfrage für den in Schritt 1 ermittelten Domainnamen aus. Zum Zitat
• “Verify that it’s the same as the original accessing IP address from your logs.” (Übersetzung) Prüfen Sie, ob sie mit der ursprünglichen zugreifenden IP-Adresse aus Ihren Logs übereinstimmt. Zum Zitat

Bing – Verifizierung ohne veröffentlichte IP-Bereiche

• “Perform a reverse DNS lookup using the IP address from the logs to verify that it resolves to a name that end with search.msn.com.” (Übersetzung) Führen Sie für die IP-Adresse aus den Logs eine Reverse-DNS-Abfrage aus und prüfen Sie, ob der Name auf search.msn.com endet. — Bing Webmaster Blog. Zum Zitat
• “…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet.” (Übersetzung) „Wie andere Suchmaschinen veröffentlicht Bing keine Liste der IP-Adressen oder -Bereiche, von denen aus das Internet gecrawlt wird.“ Der Grund: “the IP addresses or ranges we use can change any time, so responding to requests differently based on a hardcoded list is not a recommended approach.” (Übersetzung) Wie andere Suchmaschinen veröffentlicht Bing keine Liste der IP-Adressen oder -Bereiche, von denen aus das Internet gecrawlt wird; diese können sich jederzeit ändern, weshalb fest kodierte Listen nicht empfohlen werden. Zum Zitat

Patrick Stox – wofür Logs dienen (aus meiner Arbeit bei Ahrefs)

• Server logs are “the most trustworthy source of information to understand the URLs that search engines have crawled.” (Übersetzung) Server-Logs sind die vertrauenswürdigste Informationsquelle, um zu verstehen, welche URLs Suchmaschinen gecrawlt haben. Zum Zitat
• “Many bots pretend to be Googlebot to get past firewalls.” (Übersetzung) Viele Bots geben sich als Googlebot aus, um Firewalls zu umgehen. Zum Zitat
• “If you want to see hits from all bots and users, you’ll need access to your log files.” (Übersetzung) Um Treffer aller Bots und Nutzenden zu sehen, benötigen Sie Zugriff auf Ihre Logfiles. Zum Zitat
• “The rate of crawling isn’t going to impact your rankings.” (Übersetzung) Die Crawl-Rate wirkt sich nicht auf Ihre Rankings aus. Zum Zitat

Gary Illyes, Google – Crawl-Budget als messbare Log-Kennzahl

• Crawl budget is “the number of URLs Googlebot can and is willing or is instructed to crawl.” (Übersetzung) Crawl-Budget ist die Anzahl der URLs, die Googlebot crawlen kann, will oder soll. Zur Berichterstattung

Daniel Waisberg, Google – Antwortzeit als Signal für Crawl-Gesundheit (SEJs Wiedergabe seiner Empfehlung)

• “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (Übersetzung) Achten Sie auf einen dauerhaften Anstieg der durchschnittlichen Antwortzeit. Er beeinflusst die Crawl-Rate möglicherweise nicht sofort, deutet aber auf überlastete Server hin. Zum Zitat

Prüfen, ob ein Bot wirklich Googlebot ist

Der User-Agent in einer Logzeile ist nur Text; Scraper fälschen Googlebot, um Firewalls zu umgehen. Verlässlich ist nur die beidseitige DNS-Prüfung: IP rückwärts auflösen, Google-Domain bestätigen und den Hostnamen vorwärts wieder zur identischen IP auflösen.

macOS / Linux (mit host)

# 1) Reverse DNS the IP from your logs — it must end in googlebot.com,
#    google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows (mit nslookup)

:: 1) Reverse DNS the IP — confirm it ends in a Google domain
nslookup 66.249.66.1

:: 2) Forward DNS the returned hostname — confirm it matches the original IP
nslookup crawl-66-249-66-1.googlebot.com

Endet die Reverse-Auflösung nicht bei einer Google-Domain oder liefert die Forward-Auflösung nicht die ursprüngliche IP zurück, ist es nicht Googlebot. Für Bingbot verwenden Sie dieselben Schritte, erwarten aber einen Hostnamen unter search.msn.com. Alternativ gleichen Sie die IP ohne DNS mit Googles veröffentlichten Bereichen ab (common-crawlers.json, im CIDR-Format).

Crawler-Treffer aus einem Rohlog extrahieren und zählen

Kurze Einzeiler für ein Apache-/Nginx-Zugriffslog im Combined-Format. Sie filtern nur nach der User-Agent-Zeichenfolge. Verifizieren Sie die IPs, bevor Sie den Zählungen vertrauen.

# Pull only the lines claiming to be Googlebot
grep -i "googlebot" access.log > googlebot-hits.log

# Count Googlebot hits per URL, most-crawled first
# (combined format: $7 is the request path)
grep -i "googlebot" access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn | head -50

# Count Googlebot hits per status code (combined format: $9 is the status)
grep -i "googlebot" access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# List the URLs Googlebot hit that returned a 404, by frequency
grep -i "googlebot" access.log \
  | awk '$9 == 404 {print $7}' \
  | sort | uniq -c | sort -rn

# Get the unique IPs claiming Googlebot — the list you then verify by DNS
grep -i "googlebot" access.log | awk '{print $1}' | sort -u

Passen Sie die Feldpositionen $7 und $9 an, wenn Ihr Logformat abweicht; IIS/W3C und ELB ordnen Felder anders an.

Ablauf der Logfile-Analyse

• Logs beschaffen – Server-Zugriffslogs oder Exporte von CDN und Load-Balancer. Bei einer Website hinter einem CDN auch Edge-Logs abrufen, weil dem Origin Cache-Treffer fehlen.
• Ausreichenden Zeitraum erfassen – mindestens 30, idealerweise 90 Tage.
• Bots zuerst verifizieren – Reverse- und Forward-DNS oder Googles veröffentlichte IP-Bereiche. Für Bingbot DNS zu *.search.msn.com.
• Fälschungen entfernen – Crawl-Kennzahlen nur mit verifizierten Treffern berechnen; gefälschten „Googlebot“ an die Sicherheitsprüfung geben.
• Häufig und selten gecrawlte URLs und Bereiche ordnen – erkennen, wohin das Budget fließt.
• Crawl-Frequenz im Zeitverlauf verfolgen – Einbrüche durch Migrationen und Spitzen durch neue Bereiche oder Spider-Traps finden.
• Statuscodes zählen – 200, 301-302-Ketten, 404 und 5xx; Fehler nach Crawl-Häufigkeit statt bloßer Existenz priorisieren.
• Crawl-Verschwendung suchen – Parameter, Facettennavigation, interne Suche sowie endlose Seitennummerierungen und Kalender.
• Verwaiste und ungecrawlte Seiten finden – Logs mit Website-Crawl abgleichen: im Log, nicht im Crawl = verwaist; im Crawl, nicht im Log = nie abgerufen.
• Mobil-Desktop-Anteil von Googlebot prüfen – Smartphone sollte überwiegen.
• Durchschnittliche Antwortzeit beobachten – ein steigender Trend kann Crawling drosseln.
• KI-Bots segmentieren – GPTBot, ClaudeBot und PerplexityBot haben heute einen relevanten Traffic-Anteil.
• Mit GSC bestätigen – Befunde mit Crawl-Statistiken und URL-Prüfung verbinden, denn Crawl ist nicht Indexierung.

Was in Ihr Analyseblatt gehört

Ob Sie Screaming Frogs Log File Analyser, BigQuery oder die Ahrefs-Logfile-Vorlage verwenden: Sie erstellen stets dieselben wenigen Ansichten. Verifizieren Sie die Bots, zerlegen Sie jede Zeile in Spalten und bilden Sie Pivot-Tabellen.

Aus jeder Logzeile zu extrahierende Spalten

Zu erstellende Pivot-Ansichten

• Crawls pro URL und Verzeichnis, absteigend für häufig und selten gecrawlte Ziele.
• Crawls pro Statuscode, danach Statuscode × URL, damit ein häufiges 404 auffällt.
• Crawls pro Tag/Woche, nach Bereich segmentiert, als Frequenztrend.
• Crawls pro Bot/User-Agent für Mobil-Desktop- und KI-Bot-Anteile.
• Eine Verknüpfung Logs gegen Crawl per SVERWEIS oder Merge mit einem Screaming-Frog- oder Ahrefs-Export, um verwaiste und nie abgerufene Seiten zu erkennen.

Der Ahrefs-Leitfaden bietet dafür eine herunterladbare Vorlage; der Leitfaden zur Logfile-Analyse verlinkt sie.

So lesen Sie ein Logfile: die Prüfschritte

Dieses wiederholbare Schema eignet sich für jede Log-Analyse. Erst verifizieren, dann die folgenden Durchgänge ausführen.

1. Verifizieren, dann analysieren. Die Daten sind nur so gut wie die Bot-Identität dahinter. Reverse- und Forward-DNS oder IP-Bereiche prüfen und nur den bestätigten Datensatz analysieren. Gefälschte Bots gehören zur Sicherheit, nicht zur SEO.

2. Wohin fließt das Budget? Nach URL und Bereich ordnen. Ziel ist es, Aufmerksamkeit an falschen Stellen und zu wenig Abrufe wichtiger Seiten zu erkennen.

3. Worauf treffen Bots? 200 ist gesund; 3xx-Ketten, 404 und 5xx sind Verluste. Nach der Trefferhäufigkeit priorisieren, nicht nach bloßer Fehlerexistenz.

4. Was wird verschwendet? Parameter, Facettennavigation, interne Suche und endlose Seitennummerierungen oder Kalender sind klassische Budgetsenken. Logs benennen die genauen Muster.

5. Was fehlt? Logs mit einem Crawl abgleichen. Im Log, nicht im Crawl bedeutet verwaiste Seite, alte Weiterleitung oder externer Link. Im Crawl, nicht im Log bedeutet: Google hat die URL nie abgerufen.

6. Wer crawlt? Mobilen und Desktop-Googlebot trennen – Smartphone sollte überwiegen – und den KI-Bot-Anteil erfassen, der inzwischen mit Suchmaschinen konkurriert.

7. Ist der Server gesund? Eine steigende durchschnittliche Antwortzeit warnt früh vor möglicher Crawl-Drosselung.

Werkzeuge für die Logfile-Analyse

• Screaming Frog SEO Log File Analyser – das bewährte Desktop-Werkzeug. Es verifiziert Suchmaschinen-Bots automatisch, markiert gefälschte IPs und bietet Filter für User-Agent und Verifizierungsstatus. Importieren Sie einen SEO-Spider-Crawl und verwenden Sie „Not In URL Data“, um verwaiste URLs zu finden: “URLs which were discovered in your logs, but are not present in the crawl data imported.” (Übersetzung) URLs, die in den Logs vorkommen, aber nicht in den importierten Crawl-Daten. Es gibt außerdem ein Tutorial zur KI-Bot-Überwachung. Zum Tool
• BigQuery sowie Splunk / ELK Stack / Logflare / logz.io – für rohe, großvolumige Speicherung und Abfragen, wenn ein Desktop-Tool nicht ausreicht.
• Ahrefs – Logs mit einem Ahrefs-Site-Audit-Crawl abgleichen, um verwaiste Seiten zu finden und tatsächliche Bot-Ziele zu bestätigen.
• Semrush Log File Analyzer, OnCrawl, Botify, JetOctopus – weitere Crawl- und Log-Plattformen, die letzten drei für Unternehmen.
• GSC-Crawl-Statistiken – der offizielle, kostenlose und stichprobenartige Einstieg. Sie ergänzen Rohlogs, ersetzen sie aber wegen Aggregation, Begrenzung und fehlendem URL-Export nicht.
• Verify-Bingbot-Tool – IP einfügen und Bingbot bestätigen: bing.com/toolbox/verify-bingbot.

Zu vermeidende Fehler

• Der Zeichenfolge „Googlebot“ ungeprüft vertrauen. Warum das falsch ist: Der User-Agent ist nicht authentifizierter Text. Jeder kann Googlebot in einen Anfrageheader schreiben, Schutzmaßnahmen umgehen oder die Analyse mit falschem Traffic verunreinigen. Stattdessen: Reverse- und Forward-DNS oder Googles IP-Bereiche prüfen, bevor eine Zeile in Crawl-Kennzahlen einfließt.
• GSC-Crawl-Statistiken als vollständiges Bild behandeln. Warum das falsch ist: Sie sind stichprobenartig, gerundet, auf ungefähr 1 000 Zeilen und rund 90 Tage begrenzt und bieten keinen URL-Export. Sie fassen zusammen, statt aufzuzeichnen. Stattdessen: Logs als Tatsachennachweis und Crawl-Statistiken als ergänzenden schnellen Einstieg verwenden.
• Bei einer CDN-Website nur Origin-Logs abrufen. Warum das falsch ist: Dem Origin-Log fehlen sämtliche am Edge aus dem Cache bedienten Anfragen. Das Bild der Bot-Antworten bleibt unvollständig. Stattdessen: Logs an der tatsächlich erreichten CDN-/Edge-Schicht abrufen.
• 404- und 5xx-Fehler nach Existenz statt Häufigkeit beheben. Warum das falsch ist: Ein 404 pro Monat und ein 404 mit 5 000 Treffern pro Woche sind nicht dasselbe Problem. Gleiche Dringlichkeit verschwendet Aufwand. Stattdessen: Probleme nach der tatsächlichen Bot-Trefferhäufigkeit ordnen.
• Crawl-Volumen wie einen Rankinghebel maximieren. Warum das falsch ist: Mehr Crawling verbessert keine Rankings; es ist ein Diagnosesignal, keine Wachstumskennzahl. Stattdessen: Crawl-Frequenz zum Erkennen von Einbrüchen und Spider-Traps verwenden.
• Crawling mit noindex stoppen wollen. Warum das falsch ist: noindex steuert die Indexierung. Google muss die Seite weiterhin abrufen, um das Tag zu sehen. Stattdessen: Wenn der Abruf selbst verhindert werden soll, robots.txt oder einen Statuscode verwenden.
• Eine URL allein anhand von Logs „verwaist“ nennen. Warum das falsch ist: Eine im Log, aber nicht in einem frischen Crawl enthaltene URL kann eine alte Weiterleitung, ein externer Link oder wirklich verwaist sein. Logs allein unterscheiden das nicht. Stattdessen: Vor Schlussfolgerungen mit einem aktuellen Website-Crawl abgleichen.

Dauerhafte Kennzahlen für die Logfile-Analyse

Anteil verifizierter Bots

• Metrik: Verifizierte Googlebot-/Bingbot-Treffer ÷ alle Treffer, die sich per User-Agent als Googlebot oder Bingbot ausgeben.
• Aussage: Welcher Anteil des „Bot-Traffics“ tatsächlich gefälschte Scraper statt echter Suchmaschinen sind.
• Ermittlung: Jede behauptete Bot-IP per Reverse- und Forward-DNS oder IP-Bereichs-JSON prüfen und die Erfolgsquote zählen.
• Benchmark / realistischer Bereich: Keine universelle Zahl; sie hängt von der Scraping-Intensität ab. Ein niedriger oder sinkender verifizierter Anteil ist das Signal, kein fester Schwellenwert.
• Rhythmus: Bei jedem neuen Log-Zeitraum.

Anteil der Crawl-Verschwendung

• Metrik: Prozentsatz verifizierter Bot-Anfragen auf Parameter, Facetten, interne Suche oder endlose Seitennummerierungen und Kalender.
• Aussage: Wie viel Crawl-Budget an nutzlose URLs statt relevante Seiten geht.
• Ermittlung: Verifizierte Treffer nach URL-Mustern wie Query-Strings und bekannten Facetten- oder Suchpfaden segmentieren.
• Benchmark / realistischer Bereich: Keine universelle Zahl; sie hängt von URL-Struktur und Facetten ab. Beim ersten Abruf eine eigene Basislinie bilden und anschließend den Trend verfolgen.
• Rhythmus: 30 bis 90 Tage; nach Bereinigungen an robots.txt, Parametern oder Seitennummerierung erneut prüfen.

Nach Häufigkeit gewichtete Statuscode-Verteilung

• Metrik: Anteil von 200, 3xx, 404 und 5xx an verifizierten Bot-Anfragen.
• Aussage: Wo Bots Abrufe für Fehler statt Live-Inhalte verbrauchen und ob sich das verschlechtert.
• Ermittlung: Statuscode-Feld verifizierter Logzeilen zählen.
• Benchmark / realistischer Bereich: Kein universelles Ziel; abhängig von Alter und Weiterleitungshistorie der Website. Den Trend statt einer einzelnen Momentaufnahme beobachten. Ein steigender 404-/5xx-Anteil ist relevant.
• Rhythmus: 30 bis 90 Tage oder unmittelbar nach einer Migration.

Anteil mobiler gegenüber Desktop-Googlebot-Anfragen

• Metrik: Anteil verifizierter Googlebot-Treffer mit Smartphone- gegenüber Desktop-User-Agent.
• Aussage: Ob Google die Website nach der Mobile-first-Umstellung tatsächlich überwiegend mobil crawlt.
• Ermittlung: Verifizierte Treffer nach Googlebot-User-Agent in Smartphone und Desktop segmentieren.
• Benchmark / realistischer Bereich: Bei den meisten Websites sollte Smartphone überwiegen. Ein hoher Desktop-Anteil ist prüfenswert, aber allein kein harter Fehler.
• Rhythmus: Bei jedem Log-Abruf.

Anzahl verwaister und ungecrawlter Seiten

• Metrik: URLs in Logs, aber nicht in einem frischen Crawl – verwaiste oder alte Links – sowie URLs im Crawl, aber nicht in Logs – nie abgerufen.
• Aussage: Welche Seiten Bots schwer erreichen und welche verlinkten Seiten Google noch nie abgerufen hat.
• Ermittlung: Liste verifizierter Treffer mit einem Website-Crawl-Export aus Screaming Frog oder Ahrefs verknüpfen.
• Benchmark / realistischer Bereich: Vollständig situationsabhängig von Website-Größe und jüngsten Migrationen oder Umstrukturierungen. Die Zahl über die Zeit verfolgen statt extern vergleichen.
• Rhythmus: Bei großen Websites vierteljährlich oder direkt nach Migrationen.

Kopierfertige Prompts für die Log-Analyse

Diese Prompts helfen bei der Interpretation bereits abgerufener und verifizierter Logdaten. Sie dienen nicht zum Erzeugen von Logdaten; lassen Sie eine KI niemals Logzeilen oder Statistiken erfinden.

Crawl-Verschwendung aus einer URL-Stichprobe zusammenfassen

Here is a list of URL paths that verified Googlebot hits landed on, one per
line, from my server logs. Group them into patterns (query parameters,
faceted navigation, internal search, pagination/calendars, or "looks like a
real page"), and tell me which pattern has the most URLs. Don't invent URLs
that aren't in the list — only group what I've pasted.

[paste your URL list here]

Erwartetes Ergebnis: wenige benannte Cluster mit Anzahlen und ein Hinweis auf das wahrscheinlich größte Verschwendungsmuster. Behandeln Sie es als Ausgangspunkt für den Abgleich mit echten Pfaden, nicht als endgültige Antwort.

Eine Statuscode-Aufteilung priorisieren

I have this table of HTTP status codes and how many times verified Googlebot
hit each one over the last 30 days. Rank them by which I should fix first,
weighting frequency over severity — a 404 hit 5,000 times matters more than a
500 hit twice. Explain the reasoning in one line per row.

status_code, hit_count
[paste your table here]

Erwartetes Ergebnis: dieselben Zeilen nach Korrekturpriorität geordnet, jeweils mit einer kurzen Begründung. Prüfen Sie die Logik im Kontext Ihrer Website.

Eine Anfrage nach Logzugriff an DevOps entwerfen

Write a short, plain-English email to my DevOps/hosting team asking for
30-90 days of raw web server access logs (Apache/Nginx combined format, or
our CDN's edge logs if we're behind one) for [site name]. Explain in one
sentence why I need it (verifying real Googlebot/Bingbot crawl activity vs
GSC's sampled report) and ask what export format and delivery method works
for them.

Erwartetes Ergebnis: ein kurzer E-Mail-Entwurf, den Sie mit dem tatsächlichen Website-Namen ergänzen können. Prüfen Sie ihn vor dem Versand; das Tool versendet keine Nachricht.

Ein DNS-Prüfergebnis erklären

I ran a reverse DNS lookup on an IP from my server logs and then a forward
DNS lookup on the hostname it returned. Here's the raw output from the
`host` command. Tell me plainly whether this confirms the request came from
real Googlebot or Bingbot, and point to exactly which line proves or
disproves it.

[paste your host/nslookup output here]

Erwartetes Ergebnis: ein verständliches Urteil mit Bezug auf die konkrete Ausgabezeile. Nutzen Sie es als Zweitmeinung, nicht als Ersatz für die eigentliche Regel: Der Hostname endet in einer Google- oder Bing-Domain und die Forward-Auflösung liefert die ursprüngliche IP.

Empfehlenswerte Ressourcen

Meine verwandten Beiträge

• SEO-Logfile-Analyse mit Vorlage – der geprüfte Ahrefs-Grundleitfaden, dessen Rahmen und Vorlage dieser Artikel nutzt.
• Wann ist Crawl-Budget relevant? – wann sich eine Log-Analyse lohnt und wann nicht.
• Was ist Googlebot und wie funktioniert er? – Hintergrund zu Crawlern und IP-Verifizierung.
• Neue Webcrawler: KI-Bots holen Suchmaschinen-Bots ein – warum Logs 2026 anders aussehen.
• Einsteigerleitfaden zur technischen SEO – Crawling und Logs im Gesamtbild.

Meine Vorträge

• How Search Works (SlideShare) – mein Crawling-Überblick: Googlebot als mehr als 1 000 Systeme mit spezialisierten Desktop-, Mobil-, Bild-, Nachrichten-, Video- und Anzeigen-Crawlern, die sich einen Crawl-Budget-Pool teilen, sowie überwiegend aus Mountain View stammende Anfragen. Das eignet sich als Plausibilitätsprüfung neben, niemals statt einer korrekten Verifizierung. Dauerhafter Hinweis: „Dies ist mein Verständnis der Systeme und nicht zu 100 Prozent vollständig oder korrekt.“

Von anderen

• Screaming Frog Log File Analyser – Benutzerleitfaden und KI-Bot-Tutorial.
• Search Engine Land – Leitfaden zur Logfile-Analyse von Kody Wirth – praktische Einführung in Formate, Tools und Muster.
• Search Engine Journal – Googles Crawl-Statistiken verwenden – Daniel Waisbergs Empfehlung samt Antwortzeitwarnung.
• Search Engine Journal – Indexierung und Crawl-Budget – belegte Definition und Einfluss der Qualität auf die Crawl-Nachfrage.
• Search Engine Roundtable – Bingbot-IP-Adressen veröffentlicht – zur späteren IP-JSON trotz DNS-zentrierter offizieller Anleitung.
• Conductor – Logfile-Analyse für SEO – verständliche Erklärung und Maßnahmen.
• r/TechSEO – Community für Crawl- und Indexierungsdiagnosen.

Videos

• Google Search Central (YouTube) – Martin Splitts Erklärungen zu Crawling und Rendering sowie die Reihe How Google Search Works. Nützlicher Hintergrund zu den Bots, deren Treffer Sie in Logs verifizieren. Zum Kanal

Wissen testen

Fünf Fragen zur Bot-Verifizierung und zur korrekten Interpretation Ihrer Logs.

Änderungsprotokoll