http-analyze: Logfile-Analyse und Webstatistik im Wandel

Jeder Webserver führt Buch. Ruft ein Nutzer eine Webseite oder ein Bild ab, schreibt er automatisch einen Eintrag in sein Access-Log. Dafür braucht es weder ein Skript im Browser noch ein Cookie. Wer diese Logfiles auswertet, betreibt Logfile-Analyse, die älteste Form der Webstatistik. Ende der Neunzigerjahre lag unter dieser Adresse die Projektseite eines solchen Programms: http-analyze. Der Artikel erzählt, was solche Tools damals konnten. Danach geht es um den Aufbau eines Eintrags und darum, wofür sich die Analyse der Logfiles heute wieder lohnt.

Was war http-analyze?

http-analyze war ein Log-Analyzer: Das Programm las die Logfiles eines Webservers ein und generierte daraus HTML-Berichte mit Tabellen und Grafiken. Entwickelt und vertrieben hat das Programm die Firma RENT-A-GURU. Mit diesem Anbieter und mit der Software hat netstore.de heute keine Verbindung; die Adresse wurde später neu vergeben, und diese Seite schildert die Geschichte des Tools als Stück Technikgeschichte.

Ein Archivstand der Projektseite von 1999 beschreibt die Version 2.01 als komplett neu geschriebene Fassung und meldet bereits die Auslieferung von Version 2.2. Zu den Funktionen gehörten damals:

• eine Oberfläche mit Frames, über die man bequem zwischen den Statistikberichten wechselte, daneben eine klassische Ansicht ohne Frames
• die Berechnung von Pageviews und Sessions, zusammengefasst in drei Detailstufen: Top-N-Liste, Übersicht und ausführliche Liste
• Unterstützung für Server-Antworten nach HTTP/1.1
• ein frei konfigurierbares Layout der Berichte; für Provider gab es eine kommerzielle Fassung mit Handbuch, Support und Updates
• das integrierte Programm 3Dstats, das aus bestimmten Werten ein 3D-Modell im Format VRML 2.0 erzeugt

Gerade der letzte Punkt zeigt den Zeitgeist. Statt eines flachen Balkendiagramms konnte man mit einem VRML-Viewer durch die Zugriffe eines Monats „laufen“. Mehr dazu steht auf der Seite zu 3Dstats und seinen VRML-Modellen.

analog, Webalizer, AWStats: die Werkzeuge der ersten Generation

http-analyze war nicht allein. Mitte der Neunziger entstanden mehrere Programme nach demselben Prinzip. Sie lasen das Logfile ein und zählten, was darin enthalten war. Die Auswertung lief meist nachts per Cronjob, das Ergebnis landete als statische Webseite auf dem Webspace.

Programm	Erschienen	Sprache	Lizenz	Typisch
analog	1995	C	GPL	sehr schnell, nüchterne Textberichte
http-analyze	Version 2.x Ende der 1990er	–	kommerzielle Fassung für Provider	Frames-Berichte, Pageviews, Sessions, 3D-Modelle
Webalizer	1997	C	GPL	schlichte Monatsberichte mit Balken und Tabellen
AWStats	2000	Perl	GPL	viele Kennzahlen, erkennt Browser, Betriebssysteme und Robots
GoAccess	2010	C	MIT	Auswertung live im Terminal oder als HTML-Seite

Webalizer und AWStats tauchen bis heute in manchen Hosting-Oberflächen auf. Die Berichte sehen altmodisch aus. Für eine kleine Website reichen sie trotzdem oft, denn die wichtigsten Werte sind enthalten: Zugriffe pro Monat, meistgefragte Seiten, Fehlercodes und verweisende Seiten.

Wie ist eine Zeile im Access-Log aufgebaut?

Fast alle Tools verstehen das sogenannte Common Log Format (CLF), das auf den NCSA-Server zurückgeht. Das Combined Log Format hängt zwei Felder an: den Referrer und den User-Agent. Die Dokumentation des Apache HTTP Servers zu den Logdateien erklärt beide Formate Feld für Feld. Ein Beispiel für einen Eintrag in den Access Logs im Combined-Format:

198.51.100.23 - - [14/Mar/2026:09:41:07 +0100] "GET /ratgeber/router-einrichten/ HTTP/1.1" 200 18342 "https://www.google.de/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

Von links nach rechts stehen darin:

1. IP-Adresse des Clients (hier aus einem Adressbereich für Dokumentationszwecke)
2. Identität nach RFC 1413 und Benutzername, meist beide als Bindestrich leer
3. Zeitstempel mit Zeitzone
4. Abruf: Methode, Pfad der aufgerufenen Seite (die URL ohne Domain) und Protokoll
5. Status-Code der Antwort des Servers, etwa 200, 301, 404 oder 500
6. Größe der Antwort in Byte
7. Referrer, also die Seite, von der der Besucher kam
8. User-Agent: verwendeter Browser oder Bot

Jede Logdatei besteht aus Tausenden identisch aufgebauter Zeilen dieser Art. Ein Log-Analyzer zerlegt sie in die einzelnen Elemente und fasst sie etwa nach URL oder Status-Code zu Statistiken zusammen.

Hits, Pageviews, Sessions: Welche Zahl zählt?

Die frühen Statistiken warben gern mit Hits. Ein Hit ist jeder einzelne Abruf einer Datei. Ruft ein Besucher eine Seite mit 20 Bildern, zwei Stylesheets und einem Skript auf, entstehen 24 Hits. Für die Frage, wie viele Nutzer eine Seite eigentlich gelesen haben, taugt diese Zahl kaum.

• Hits: alle Abrufe, inklusive Bilder, CSS-Dateien und Fehlerantworten
• Pageviews: nur Aufrufe echter Seiten, ohne eingebettete Dateien
• Sessions: zusammenhängende Besuche, meist über IP-Adresse und User-Agent erkannt und nach einer Pause (häufig 30 Minuten) beendet

Programme wie http-analyze rechneten deshalb früh Pageviews und Sessions aus. Sessions bleiben in Logfiles eine Schätzung, und die möglichen Fehlerquellen sind bekannt: Viele Nutzer hinter einem Proxy teilen sich eine Adresse, und ein Smartphone wechselt seine IP unterwegs mehrmals.

Logfile-Analyse heute: Bots, Fehler und Crawling

Mit Google Analytics und ähnlichen Diensten rückten die Logfiles für viele Jahre in den Hintergrund. Im technischen SEO holt man sie wieder hervor, denn dort zählt, was Crawler genau tun. Nur die Logfiles zeigen, welche URLs der Googlebot tatsächlich abruft und wie oft eine URL gecrawlt wird. Ein Crawler führt kein Tracking-Skript aus, taucht also in Google Analytics oder Matomo-Tracking gar nicht auf.

Typische Fragen einer Logfile-Analyse für SEO:

• welche Seiten gecrawlt werden und welche wichtigen Seiten selten oder nie
• wie viele Abrufe auf 404-Fehler, Weiterleitungsketten oder Serverfehler laufen und wo technische Probleme liegen
• ob URLs mit Parametern oder Duplicate Content unnötig oft gecrawlt werden
• ob neue oder aktualisierte Inhalte zügig gecrawlt werden
• welche KI-Crawler die Seite abrufen; eine Übersicht bietet der Beitrag die KI-Crawler im Serverlog und was man ihnen erlaubt

Vorsicht beim User-Agent: Er lässt sich fälschen. Ob ein Zugriff wirklich vom Googlebot kommt, prüfen Sie per Reverse-DNS-Abfrage, die auf googlebot.com oder google.com enden muss, oder über die IP-Listen, die Google veröffentlicht. Die Google Search Console zeigt zwar Crawling-Statistiken, allerdings nur zusammengefasst und mit einer Auswahl von Beispiel-URLs.

Für die Analyse gibt es heute mehrere Tools. GoAccess liest Logfiles direkt auf dem Webserver und zeigt eine Live-Übersicht im Terminal. Der Screaming Frog Log File Analyser importiert Logfiles per Drag-and-drop und gleicht die Daten mit einem eigenen Crawl der Website ab. Für große Datenmengen setzen Teams den ELK-Stack aus Elasticsearch, Logstash und Kibana ein. Matomo bietet einen Import von Logfiles an, sodass sich die gewohnten Matomo-Berichte ganz ohne Tracking-Code im Browser füllen lassen.

Serverseitig oder per JavaScript auswerten?

Beide Verfahren messen Unterschiedliches. Welche Informationen Sie jeweils bekommen, zeigt die Tabelle:

Kriterium	Logfile-Analyse	JavaScript-Tracking
Bots und Crawler	vollständig sichtbar	fast unsichtbar
Adblocker, abgelehnte Einwilligung	kein Einfluss	Lücken in den Daten
Cookies im Browser	keine	meist ja
Verweildauer, Scrolltiefe, Klicks	kaum messbar	gut messbar
Seiten aus Browser- oder CDN-Cache	fehlen im Logfile des Ursprungsservers	werden erfasst

Beim Datenschutz hat die serverseitige Auswertung einen klaren Vorteil. Sie liest nichts aus dem Endgerät aus und setzt keine Cookies; ein Banner nach § 25 TDDDG braucht sie dafür nicht. Frei von der DSGVO ist sie trotzdem nicht, denn IP-Adressen gelten als personenbezogene Daten. In der Praxis heißt das: Zweck und Rechtsgrundlage in der Datenschutzerklärung nennen, gespeicherte Adressen kürzen und die Logfiles nach einer festen, kurzen Frist löschen. Wer zusätzlich Tracking einsetzt, sollte sich mit der Cookie-Akzeptanz und einem sauber gestalteten Banner beschäftigen.

Für kleinere Websites lohnt sich eine regelmäßige Logfile-Analyse als Grundausstattung. Kampagnen und Klickwege misst sie schlecht. Bei Reichweite, Fehlern und Bot-Verkehr ist sie dafür die zuverlässigere Quelle, weil Adblocker und abgelehnte Banner keine Lücken reißen. Wer beide Verfahren kombiniert, kann die Zahlen gegeneinander prüfen.

Checkliste: So starten Sie mit der Logfile-Analyse

• Beim Hoster nachsehen, wo die Access-Logs liegen und wie lange sie aufbewahrt werden; manche Pakete löschen sie automatisch nach wenigen Tagen
• Format prüfen: Welches Log Format verwendet der Webserver? Bei Nginx steht es in der Direktive log_format
• Logfiles mindestens einen Monat lang sichern, falls der Hoster sie früher löscht; erst dann werden Muster sichtbar
• Mit einem Werkzeug starten: GoAccess für den schnellen Überblick, Screaming Frog für SEO-Fragen, Matomo für klassische Berichte
• Zuerst Status-Codes und die meistgecrawlten URLs ansehen, danach Bots nach User-Agent und IP prüfen
• Ergebnisse mit den Daten aus der Google Search Console abgleichen
• gefundene Fehler beheben, Weiterleitungen und interne Links optimieren, die Analyse regelmäßig wiederholen
• Datenschutzerklärung und Löschfristen anpassen

Wer tiefer in die Optimierung einsteigen möchte, findet die Grundlagen im Beitrag Suchmaschinenoptimierung: Was ist das und worauf kommt es an? Ein Eintrag im Access-Log sieht übrigens fast genauso aus wie zu Zeiten von http-analyze. Neu sind vor allem die Besucher, nach denen man darin sucht: Googlebot, Bingbot und eine Reihe von KI-Crawlern, die es vor wenigen Jahren noch nicht gab.