Was ist die Logfile-Analyse?

Die Logfile-Analyse besteht darin, das Protokoll zu lesen, das der Server bei jeder Anfrage schreibt: eine Seite, ein Bild, ein PDF, eine Datei, die es nicht mehr gibt. Jede Anfrage hinterlässt eine Zeile, und diese Zeilen zusammen erzählen, was tatsächlich geschah, nicht was geschehen sollte.

Der Unterschied zu jedem Werkzeug der Web-Analyse liegt in der Herkunft. Die Analyse braucht einen Browser, der ein Skript ausführt; das Protokoll entsteht vorher, am Server, ohne jemanden um Erlaubnis zu fragen. Deshalb sieht es, was die andere nicht sehen kann.

Und was sie nicht sehen kann, ist genau das, was im technischen SEO zählt: der Besuch des Crawlers. Googlebot führt kein Messskript aus, in der Analyse existiert er also nicht. Im Protokoll hinterlässt er jede Anfrage mit Uhrzeit, genauer URL und dem Code, den er bekam.

Zuerst gehört gesagt, was sie NICHT ist. Kein Marketingwerkzeug und keine Quelle für Themenideen: Das Protokoll weiß nicht, wonach jemand gesucht hat, kennt keine Suchbegriffe und unterscheidet keinen zufriedenen von einem enttäuschten Besuch. Es beantwortet eine einzige Familie von Fragen, die technische, und darin ist es unschlagbar.

Sie ist auch keine Erfindung des SEO. Das Protokoll gibt es, seit es Server gibt, und es wird gleich geschrieben, ob jemand es liest oder nicht. Das Einzige, was dieses Fach beisteuert, ist die Gewohnheit, mit einer konkreten Frage hineinzusehen, statt es zu öffnen, wenn schon etwas kaputt ist.

Apache und nginx schreiben standardmäßig dasselbe Format, combined genannt. Eine Zeile bringt fünf Angaben, die sich lohnen, und sie auf einen Blick lesen zu können ist die halbe Arbeit: wer angefragt hat, wann, was, was er bekam und wer zu sein behauptet wird.

Das letzte Feld, die Kennung des Programms, stiftet die meiste Verwirrung. Es ist eine Zeichenkette, die der Anfragende frei wählt, jeder kann sich also Googlebot nennen. Bevor man diese Besuche zählt, gehört die IP gegen die offiziellen Bereiche geprüft, sonst misst der Bericht den, der die Website kopiert, statt den, der sie indexiert.

Das Protokoll erfasst auch die Anfragen, die keine Seiten sind: Stilvorlagen, Bilder, Schriften und die Dateien, die sich nur über das X-Robots-Tag steuern lassen. Es ist der direkteste Weg herauszufinden, welcher Teil des Crawl-Budgets in Dinge geht, die kein Inhalt sind.

Zwei weitere Felder stehen in der Zeile und werden leicht übersehen. Die Größe der Antwort in Bytes unterscheidet eine vollständige Seite von einem Fehler mit leichter Vorlage, und ein plötzlicher Einbruch dieser Zahl verrät meist eine kaputte Vorlage, bevor sie jemand meldet.

Das andere ist der Verweisende, also die URL, von der aus man kam. Beim Verkehr aus Browsern gibt es Hinweise auf eingehende Verweise; beim Crawler ist es meist leer, und auch das sagt etwas: Die Suchmaschine kam nicht über einen Verweis dieser Sitzung, sondern aus ihrer eigenen Liste bekannter URLs. Steht doch ein Wert darin, zeigt er, welche interne Seite dorthin führte — zu lesen zusammen mit der internen Verlinkung.

Es gibt Fragen, die nur das Protokoll mit Tatsachen beantwortet. Die erste: Welche Seiten crawlt Google, und wie oft? Fast immer zeigt sich ein unangenehmes Ungleichgewicht, mit wichtigen Bereichen einmal im Monat und wertlosen URLs täglich.

Die zweite: Was findet er vor, wenn er ankommt? Hier kommen die 404-Fehler heraus, die niemand gemeldet hat, die zeitweiligen 500-Fehler mitten in der Nacht und die Weiterleitungsketten, die der Crawler jedes Mal ganz durchläuft.

Und die dritte, die am meisten überrascht: Welche URLs fordert er an, von denen du nichts wusstest? Kombinationen von GET-Parametern, Fassungen mit und ohne Schrägstrich am Ende, Pfade aus einer Migration von vor zwei Jahren. Alle verbrauchen Crawling, und keine steht in einer Liste veröffentlichter Seiten.

Eine vierte Frage wird selten gestellt, und das Protokoll beantwortet sie besser als alles andere: Zu welcher Uhrzeit ist der Server langsam? Gruppiert man die Antwortzeit nach Stunden, zeigt sich, ob das Crawling mit der nächtlichen Sicherung zusammenfällt oder mit dem schweren Verarbeitungslauf um drei. Fällt es zusammen, ist der TTFB, den die Suchmaschine misst, nicht der, den deine Besucher erleben.

Und eine fünfte, nützlich nach jeder größeren Änderung: Wie lange braucht Google, um es mitzubekommen? Nach der Veröffentlichung eines neuen Bereichs zeigt das Protokoll den genauen Tag, an dem er angefordert wurde, und wie oft es wiederkam. Das ist ein unmittelbares Maß dafür, ob die Entdeckung funktioniert, ohne von der Verzögerung der Search Console abzuhängen.

Zuerst braucht man die Dateien, und das ist meist der langsamste Teil. Sie liegen auf dem Server, werden alle paar Tage gedreht und gepackt, und wenn niemand sie aufhebt, sind sie weg. Bevor man etwas auswertet, stellt man sicher, dass sie mindestens einen Monat aufbewahrt werden.

Dann wird gefiltert: die Anfragen geprüfter Suchmaschinen behalten und Seiten von Ressourcen trennen. Damit lassen sich die Fragen von oben beantworten, gruppiert nach URL, nach Tag und nach Antwortcode. Eine Tabellenkalkulation trägt eine kleine Website; ab einer gewissen Größe braucht es ein Werkzeug, das dafür gebaut ist.

Und es lohnt der Abgleich mit dem, was schon da ist: die Sitemap, der Abdeckungsbericht der Search Console und der tatsächliche Traffic. Eine URL, die Google täglich crawlt, aber nicht in die Indexierung nimmt und die keine Besuche bekommt, ist eine konkrete Frage; das Protokoll macht sie nur sichtbar.

Ein Hinweis zum Filtern, der falsche Schlüsse erspart: Man entscheidet früh, was als „eine Seite“ gilt. Zählt man Anfragen nach Bildern, Stilvorlagen und Schriften zusammen mit denen nach Inhalten, gerät jedes Verhältnis schief, denn eine einzige Seite zieht zwanzig Ressourcenanfragen nach sich.

Und eine Empfehlung zur Darstellung. Eine nach Anfragezahl sortierte URL-Liste beeindruckt und sagt nichts; verstanden wird die Verteilung nach Bereichen, der Verlauf über Wochen und die kurze Liste der URLs, die Crawling bekommen, ohne etwas hervorzubringen. In einer Prüfung zum technischen SEO passen diese drei Ansichten auf eine Seite und tragen die Entscheidungen.

Der teuerste ist, das Protokoll für eine anonyme Angabe zu halten. Eine IP-Adresse identifiziert häufig genug eine Person, ein Logfile ist damit eine Sammlung personenbezogener Daten im Sinne der DSGVO: mit Aufbewahrungsfrist, Rechtsgrundlage und beschränktem Zugang. Es komplett in eine geteilte Tabelle zu exportieren ist ein Problem, keine Abkürzung.

Der zweite ist, als Suchmaschine zu zählen, was es nur behauptet. Ohne Prüfung der IP mischt der Bericht das echte Crawling mit dem dessen, der den Katalog kopiert, und die Schlüsse über die Besuchshäufigkeit fallen zu hoch aus.

Und der dritte ist, einen einzigen Tag anzusehen. Crawling ist von Natur aus ungleichmäßig: Ein beliebiger Dienstag sagt nichts, während vier zusammenhängende Wochen ein Muster zeigen. Aus einer kurzen Stichprobe zu schließen entspricht der Entscheidung über das Klima anhand eines Blicks aus dem Fenster.

Ein vierter Fehler, leiser: „Google crawlt es nicht“ mit „Google kann es nicht crawlen“ zu verwechseln. Dass eine URL in vier Wochen Protokoll nicht auftaucht, kann heißen, dass sie in der robots.txt gesperrt ist, dass niemand auf sie verweist, oder schlicht, dass die Suchmaschine sie nicht für vorrangig hielt. Drei verschiedene Ursachen mit drei verschiedenen Lösungen, und das Protokoll allein sagt nicht, welche vorliegt.

Und der letzte, der häufigste von allen: auswerten, ohne vorher entschieden zu haben, was man wissen will. Eine Datei mit mehreren Millionen Zeilen liefert Antworten auf jede Frage, die man ihr stellt, auch auf die belanglosen. Die Frage aufzuschreiben, bevor man die Datei öffnet, trennt einen brauchbaren Bericht von einer Sammlung von Diagrammen.