Ein Shop weiß aus der Search Console, welche Adressen indexiert sind. Was dort nicht steht: welche Adresse ein Crawler tatsächlich angefragt hat, in welcher Sekunde, mit welchem Statuscode und mit wie vielen Bytes der Server geantwortet hat. Diese Angaben liegen an genau einer Stelle - im Zugriffsprotokoll des eigenen Servers. Dort taucht auch auf, was keine fremde Auswertung zeigt: Abrufe von Bots ohne Ausweis, Anfragen an Adressen, die es seit dem letzten Relaunch nicht mehr gibt, und Fehlerantworten, die nur unter Last entstehen. Wie groß der nicht-menschliche Anteil inzwischen ist, zeigt eine Messung im Netz eines Infrastrukturanbieters: Anfang Dezember 2025 stammten 47 Prozent der HTML-Anfragen von Menschen und 44 Prozent von Bots ohne KI-Bezug (Cloudflare Radar). Wer den Rest nur schätzt, steuert seine Sichtbarkeit in der Suche mit halben Daten.
Was im Zugriffsprotokoll steht und was die Konsole auslässt
Eine Zeile im Zugriffsprotokoll ist ein Tatsachenbericht: Absender-Adresse, Zeitstempel, Methode, angefragter Pfad, Protokollversion, Statuscode, Antwortgröße, Referrer und die Kennung des Clients. Nichts davon ist gerundet, nichts ist auf 90 Tage begrenzt, nichts wird nach Wichtigkeit gefiltert. Genau darin liegt der Unterschied zu jedem Bericht, den ein Suchanbieter bereitstellt. Die Crawling-Statistik der Search Console führt beispielsweise nur die 20 untergeordneten Domains mit den meisten Zugriffen der letzten 90 Tage auf (Google Search Console-Hilfe). Ein Shop mit Bilderhost, Redaktionssystem und Länder-Subdomains sieht dort also einen Ausschnitt, im eigenen Protokoll dagegen den vollständigen Bestand. Google zieht die Grenze, ab der sich der Bericht überhaupt lohnt, bei 1.000 Seiten (Google Search Console-Hilfe); die meisten Sortimente mit Varianten und Filtern liegen deutlich darüber.
Der zweite Unterschied ist die Reichweite. Ein Suchanbieter berichtet über sich selbst. Das Protokoll berichtet über alle: über Preisvergleiche, Sicherheitsscanner, Übersetzungsdienste, Archivdienste, Werkzeuge von Mitbewerbern und über den Anteil, der schlicht nichts Gutes will. Nach einer Auswertung von Netzwerkdaten überholte automatisierter Verkehr im Jahr 2024 erstmals seit zehn Jahren den menschlichen und lag bei 51 Prozent des gesamten Web-Verkehrs (Imperva); auf schädliche Bots entfielen dabei 37 Prozent (Imperva). Diese Zugriffe erzeugen Last, verbrauchen Rechenzeit und verzerren jede Auswertung, die auf Seitenaufrufen beruht - im Bericht des Suchanbieters kommen sie nicht vor.
Ein üblicher Eintrag im kombinierten Format nennt neun Felder. Vier davon tragen die SEO-Auswertung: der Pfad sagt, welche Adresse überhaupt bekannt ist, der Statuscode sagt, was der Server geantwortet hat, die Antwortgröße verrät stille Fehlseiten mit Statuscode 200, und die Client-Kennung trennt Crawler von Besuchern. Die restlichen Felder - Zeitstempel, Methode, Protokollversion, Referrer und Absender-Adresse - beantworten die Fragen nach Takt, Herkunft und Echtheit.
Wer wirklich anklopft: die Verteilung im Bot-Verkehr
Bevor eine einzelne Adresse betrachtet wird, lohnt der Blick auf die Verteilung. Im Netz eines großen Infrastrukturanbieters erzeugte Googlebot 2025 allein 4,5 Prozent aller HTML-Anfragen - ein Anteil, der etwas über dem aller Trainings- und Antwort-Crawler zusammen lag (Cloudflare Radar). Beim verifizierten Bot-Verkehr entfielen 40 Prozent auf Suchmaschinen-Crawler, halb so viel auf KI-Crawler und über 13 Prozent auf SEO-Werkzeuge (Cloudflare Radar). Ein einziger Crawler stellte in seiner aktivsten Phase mehr als 28 Prozent des gesamten verifizierten Bot-Verkehrs (Cloudflare Radar). Für einen Shop heißt das: Der Zugriffsberg, der im Protokoll auffällt, ist selten der Suchmaschine zuzurechnen, und eine Steuerung, die für Google gebaut wurde, greift bei den übrigen nicht.
Search engine crawlers were responsible for 40% of Verified Bot traffic, with AI crawlers generating half as much (20%). Search engine optimization bots were also quite active, driving over 13% of requests from Verified Bots.
Cloudflare Radar, The 2025 Cloudflare Radar Year in Review
Der Handel steht dabei besonders im Blickfeld: Bei einer Auswertung der KI-Crawler-Aktivität nach Branchen im Oktober 2025 vereinten Handel und Software zusammen gut 40 Prozent der gesamten Aktivität auf sich (Cloudflare Radar). Das passt zum Gewicht der Branche im Netz, denn 19,2 Prozent aller untersuchten mobilen Seiten wurden als Shop erkannt (Web Almanac). Wer für den eigenen Onlinehandel entscheiden will, welche dieser Zugriffe erwünscht sind, findet die Abwägung im Beitrag zur Steuerung von KI-Crawlern und zum Nutzungsvorbehalt.
| Zugriffsart | Erkennbar am | Wirkung auf das Budget | Sinnvolle Reaktion |
|---|---|---|---|
| Suchmaschinen-Crawler | Kennung plus Rückwärtsauflösung | verbraucht es planbar | Pfade lenken, Fehler beseitigen |
| KI- und Trainings-Crawler | Kennung, oft ohne Verifizierung | verbraucht Rechenzeit | in der robots.txt regeln |
| SEO- und Analysewerkzeuge | feste Kennungen, feste Netzbereiche | kein Nutzen für die Suche | Takt begrenzen |
| Getarnte Zugriffe | Kennung passt nicht zur Adresse | reine Last | vor der Anwendung abweisen |
Die Grenzen, an denen ein Abruf abbricht
Ein Crawler lädt keine beliebig großen Dateien. Googlebot holt von einer einzelnen Adresse höchstens die ersten zwei Megabyte; alles danach wird weder gerendert noch indexiert (Google Search Central). Für andere Google-Crawler ohne eigene Vorgabe liegt die Grenze bei 15 Megabyte je Adresse, unabhängig vom Dateityp (Google Search Central). Beides klingt großzügig, und für das reine Dokument ist es das auch: Das HTML einer typischen Seite wiegt im Median 35 Kilobyte (Web Almanac). Kritisch wird es erst, wenn ein Shop Produktdaten, Bildlisten oder ganze Zustandsobjekte inline in die Seite schreibt. Dann rutscht der Teil, der die strukturierte Auszeichnung trägt, hinter die Grenze - und im Protokoll sieht der Abruf trotzdem nach einer sauberen 200-Antwort aus.
log_format crawl '$remote_addr $time_iso8601 "$request" '
'$status $body_bytes_sent $request_time '
'"$http_referer" "$http_user_agent"';
access_log /var/log/nginx/shop-crawl.log crawl;Die Antwortgröße im Protokoll ist deshalb kein Nebenfeld, sondern ein Messwert. Eine Kategorieseite, die sonst 60 Kilobyte ausliefert und plötzlich mit 4 Kilobyte antwortet, hat entweder einen Fehler ausgeliefert oder eine leere Trefferliste - beides mit Statuscode 200 und damit unsichtbar für jede Prüfung, die nur den Code betrachtet. Zusammen mit der Antwortzeit ergibt sich eine Reihe, die sich über Wochen verfolgen lässt. Wie dieselbe Größe im Ladeverhalten wirkt, steht im Beitrag zu Core Web Vitals und Ladezeit; an der Ladezeitoptimierung hängt am Ende auch der Takt, in dem gecrawlt wird.
Wird die Seite langsamer, antwortet der Server mit 5xx oder signalisiert er mit 429 eine Drosselung, sinkt die Crawl-Rate unmittelbar (Google Search Central). Das ist die Stellschraube, die ohne jedes Zutun wirkt: Ein Server, der zügig antwortet, bekommt mehr Abrufe - und ein Server unter Dauerlast bekommt weniger, ohne dass irgendwo eine Meldung erscheint.
robots.txt: was die Norm sagt und was im Netz steht
Die robots.txt ist die erste Datei, die ein Crawler anfragt, und im Protokoll ist sie die verlässlichste Spur für den Beginn eines Durchlaufs. Der Standard verlangt ein Parsing-Limit von mindestens 500 Kibibyte (IETF), und Google setzt genau diese Grenze auch durch (Google Search Central). Zwischenspeichern soll ein Crawler die Datei laut Norm nicht länger als 24 Stunden (IETF); Google hält die Datei in der Regel ebenfalls bis zu 24 Stunden vor (Google Search Central). Eine Weiterleitungskette soll über mindestens fünf aufeinanderfolgende Sprünge verfolgt werden (IETF) - wer die robots.txt über mehrere Hostwechsel schickt, riskiert, dass sie am Ende als nicht vorhanden gilt.
- Ein Serverfehler auf die robots.txt hält das Crawling der Website zunächst zwölf Stunden an; angefragt wird in dieser Zeit weiter nur die Datei selbst (Google Search Console-Hilfe).
- Bleibt der Fehler bestehen, arbeitet Google bis zum 30. Tag nach der ursprünglichen Anforderung mit der letzten erfolgreich abgerufenen Fassung (Google Search Console-Hilfe).
- Die Dateigröße ist selten das Problem: nur 0,1 Prozent der Seiten überschreiten die 500-Kilobyte-Grenze (Web Almanac).
- Der Takt der Anzeigen-Crawler ist kein Zufall: hinterlegte Adressen werden etwa alle zwei Wochen geholt (Google Search Console-Hilfe).
Der Blick auf die Gesamtheit relativiert einiges. Nur 84,9 Prozent aller robots.txt-Anfragen erhalten überhaupt eine 200-Antwort (Web Almanac), bei 13 Prozent der Seiten läuft die Anfrage ins Leere (Web Almanac), und 1,8 Prozent liefern eine vollständig leere Datei aus, für deren Auslegung der Standard nichts vorgibt (Web Almanac). Geregelt wird fast alles über den Sammelplatzhalter: In 77,04 Prozent der Dateien steht der Stern als Adressat (Web Almanac), während Googlebot nur in 6,66 Prozent namentlich angesprochen wird (Web Almanac). Regeln für den Trainings-Crawler GPTBot sind binnen eines Jahres um rund die Hälfte häufiger geworden und stehen inzwischen auf 4,5 Prozent der Seiten (Web Almanac); die als Wegweiser gedachte llms.txt findet sich auf 2,13 Prozent (Web Almanac). Diese Zahlen stammen aus einem Bestand von 16.213.084 Websites (Web Almanac) - sie beschreiben nicht den Einzelfall, sondern den Normalzustand, gegen den ein Shop antritt.
Ein per robots.txt gesperrter Pfad wird nicht abgerufen - und damit liest kein Crawler das noindex, das auf der Seite steht. Im Protokoll sieht man bei ausgesperrten Adressen deshalb gar nichts, obwohl sie im Index stehen können. Wer eine Adresse aus dem Index nehmen will, lässt den Abruf zu und setzt die Anweisung im Kopfbereich oder als HTTP-Kopfzeile. Passend dazu die Verteilung im Netz: Nur 2,4 Prozent der mobilen Seiten setzen überhaupt ein noindex (Web Almanac), und bei 10,3 Prozent stehen ungültige Elemente im Kopfbereich (Web Almanac) - dort verlieren canonical, noindex und hreflang ihre Wirkung.
Crawl-Budget: ab welcher Größe es zählt
Crawl-Budget ist ein Begriff, der öfter benutzt als gebraucht wird. Google hält eine gezielte Steuerung erst bei großen Websites ab etwa einer Million eindeutiger Seiten mit wöchentlich wechselnden Inhalten für nötig (Google Search Central), bei sehr schnell wechselnden Inhalten dagegen schon ab 10.000 eindeutigen Seiten (Google Search Central). Der zweite Fall trifft mehr Shops, als es zunächst scheint: Varianten, Filterkombinationen, Sortierungen und Seitenzahlen erzeugen Adressen im fünfstelligen Bereich, ohne dass jemand sie angelegt hätte. Welche davon überhaupt existieren dürfen, ist eine Entscheidung der Informationsarchitektur - der Beitrag zur Facettennavigation und ihren Filter-Adressen zeigt die Abwägung im Detail.
Abrufe je Verzeichnis
Wie verteilt sich der Crawl auf Kategorien, Produkte, Filter und Suchergebnisse? Ein Sortiment, dessen Abrufe zur Hälfte auf Filteradressen entfallen, hat kein Budgetproblem, sondern ein Strukturproblem.
Statuscodes je Bereich
Ein Bereich mit auffällig vielen 404- oder 301-Antworten zeigt alte Verweise. Ein echter 404 nimmt die Adresse aus der Warteschlange, eine als Erfolg ausgelieferte Fehlseite wird weiter abgerufen und verbraucht Budget (Google Search Central).
Antwortzeit je Vorlage
Produktseiten, Kategorien und die Suche antworten unterschiedlich schnell. Die langsamste Vorlage bestimmt, wie viel insgesamt abgerufen wird - ein Fall für Caching und Serverbetrieb.
Erstabruf neuer Adressen
Die Spanne zwischen Veröffentlichung und erstem Abruf ist die ehrlichste Kennzahl für die Erreichbarkeit einer Struktur. Sie steht nur im Protokoll.
Ein Detail, das regelmäßig für Ratlosigkeit sorgt, ist der Zugriffsberg ohne erkennbaren Anlass. Häufig steckt kein Ereignis dahinter, sondern ein Takt: ein Anzeigen-Crawler, ein Feed-Abgleich, ein Sicherheitsscan im Wochenrhythmus. Wer diese Muster einmal benannt hat, sucht nicht länger nach einer Ursache, die es nicht gibt, und erkennt dafür die Ausschläge, die tatsächlich neu sind.
Vom Rohprotokoll zur Entscheidung
Die Menge schreckt zunächst ab. Eine typische Seite erzeugt im Median 77 Anfragen je Aufruf (Web Almanac) - Dokument, Stilvorlagen, Skripte, Schriften und Bilder zusammengenommen. Bei einem Shop mit fünfstelligen Besuchszahlen entstehen daraus Millionen Zeilen pro Tag. Der erste Schritt ist deshalb nicht die Auswertung, sondern der Zuschnitt: Ressourcen aus der Betrachtung nehmen, auf Dokumentabrufe reduzieren, nach Kennung trennen. Danach bleibt eine Datenmenge, die sich mit Bordmitteln beherrschen lässt - ohne zusätzliche Software und ohne dass Daten das Haus verlassen.
Aus diesen beiden Aufrufen folgt bereits eine Entscheidung. Fällt ein nennenswerter Teil der Abrufe auf die interne Suche, wird Rechenzeit für Adressen aufgewendet, die im Index nichts verloren haben. Steht der Anteil der 301-Antworten dauerhaft im zweistelligen Prozentbereich, verweisen interne Verweise noch auf alte Pfade - eine Aufgabe für die interne Verlinkung, nicht für die Weiterleitungstabelle. Und ein Block von 500er-Antworten, der sich auf wenige Minuten häuft, gehört in die Überwachung von Erreichbarkeit und Ladezeit und nicht in die SEO-Auswertung.
- Abrufe je Statuscode und Woche. Trendbrüche zeigen Relaunch-Reste und Serverprobleme, bevor sie in der Sichtbarkeit ankommen.
- Verhältnis Dokument zu Ressource. Holt ein Crawler überwiegend Bilder und Skripte, stimmt die Priorisierung der Verweise nicht.
- Erstabruf neuer Produkte. Die Spanne zwischen Anlage und erstem Abruf beantwortet die Frage, ob die Struktur trägt.
- Adressen ohne einen einzigen Abruf. Der Abgleich der Sitemap gegen das Protokoll benennt genau die Seiten, die noch kein Crawler gesehen hat.
Verifizieren statt glauben
Die Client-Kennung ist ein Textfeld, das jeder setzen kann. Ein nennenswerter Teil der Zugriffe, die sich als Suchmaschine ausgeben, kommt aus Netzen, die keiner Suchmaschine gehören - dieselbe Auswertung, die schädlichen Bots 37 Prozent des Verkehrs zuordnet (Imperva), erklärt auch, warum eine Kennung allein nichts beweist. Der belastbare Weg ist die Rückwärtsauflösung der Absender-Adresse mit anschließender Vorwärtsprüfung: Der ermittelte Name muss zur erwarteten Domain gehören, und dieser Name muss wieder auf dieselbe Adresse zeigen. Erst dann darf eine Zeile als Suchmaschinenabruf gezählt werden.
host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1Für die laufende Auswertung genügt es, das Ergebnis je Netzbereich zu speichern statt je Zeile - sonst dauert die Prüfung länger als die Auswertung selbst. Wer den Schritt überspringt, misst hinterher einen Crawl-Anstieg, den es nicht gab, und leitet daraus Maßnahmen ab, die nichts bewirken. Für die Abwehrschicht gilt dieselbe Überlegung wie bei individuell entwickelten Anwendungen: Der Filter gehört vor die Anwendung, nicht in sie.
Was die Fehlerseite des Protokolls verrät
Google wertet eine Fehlerkategorie als Problem, wenn an einem Tag mehr als 5 Prozent aller Anfragen dort scheitern, etwa bei der DNS-Auflösung (Google Search Console-Hilfe). Diese Schwelle lässt sich im eigenen Protokoll nachbilden, und zwar feiner: je Vorlage, je Verzeichnis, je Tageszeit. Besonders lohnend ist die Suche nach Antworten, die formal richtig und inhaltlich falsch sind. Eine Fehlseite, die als Erfolg ausgeliefert wird, wird weiter abgerufen und verbraucht Budget (Google Search Central); im Protokoll fällt sie nur über die Antwortgröße auf.
| Beobachtung im Protokoll | Wahrscheinliche Ursache | Prüfung | Folge bei Nichtstun |
|---|---|---|---|
| 200 mit auffällig kleiner Antwort | Fehlseite oder leere Trefferliste | Antwortgröße je Vorlage vergleichen | Adresse bleibt in der Warteschlange |
| Viele 301 in einem Verzeichnis | alte interne Verweise | Verweisziele im Quelltext prüfen | Budget fließt in Weiterleitungen |
| 429 oder 5xx in Wellen | Überlast oder Drosselung | Antwortzeit je Stunde auswerten | die Crawl-Rate sinkt |
| 404 mit Referrer aus dem Shop | defekte interne Verweise | Referrer-Feld gruppieren | Besucher und Crawler laufen ins Leere |
Der Vollständigkeit halber gehört die Gegenrichtung dazu: Adressen, die zwar existieren, im Protokoll aber überhaupt nicht auftauchen. Sie entstehen, wenn eine Seite weder in der Sitemap steht noch intern verlinkt ist. Eine einzelne Sitemap fasst höchstens 50.000 Adressen oder 50 Megabyte (Google Search Central) - große Sortimente brauchen also mehrere Dateien und einen Index darüber. Fehlt er, bleibt ein Teil des Katalogs unentdeckt, und im Protokoll ist das genau die Leerstelle, die niemand sucht. Wie eng das mit doppelten Inhalten zusammenhängt, zeigt der Beitrag zu Produktvarianten und doppelten Inhalten.
Aufbewahrung, Datenschutz und der richtige Zuschnitt
Ein Zugriffsprotokoll enthält Absender-Adressen und damit personenbezogene Daten. Für die SEO-Auswertung wird die vollständige Adresse an genau einer Stelle gebraucht: bei der Verifizierung der Crawler. Danach genügt das Ergebnis dieser Prüfung. Ein sauberer Zuschnitt trennt deshalb zwei Ströme - ein kurzlebiges Rohprotokoll für Betrieb und Sicherheit und eine gekürzte, um die Adressen bereinigte Fassung für die Auswertung über Monate. Welche Fristen dabei zusammenkommen und wie sie sich ohne Datenverlust umsetzen lassen, behandelt der Beitrag zum Löschkonzept und den Aufbewahrungsfristen.
Das Rohprotokoll bleibt kurz und dient dem Betrieb. Parallel entsteht eine verdichtete Fassung ohne Absender-Adresse: Datum, Stunde, Pfadmuster, Statuscode, Antwortgröße, Antwortzeit und die verifizierte Crawler-Klasse. Diese Fassung ist klein genug für Jahre, beantwortet jede SEO-Frage und macht die Auswertung unabhängig von der Aufbewahrungsfrist des Rohbestands. Beim Aufbau hilft dieselbe Reihenfolge, die auch die Zustellbarkeit der Shop-Mails verlangt: erst alle Quellen erfassen, dann die Kette bauen.
Wo das Protokoll blind ist
Ein eigenes Protokoll zeigt nur, was den eigenen Server erreicht. Liegt ein Auslieferungsnetz davor, beantwortet dieses einen Teil der Anfragen selbst, und im Ursprungsprotokoll fehlt dieser Teil. Wie oft das vorkommt, lässt sich beziffern: Nur 35 Prozent der HTML-Auslieferungen laufen über ein Auslieferungsnetz, der Rest kommt direkt vom Ursprungsserver (Web Almanac). Bei rund zwei Dritteln der Auftritte steht der Crawler-Zugriff also vollständig im eigenen Protokoll; beim übrigen Drittel muss die Auswertung beide Quellen zusammenführen. Wer die Zwischenschicht ohnehin betreibt, findet die Abwägung im Beitrag zur Cache-Architektur im Shop.
Die zweite Blindstelle ist das Rendern. Ressourcen wie Stilvorlagen und Skripte hält der Rendering-Dienst bis zu 30 Tage vor, unabhängig von den HTTP-Cache-Anweisungen (Google Search Central). Ein Skript, das heute getauscht wird, kann also wochenlang keinen einzigen Abruf im Protokoll erzeugen und trotzdem beim Rendern verwendet werden - in einer veralteten Fassung. Umgekehrt ist der Anteil der Abrufe, die aus einem Zwischenspeicher beantwortet werden können, verschwindend gering: vor zehn Jahren waren es 0,026 Prozent, inzwischen sind es 0,017 Prozent aller Abrufe (Google Search Central). Praktisch bedeutet das: Fast jeder Crawler-Abruf erreicht wirklich den Server, und fast jeder hinterlässt eine Zeile.
Ein Vorgehen für die ersten vier Wochen
Eine Logfile-Auswertung scheitert selten an der Technik und oft an der Reihenfolge. Wer mit der Frage nach dem Crawl-Budget beginnt, misst Rauschen. Wer mit dem Zuschnitt beginnt, hat nach vier Wochen eine Zeitreihe, die trägt - und einen Ausgangswert, gegen den sich jede spätere Änderung messen lässt.
- Woche 1, Erfassung. Ein eigenes Protokollformat mit Antwortzeit und Antwortgröße einrichten, Rotation und Aufbewahrung festlegen, die Ströme für Betrieb und Auswertung trennen.
- Woche 2, Verifizierung. Crawler-Kennungen sammeln, per Rückwärts- und Vorwärtsauflösung bestätigen, das Ergebnis je Netzbereich speichern.
- Woche 3, Struktur. Abrufe je Verzeichnis, Statuscode und Vorlage auswerten, Filter- und Suchadressen getrennt zählen, Sitemap gegen Protokoll abgleichen.
- Woche 4, Entscheidung. Regeln anpassen, Weiterleitungen bereinigen, langsame Vorlagen priorisieren. Ein strukturierter SEO-Audit für den Shop ordnet die Befunde in den größeren Zusammenhang ein.
Was der Blick ins Protokoll im Alltag ändert
Der wirtschaftliche Rahmen ist nicht klein: Der deutsche Onlinehandel setzte zuletzt 92,3 Milliarden Euro netto um, ein Zuwachs von 3,9 Prozent (HDE), und der Onlineanteil am gesamten Einzelhandel lag bei 13,5 Prozent (HDE). In einem Markt dieser Größe ist jede Kategorie, die ein Crawler nicht erreicht, eine Position, die im Wettbewerb fehlt. Das Protokoll beantwortet dabei keine Frage nach Ranking oder Umsatz - es beantwortet die Vorfrage: Ist die Seite überhaupt abgerufen worden, in welchem Zustand, wie oft und mit welchem Ergebnis? Erst danach lohnt die Diskussion über Inhalte.
Für den laufenden Betrieb genügt anschließend ein schmaler Bericht: Abrufe je Crawler-Klasse, Statusverteilung, Antwortzeit je Vorlage, Erstabruf neuer Adressen. Vier Werte, monatlich, gegen den eigenen Ausgangswert gemessen. Bricht einer davon aus, ist die Ursache in der Regel schnell gefunden - vorausgesetzt, das Protokoll war vorher da. Wer den Aufbau nicht selbst stemmen möchte, kann die technische Suchmaschinenoptimierung und den Betrieb der Shop-Plattform zusammen betrachten; eine Bestandsaufnahme im Gespräch klärt typischerweise rasch, welcher der vier Werte zuerst gebraucht wird.
Google Search Central: Inside Googlebot: demystifying crawling, fetching, and the bytes we process (2026), Crawling December: HTTP caching und The how and why of Googlebot crawling (2024), How Google interprets the robots.txt specification, Large site owner's guide to managing your crawl budget sowie Build and submit a sitemap (2026). Google Search Console-Hilfe: Bericht Crawling-Statistiken (2026). IETF: RFC 9309 - Robots Exclusion Protocol (2022), Abschnitte 2.3.1.2, 2.4 und 2.5. Web Almanac 2025, Kapitel SEO, Page Weight, CDN und Ecommerce, Datenbestand 16.213.084 Websites. Cloudflare Radar: The 2025 Cloudflare Radar Year in Review (Dezember 2025). Imperva: 2025 Bad Bot Report mit Netzwerkdaten des Jahres 2024. HDE: Online-Monitor 2026. Alle Zahlen sind mit Tieflink und wörtlichem Zitat im Quellverzeichnis dieses Beitrags hinterlegt.
Sie ist ein guter Einstieg, aber ein Ausschnitt. Der Bericht führt nur die 20 untergeordneten Domains mit den meisten Zugriffen der letzten 90 Tage auf (Google Search Console-Hilfe), und Google selbst hält ihn bei Websites mit weniger als 1.000 Seiten in der Regel für entbehrlich (Google Search Console-Hilfe). Vor allem berichtet er über einen einzigen Anbieter. Alles, was sonst anklopft - Preisvergleiche, Scanner, Trainings-Crawler - steht ausschließlich im eigenen Protokoll.
Eine gezielte Budgetsteuerung hält Google erst ab etwa einer Million eindeutiger Seiten mit wöchentlich wechselnden Inhalten für nötig, bei sehr schnell wechselnden Inhalten bereits ab 10.000 eindeutigen Seiten (Google Search Central). Die Auswertung selbst lohnt typischerweise deutlich früher: Fehlerbilder, tote Verweise und langsame Vorlagen zeigen sich unabhängig von der Sortimentsgröße. Einen Rahmen dafür gibt ein strukturierter Shop-Audit.
Über die Kennung allein gar nicht, denn sie ist frei setzbar. Belastbar ist die Rückwärtsauflösung der Absender-Adresse mit anschließender Vorwärtsprüfung: Der ermittelte Name muss zur erwarteten Domain gehören und wieder auf dieselbe Adresse zeigen. Dass sich der Aufwand lohnt, zeigt der Anteil schädlicher Bots von 37 Prozent am gesamten Verkehr (Imperva).
Getrennt betrachtet: Das Rohprotokoll mit Absender-Adressen bleibt so kurz wie betrieblich vertretbar, weil es personenbezogene Daten enthält. Die verdichtete Fassung ohne Adressen darf lange bleiben und trägt die Zeitreihe. Welche Fristen im Shop zusammenkommen, ordnet der Beitrag zum Löschkonzept und den Aufbewahrungsfristen ein.
Nur bei denen, die sich an die Datei halten - sie ist eine Bitte, keine Sperre. In 77,04 Prozent der Dateien im Netz steht ohnehin nur der Sammelplatzhalter (Web Almanac), Googlebot wird lediglich in 6,66 Prozent namentlich angesprochen (Web Almanac). Wer den Zugriff wirklich unterbinden will, arbeitet vor der Anwendung, etwa über Netzbereiche und Taktbegrenzung. Für Trainings-Crawler kommt die rechtliche Seite hinzu, die den Nutzungsvorbehalt betrifft.
Zuerst prüfen, ob sie in einer Sitemap stehen und intern erreichbar sind. Eine einzelne Sitemap fasst höchstens 50.000 Adressen oder 50 Megabyte (Google Search Central), größere Sortimente brauchen mehrere Dateien mit einem Index darüber. Danach ist es meist eine Frage der internen Verlinkung: Was von keiner Seite aus erreichbar ist, wird in der Regel auch nicht abgerufen.