In der technischen SEO beschäftigen sich viele Analysen zuerst mit dem, was eine Suchmaschine auf einer Website theoretisch finden kann. Ich crawle eine Website mit einem Tool, untersuche Statuscodes, interne Links, Canonicals, Weiterleitungen oder die Seitentiefe und bekomme damit ein ziemlich gutes Bild der technischen Struktur.
Was ich dadurch allerdings noch nicht weiß, ist, was Google tatsächlich auf meiner Website tut.
Genau an diesem Punkt werden Server-Logfiles interessant.
Ein normaler Website-Crawl beantwortet im Kern die Frage, welche URLs ein Crawler auf meiner Website entdecken kann und welchen technischen Zustand diese URLs und deren Inhalte haben. Eine Logfile-Analyse stellt eine andere Frage: Welche URLs hat Googlebot wirklich angefordert?
Diese Unterscheidung klingt zunächst unspektakulär. Bei großen Websites verändert sie jedoch die gesamte Perspektive auf Technische SEO. Denn plötzlich betrachte ich nicht nur die Seitenarchitektur, die ich Google anbiete. Ich sehe, wie Google diese Architektur tatsächlich nutzt.
Die tatsächliche Nutzung der Website durch Googlebot
Jeder Aufruf einer URL hinterlässt auf Servern Spuren. Je nach Konfiguration (Achtung Datenschutz!) lassen sich in den Logfiles unter anderem der Zeitpunkt eines Requests, die angeforderte Ressource, der zurückgegebene HTTP-Statuscode, der User-Agent und die IP-Adresse nachvollziehen.
Damit kann beispielsweise festgestellt werden, dass Googlebot eine wichtige Kategorie-Seite gestern mehrfach aufgerufen hat, während eine andere strategisch relevante Seite seit zwei Wochen überhaupt nicht mehr besucht wurde.
Die Google Search Console (GSC) bietet mit dem Bericht zu den Crawling-Statistiken bereits einen guten Einstieg in diese Daten. Dort lassen sich Crawling-Anfragen unter anderem nach Antwortcode, Dateityp, Crawling-Zweck und Googlebot-Typ aufschlüsseln. Auch Downloadvolumen, durchschnittliche Antwortzeit und Hostprobleme werden sichtbar. (developers.google.com)
Für größere Websites reicht diese aggregierte Sicht allerdings irgendwann nicht mehr aus.
Dann möchte ich nicht nur wissen, wie viele Requests Googlebot insgesamt erzeugt. Ich möchte wissen, auf welche URLs diese Requests entfallen und welche Muster sich daraus ergeben.
Wenn die Verteilung wichtiger wird als die Gesamtzahl
Nehmen wir einen Onlineshop mit 800.000 indexierbaren URLs.
Innerhalb von 30 Tagen erzeugt Googlebot 18 Millionen Requests. Die Zahl allein klingt zunächst beeindruckend, sagt aber erstaunlich wenig aus.
Interessant wird es erst, wenn ich die Requests segmentiere.
6,2 Millionen betreffen Produktseiten, 2,1 Millionen Kategorien, 5,4 Millionen Filter- und Parameter-URLs, 2,8 Millionen URLs mit einem 301-Redirect und weitere 1,5 Millionen URLs, die einen 404 Statuscode zurückgeben.
Zusätzlich stelle ich fest, dass 35 Prozent der aktiven Produktseiten innerhalb des gesamten Monats keinen einzigen Googlebot-Request erhalten haben.
Spätestens jetzt habe ich keinen einzelnen SEO-Fehler mehr vor mir. Ich habe ein Muster.
Und genau hier unterscheidet sich eine technische Diagnose von einer bloßen Bestandsaufnahme.
Die falsche Reaktion wäre, sofort die robots.txt zu verändern, Redirects zu entfernen oder Sitemaps umzubauen. Bevor ich eine Lösung auswähle, muss ich verstehen, warum diese Verteilung überhaupt entstanden ist.
Warum crawlt Google so viele Redirects?
2,8 Millionen Requests auf URLs mit einem 301 wären für mich deshalb zunächst kein Anlass für eine sofortige Maßnahme, sondern für eine Hypothese.
Warum kennt Googlebot diese URLs und ruft diese anscheinend häufig auf?
Vielleicht verweisen interne Links noch auf alte Produktadressen. Vielleicht stehen historische URLs weiterhin in einer XML-Sitemap. Vielleicht existieren externe Links auf diese Seiten. Vielleicht handelt es sich um Altlasten eines Relaunches oder um Folgen einer früheren Änderung der URL-Struktur.
Auch Redirect-Ketten wären denkbar.
Aus
/produkt-alt/
wird zunächst
/produkt-neu/
und später:
/produkt-alt/ → 301 → /produkt-neu/ → 301 → /produkte/produkt-neu/
Google folgt permanenten Redirects und verwendet sie zugleich als starkes Signal dafür, welches Ziel künftig als kanonische URL betrachtet werden soll. Gleichzeitig empfiehlt Google, unnötig lange Redirect-Ketten zu vermeiden, weil sie das Crawling erschweren können. (developers.google.com)
Die eigentliche Frage lautet deshalb nicht: „Wie entferne ich die 301er?“
Sie lautet vielmehr:
Woher bezieht Google diese alten URLs immer wieder?
Eine Logfile-Analyse liefert mir den Befund. Um die Ursache zu finden, muss ich ihn anschließend mit interner Verlinkung, Sitemaps, externen Links und der historischen URL-Struktur verbinden.
Eine Million 404er sind ebenfalls nur der Anfang
Dasselbe gilt für 404-Requests.
Ein 404 Not Found ist zunächst kein SEO-Fehler. Seiten verschwinden. Produkte werden entfernt. URLs ändern sich. Ein korrekt ausgelieferter 404 ist in solchen Fällen vollkommen legitim. Google empfiehlt ausdrücklich, dauerhaft entfernte Inhalte ohne passenden Ersatz mit 404 oder 410 zu beantworten. (developers.google.com)
Wenn Googlebot allerdings jeden Monat 1,5 Millionen Requests auf 404-URLs erzeugt, würde ich genauer hinsehen. Auch hier interessiert mich zunächst nicht, wie ich die Zahl möglichst schnell reduziere. Ich möchte wissen, warum Google diese URLs überhaupt weiterhin findet und anscheinend auch aufsucht.
Vielleicht existieren fehlerhafte interne Links. Vielleicht erzeugen Templates weiterhin alte Produktadressen. Vielleicht enthält eine Sitemap längst entfernte Seiten. Vielleicht entstehen fehlerhafte Parameter-URLs. Vielleicht verweisen externe Links auf Inhalte, die nicht mehr existieren. Und vielleicht handelt es sich teilweise gar nicht um echte 404-Antworten.
Besonders problematisch sind sogenannte Soft-404s. Dabei zeigt eine Seite beispielsweise „Produkt nicht verfügbar“, liefert technisch aber weiterhin einen Statuscode 200 OK. Für Google sieht es damit zunächst so aus, als existiere eine reguläre Seite. Solche URLs können weiterhin gecrawlt werden und zusätzliche Crawling-Ressourcen beanspruchen. Google empfiehlt deshalb ausdrücklich, Soft-404-Probleme zu beseitigen. (developers.google.com)
Auch hier zeigt sich: Der Statuscode selbst ist noch keine Diagnose. Entscheidend ist das Muster dahinter.
35 Prozent der Produkte wurden gar nicht gecrawlt
Noch interessanter wird unser Beispiel an einer anderen Stelle. 35 Prozent der aktiven Produktseiten wurden im gesamten Untersuchungszeitraum nicht ein einziges Mal von Googlebot aufgerufen. Es wäre verlockend, sofort von einem Indexierungsproblem zu sprechen.
Genau das wäre allerdings zu früh.
Wenn Google eine URL überhaupt nicht crawlt, habe ich zunächst eine Frage der Auffindbarkeit (Discovery) und der Crawl-Priorisierung. Erst nachdem eine Seite gecrawlt wurde, stellt sich die nächste Frage: Möchte Google diese Seite anschließend indexieren?
Google weist selbst darauf hin, dass nicht jede gecrawlte Seite automatisch indexiert wird. Gleichzeitig entdeckt Google neue URLs insbesondere über Links auf bereits bekannten Seiten und über weitere Quellen wie Sitemaps. (developers.google.com)
Wenn ein erheblicher Anteil meines Produktinventars überhaupt keinen Request erhält, interessiert mich deshalb zunächst die strukturelle Frage: Sind diese Seiten für Google überhaupt ausreichend auffindbar und wichtig genug, um regelmäßig berücksichtigt zu werden?
Vielleicht liegen sie sehr tief in der Websitearchitektur. Vielleicht sind sie nur schwach bis gar nicht intern verlinkt. Vielleicht fehlen sie in der XML-Sitemap. Vielleicht blockiert die robots.txt bestimmte Bereiche. Vielleicht entstehen manche URLs erst durch JavaScript oder Benutzerinteraktionen. Vielleicht verweisen Canonicals auf andere Seiten. Oder die Website besitzt schlicht ein so großes und redundantes URL-Inventar, dass Google viele dieser Produkte als wenig relevant einstuft.
Google beschreibt das wahrgenommene URL-Inventar ausdrücklich als einen der Faktoren, auf die Betreiber großer Websites erheblichen Einfluss haben. Wenn Google sehr viele doppelte, entfernte oder unwichtige URLs kennt, kann viel Crawling-Aktivität auf genau diese Bereiche entfallen. (developers.google.com)
Die Aussage „35 Prozent wurden nicht gecrawlt“ reicht deshalb noch nicht. Ich muss wissen, welche 35 Prozent.
Segmentierung macht aus Daten eine Diagnose
Vielleicht stelle ich bei einer weiteren Analyse fest, dass Produktkategorie A zu 96 Prozent gecrawlt wurde, Kategorie B zu 88 Prozent und Kategorie C nur zu 27 Prozent.
Dann verändert sich die Frage sofort.
Jetzt habe ich keinen allgemeinen Crawl-Budget-Verdacht mehr, sondern einen konkreten Bereich der Website, den ich untersuchen kann.
Vielleicht liegt Kategorie C deutlich tiefer in der Informationsarchitektur. Vielleicht existieren kaum interne Links. Vielleicht fehlen die Seiten in einer Sitemap. Vielleicht besitzt die Kategorie deutlich mehr Filtervarianten als andere Bereiche.
Genau deshalb ist Segmentierung bei Logfile-Analysen so wichtig.
Ein Durchschnitt über die komplette Website kann ein Problem überdecken, das innerhalb einzelner Seitentypen extrem ausgeprägt ist.
Ich möchte deshalb nicht nur wissen, wie viele Requests Googlebot erzeugt. Ich möchte verstehen, wo diese Requests landen, welche Bereiche bevorzugt werden und welche nahezu unsichtbar bleiben.
Erst dadurch entsteht ein Bild davon, wie Google meine Website tatsächlich wahrnimmt und am Ende auch nutzt.
Logfiles liefern keine Antworten, sondern bessere Fragen
Das ist für mich vielleicht der wichtigste Punkt bei der Logfile-Analyse. Die Logs sagen mir nicht automatisch, was ich tun soll.
Wenn ein großer Anteil aller Requests auf Parameter-URLs entfällt, bedeutet das nicht automatisch, dass ich sie blockieren sollte. Wenn Googlebot eine Seite selten crawlt, bedeutet das nicht automatisch, dass diese Seite ein Problem hat. Und wenn eine URL häufig gecrawlt wird, bedeutet das nicht automatisch, dass Google sie für besonders wertvoll hält.
Logfiles zeigen Verhalten.
Die Interpretation entsteht erst, wenn ich diese Daten mit weiteren Informationen kombiniere. Dazu gehören die Informationsarchitektur, interne Verlinkung, XML-Sitemaps, Canonicals, Statuscodes, Indexierungsdaten, Search-Console-Daten und gegebenenfalls die tatsächliche Veränderungsfrequenz einer Seite.
Genau deshalb sollte eine gute technische Analyse nicht mit einer Maßnahme beginnen, sondern mit einer Hypothese.
Wenn 2,8 Millionen Googlebot-Requests auf permanente Redirects entfallen, ist das zunächst ein Befund. Daraus könnte die Hypothese entstehen, dass Google weiterhin große Mengen historischer URLs über interne oder externe Quellen entdeckt. Anschließend prüfe ich, woher diese URLs stammen, ob sie noch intern verlinkt sind, ob sie in Sitemaps auftauchen oder ob Redirect-Ketten existieren.
Erst danach entscheide ich über eine Maßnahme.
Diese Reihenfolge – Befund, Hypothese, Prüfung, Maßnahme – ist für mich wesentlich sinnvoller, als direkt aus einer Kennzahl eine technische Änderung abzuleiten.
Auch der Googlebot selbst muss überprüft werden
Bei einer echten Server-Logfile-Analyse gibt es noch einen technischen Punkt, der leicht übersehen wird. Nicht jeder Request mit dem User-Agent „Googlebot“ stammt tatsächlich von Google. User-Agents lassen sich problemlos fälschen.
Google empfiehlt deshalb ausdrücklich, verdächtige Googlebot-Requests entweder über einen Reverse-DNS-Lookup zu überprüfen oder die Quell-IP mit den von Google veröffentlichten Googlebot-IP-Bereichen abzugleichen. (developers.google.com)
Gerade bei großen Datenmengen ist das relevant. Wenn ich Millionen von Requests analysiere und jeden Crawler mit „Googlebot“ im User-Agent ungeprüft einbeziehe, kann ich meine gesamte Analyse mit Bot-Traffic verfälschen, der überhaupt nicht von Google stammt.
Bevor ich also komplizierte Aussagen darüber treffe, wie Google meine Website crawlt, sollte ich zunächst sicherstellen, dass ich tatsächlich auch die Anfragen von Google messe.
Die Search Console ist der Einstieg, nicht unbedingt das Ende
Für viele Websites reicht der Bericht „Crawling-Statistiken“ der Google Search Console vollkommen aus.
Er zeigt die Entwicklung der Requests, Antwortcodes, Dateitypen, Googlebot-Typen, Hostprobleme und die durchschnittliche Antwortzeit. Damit lassen sich bereits viele Auffälligkeiten erkennen. (developers.google.com)
Je größer und komplexer eine Website wird, desto stärker wächst jedoch der Bedarf an einer URL-genauen Betrachtung.
Dann möchte ich nicht mehr nur wissen, dass beispielsweise 18 Prozent aller Requests auf 301 entfallen. Ich möchte wissen, welche URLs das konkret sind, aus welchen Bereichen sie stammen, wie häufig sie gecrawlt werden und warum Google sie weiterhin kennt.
Genau hier beginnt der eigentliche Mehrwert einer Logfile-Analyse.
Von der technischen Beobachtung zur strategischen Entscheidung
Logfile-Analyse klingt zunächst nach einem sehr technischen Spezialthema. Tatsächlich führt sie jedoch schnell zurück zu strategischen Fragen.
Wenn Googlebot Millionen von Parameter-URLs crawlt, kann dahinter ein Problem der Informationsarchitektur stecken. Wenn wichtige Produkte kaum gecrawlt werden, kann die interne Verlinkung eine Rolle spielen. Wenn alte URLs über Jahre hinweg weiter angefragt werden, kann die Website selbst noch immer widersprüchliche Signale senden.
Und wenn viele Requests auf Fehlerseiten, Redirect-Ketten oder andere technisch wenig wertvolle Bereiche entfallen, muss ich möglicherweise nicht den Googlebot optimieren. Ich muss meine Website optimieren.
Genau darin liegt für mich der Wert von Server-Logs. Sie zeigen nicht, wie meine Website meiner Meinung nach aufgebaut ist. Sie zeigen, wie Google sie tatsächlich benutzt.
Mein Fazit
Ein technischer Website-Crawl und eine Logfile-Analyse beantworten unterschiedliche Fragen.
Der Crawl zeigt mir, welche Struktur ein Crawler vorfinden kann. Die Server-Logs zeigen mir dagegen, welche Teile dieser Struktur Googlebot wirklich besucht. Gerade bei großen Websites kann dieser Unterschied entscheidend sein.
Millionen von Requests auf Redirects oder Fehlerseiten sind zunächst keine fertige Diagnose. Ebenso wenig beweist eine hohe Zahl an Parameter-Crawls automatisch verschwendetes Crawl-Budget. Und wenn ein erheblicher Anteil des Produktinventars überhaupt nicht gecrawlt wird, sollte ich nicht vorschnell von einem Indexierungsproblem sprechen.
Die eigentliche Arbeit beginnt mit der Frage nach dem Warum.
- Warum findet Google weiterhin alte URLs?
- Warum entstehen so viele Fehler-Requests?
- Warum crawlt Google bestimmte Bereiche intensiv und andere kaum?
Erst wenn ich diese Fragen beantworten kann, kann ich sinnvolle technische Maßnahmen ableiten. Und genau deshalb ist die vielleicht wichtigste Regel einer Logfile-Analyse erstaunlich einfach:
Nicht sofort reparieren. Erst verstehen, was Googlebot tatsächlich tut – und warum.
