Kernaussagen
Logfiles zeigen dir, womit sich Bots auf deiner Seite beschäftigen und wie oft sie crawlen. Ein Crawler wie Screaming Frog zeigt dir das nicht. Crawling ist begrenzt: Täglich erscheinen hunderte Millionen neue Dokumente. Die Light-Variante nutzt die Crawl-Statistiken der Google Search Console. Du findest sie unter Einstellungen, nur bei einer Domain-Property. Sie liefern bis zu 1000 Beispiel-URLs pro Ausprägung und drei Monate Verlauf. Der Ablauf hat drei Schritte: Export mit dem Chrome-Plugin von Valentin Pletzer statt bis zu 45 Einzeldateien, Aggregation per Template in Google Sheets oder n8n, Dashboard in Looker Studio. In einem Fall machten Parameter-URLs mit 301-Redirect 23 Prozent des gesamten Crawlings aus. Statuscode 410 führte in einzelnen Ergebnissen zu 50 Prozent weniger Crawling als 404. Als Zielwert nennt Björn mindestens 95 Prozent Statuscode 200, Juliane stimmt zu.
Eine Logfile-Analyse zeigt dir, was Googlebot auf deiner Website crawlt und wie oft. Juliane Bettinga nutzt dafür eine leichte Variante: die Crawl-Statistiken der Google Search Console mit bis zu 1000 Beispiel-URLs pro Ausprägung und drei Monaten Verlauf. In einem Vergleichsprojekt kam diese Light-Analyse zu nahezu denselben Erkenntnissen wie eine klassische Logfile-Analyse.
Video-Summary
Auf SEOSOON fassen wir hier die Inhalte der Folge zusammen. Björn Darko spricht darin mit Juliane Bettinga über die Logfile-Analyse light. Juliane kommt aus Jena und hat eine Boutique-Agentur für SEO mitgegründet.
Was Logfiles zeigen und warum ein Crawler nicht reicht
Juliane nennt Logfiles „unser Bild“ davon, womit sich Suchmaschinen und andere Bots beschäftigen. Für sie ist das die einzige Datenquelle mit einem umfassenden Blick in den Maschinenraum. Du siehst darin auch Ressourcen jenseits deiner sichtbaren URL-Struktur.
Ein normaler Crawler wie Screaming Frog oder Botify zeigt dir mit angebundener Inspection API höchstens das letzte Crawldatum einer URL. Wie oft Google die URL vorher abgerufen hat, siehst du dort nicht. Du erkennst auch nicht, ob Google bestimmte URLs gar nicht crawlt oder sich in Ressourcen festbeißt. Genau diese Frequenz liefert dir die Logfile-Analyse.
Warum Crawling eine begrenzte Ressource ist
Juliane sagt klar: „Crawling ist am Ende eine begrenzte Ressource.“ Täglich erscheinen hunderte Millionen neue Dokumente. Dazu kommen unzählige bekannte Dokumente, die Suchmaschinen immer wieder crawlen. Du stehst also in einem Wettbewerb um Crawling.
Verschwendest du Crawling auf unnötiges URL-Inventar, hat das vier Folgen. Google entdeckt und indexiert neue URLs zu spät, im Publishing entscheidet das über die Schlagzeilen-Box. Aktualisierungen bestehender Seiten kommen verzögert an. Crawling-Spitzen belasten den Server, treiben Kosten und können Ausfälle provozieren. Und jede unnötig gecrawlte URL erzeugt einen CO2-Fußabdruck, der sich über viele Bots potenziert.
Google Search Console Crawling: wo die Crawl-Statistiken stecken
Die Crawl-Statistiken liegen versteckt unter den Einstellungen der Google Search Console. Du siehst sie nur bei einer Domain-Property, nicht bei Verzeichnis-Properties. Dafür erfasst die Domain-Property automatisch alle Subdomains, auch APIs oder Bild-Hosts, die du nie einzeln angelegt hast.
Im Bereich Hosts zeigt dir die GSC bis zu 20 meistabgerufene Subdomains der letzten 90 Tage. Hier startet Juliane jede Analyse. Oft findet sie dort alte Stagings oder Subdomains ohne Relevanz, die Google trotzdem crawlt. Die gehören blockiert oder abgeschaltet.
Logfile-Analyse light in drei Schritten
Schritt 1: Du holst dir die Daten aus der GSC. Google teilt sie nach Dateityp, Zweck, Antwort und Googlebot-Typ auf. Jede Ausprägung enthält bis zu 1000 Beispiel-URLs. Manuell wären das bis zu 45 Exporte. Das Chrome-Plugin von Valentin Pletzer lädt alles mit einem Klick herunter.
Schritt 2: Du konsolidierst und aggregierst die Daten. Julianes Master-Template zerlegt den URL-Pfad für Verzeichnisanalysen und fasst Zeitstempel zusammen. Das klappt in Google Sheets mit Apps Script oder komfortabler in n8n.
Schritt 3: Du bindest die beiden Ergebnisdateien an Looker Studio an. Dann suchst du nach Auffälligkeiten und Ansätzen für die Optimierung. Juliane stellt das Template frei zur Verfügung, du kannst sie direkt anschreiben.
Statuscodes, Dateitypen und Top-URLs im Dashboard prüfen
Zuerst schaust du auf die Statuscode-Verteilung. Statuscode 200 und 304 sollten den Hauptanteil ausmachen. Im gezeigten Beispiel lag 200 nur bei 53 Prozent, ein klares Warnsignal. Björn nennt mindestens 95 Prozent Statuscode 200 als Ziel. Redirects und 404 sind in Maßen normal, dürfen aber nicht überwiegen.
Danach prüfst du die Dateitypen. Im Beispiel machten PDFs 6 Prozent aus, auf einer wenig bildlastigen Domain fielen auch Bilder auf. Hohe JavaScript-Anteile können auf Rendering-Probleme hinweisen. Unter den meistgecrawlten URLs tauchte zudem eine fehlerhafte CSS-Datei mit 404 auf.
Mit angebundenen GSC-Leistungsdaten siehst du, ob deine Top 10 gecrawlten URLs überhaupt Klicks bringen. Wenn nicht, solltest du deine Website-Architektur und interne Verlinkung prüfen. Gut verlinkte URLs crawlt Google häufiger. Auch die Tageszeit-Verteilung hilft dir, große Änderungen gut zu timen.
URL-Migration mit den Crawl-Statistiken begleiten
Vor einer Migration ermittelst du den Status Quo. Die GSC speichert drei Monate rückwirkend, du kannst also notfalls auch danach vergleichen. Nach dem Umzug steigt der Anteil von 301 deutlich. Steigt 404 stark, sind vielleicht Inhalte auf der Strecke geblieben.
Mit der Zeit sollte sich alles zugunsten von Statuscode 200 einpendeln. In einem Projekt lag der 404-Anteil lange bei 40 bis 50 Prozent. Erst die Umstellung auf 410 hat das Crawling spürbar entlastet. Achte auch auf mehr JavaScript- oder CSS-Crawling nach Template-Änderungen.
Crawling-Ballast reduzieren: die wichtigsten Hebel
Juliane nennt mehrere Hebel. Behebe technische Fehler wie facettierte Navigation, Kalender oder ungewollte Parameter-URLs. Sperre unnötige Verzeichnisse per robots.txt und denk bei Bedarf über Link-Maskierung nach. Baue Redirect-Ketten ab, im Republishing sind fünf bis zehn Stufen keine Seltenheit.
Nutze 410 für dauerhaft gelöschte Inhalte und 304 für unveränderte Seiten. Verlinke wichtige Seiten gut, Klicktiefe acht hilft dir nicht. Halte Ladezeit und Server-Antwortzeit im Blick. Wie du dein Crawl-Budget gezielt optimierst, vertiefen wir auf unserer eigenen Seite zum Thema Crawl-Budget.
Grenzen der GSC-Daten
Mehr als die Beispieldaten bekommst du aus den Crawl-Statistiken nicht heraus. Es gibt keine API und keinen Workaround. Ein kleiner Hack funktioniert nur mit dem Plugin: Du legst Verzeichnisse als Subfolder-Property an und ziehst die Daten pro Subfolder.
Für eine ganz detaillierte Auswertung brauchst du am Ende die klassische Logfile-Analyse. Die GSC liefert dir aber die ersten Indikatoren. Und weil Probleme meist strukturell sind, reichen die Beispieldaten oft aus.
Was ist eine Logfile-Analyse? Definition und Nutzen für SEO
Ergänzend zur Episode haben wir die Grunddefinition aus Julianes Erklärungen kompakt zusammengefasst.
Eine Logfile-Analyse wertet aus, womit sich Suchmaschinen-Bots auf deiner Website beschäftigen. Du siehst, welche URLs und Ressourcen Google abruft, wie oft und mit welchem Statuscode. Das Ziel ist Crawling-Effizienz: Google soll deine wichtigsten Seiten finden und sich nicht mit Fehlern aufhalten.
- Wie schnell findet Google eine neue URL?
- Welche Verzeichnisse crawlt Google besonders häufig?
- Gibt es Missverhältnisse beim Crawling?
- Beißt sich der Bot an fehlerhaften Ressourcen fest, etwa an einer CSS-Datei mit 404?
- Welche URLs crawlt Google gar nicht?
Klassische Server-Logfiles auswerten ist aufwendig. In Unternehmen geht es um Terabytes, oft schaffst du nur Zeiträume von einem Tag bis einer Woche. Die Light-Variante über die Google Search Console umgeht dieses Problem.
Tools für die Logfile-Analyse mit Google Search Console Daten
Ergänzend zur Episode haben wir alle genannten Werkzeuge mit ihrer Rolle in einer Übersicht gesammelt.
| Tool | Rolle in der Analyse | Hinweis aus der Folge |
|---|---|---|
| Google Search Console, Crawl-Statistiken | Datenquelle für Crawl-Anfragen, Statuscodes, Dateitypen, Crawl-Zweck | Nur bei Domain-Property, unter Einstellungen |
| Chrome-Plugin von Valentin Pletzer | Export aller Crawl-Statistik-Berichte mit einem Klick | Ersetzt bis zu 45 manuelle Exporte |
| Google Sheets mit Apps Script | Daten konsolidieren und aggregieren im Master-Template | Ein paar Daten kopierst du manuell hinein |
| n8n | Workflow für die Aggregation | Komfortabler, setzt n8n-Kenntnisse voraus |
| Looker Studio | Dashboard mit Kreuzfiltern, auch Benachrichtigungen möglich | Bekommt die zwei Ergebnisdateien |
| Screaming Frog, Botify | Klassische Crawler | Zeigen keine Crawl-Frequenz |
Juliane stellt ihr Template frei zur Verfügung. Schreib sie einfach direkt an, wenn du es nutzen willst.
Praxisbeispiel Logfile-Analyse: Parameter-URLs fressen 23 Prozent des Crawlings
Ergänzend zur Episode haben wir Julianes Fallbeispiel Schritt für Schritt aufbereitet.
- Statuscode-Verteilung prüfen: 301-Redirects machten 30 Prozent des gesamten Crawlings aus.
- Erklärbares abgrenzen: 20 Prozent Statuscode 404 passten zu einer dynamischen Seite mit täglich auslaufenden Inhalten.
- Unerklärliches markieren: Die 30 Prozent 301 ließen sich nicht erklären, es gab kein Republishing.
- Ins Detail gehen: Im Dashboard filterte das Team nach betroffenen URLs und Verzeichnissen. 301-Redirects laufen dort unter dem Dateityp „anderer Dateityp“.
- Ursache finden: Parameter-URLs mit 301-Redirect verursachten 23 Prozent des gesamten Crawls.
- Optimieren: Mit diesem Befund konnte das Team die Parameter-URLs gezielt angehen.
Die Lehre: Frag bei jeder Auffälligkeit, ob du sie erklären kannst. Einzelne URLs ruinieren selten dein Crawl-Budget. Meist steckt ein strukturelles Thema dahinter.
Discovery vs. Refresh: der Crawl-Zweck in der Google Search Console
Ergänzend zur Episode zeigen wir, warum dieser Datenpunkt ein echter Vorteil gegenüber klassischen Logfiles ist.
Klassische Logfiles verraten dir nicht, ob Google eine URL neu entdeckt oder nur aktualisiert. Die Crawl-Statistiken der GSC liefern genau diese Info: Discovery-Crawls für neue URLs, Refresh-Crawls für bekannte URLs.
- Prüfe die Verteilung pro Verzeichnis, nicht nur für die ganze Domain.
- Veröffentlichst du im Blog täglich oder wöchentlich, sollte dort der Discovery-Anteil hoch sein.
- Gleiche bei Marktplätzen den Anteil neuer Produktseiten in der Sitemap mit dem Discovery-Anteil ab.
- Passt die Verteilung nicht zu deiner Publikationsstrategie, suche nach Crawling, das in falsche Bereiche fließt.
Juliane hat nach einer Crawl-Budget-Optimierung einen deutlichen Shift gesehen. Das Verhältnis von Discovery und Refresh passte danach wieder zur Publikationsstrategie.
Wichtige Fragen und Tipps rund um die Logfile-Analyse mit der Google Search Console
Was ist eine Logfile-Analyse und wofür wird sie benötigt?
Eine Logfile-Analyse wertet aus, womit sich Suchmaschinen-Bots auf deiner Website beschäftigen. Juliane Bettinga nennt Logfiles die einzige Datenquelle, die dir ein umfassendes Bild deines Crawl-Verhaltens gibt. Du siehst darin nicht nur deine sichtbaren URLs. Du siehst auch Ressourcen wie CSS, JavaScript oder PDFs, die Bots abrufen.
Das große Ziel ist Crawling-Effizienz. Google soll deine wichtigsten Seiten finden und sich nicht mit Fehlern aufhalten. Die Analyse beantwortet dir konkrete Fragen: Wie schnell findet Google eine neue URL? Welche Verzeichnisse crawlt Google besonders oft? Beißt sich der Bot an fehlerhaften Ressourcen fest? Im Dashboard der Folge tauchte zum Beispiel eine fehlerhafte CSS-Datei mit Statuscode 404 unter den meistgecrawlten URLs auf.
Du brauchst die Analyse, weil ineffizientes Crawling echte Folgen hat. Google entdeckt neue URLs später und indexiert sie verzögert. Updates an bestehenden Seiten kommen spät an. Im Publishing entscheidet das über einen Platz in den Schlagzeilen. Dazu kommen Serverlast, Kosten und ein vermeidbarer CO2-Fußabdruck.
Juliane rät, dass auch kleinere Websites ihr Crawling mindestens einmal prüfen. Ein Newsarchiv mit rund 1000 URLs kann durch eine Filternavigation auf über eine Million URLs anwachsen. Wie du ohne riesige Server-Logs startest, zeigt dir der Abschnitt zur Logfile-Analyse light in drei Schritten.
Wie kann man mit der Google Search Console eine Logfile-Analyse durchführen?
Eine Logfile-Analyse mit der Google Search Console nutzt die Crawl-Statistiken statt echter Server-Logs. Juliane Bettinga beschreibt dafür drei Schritte. Voraussetzung ist eine Domain-Property, denn nur dort siehst du die Crawl-Statistiken unter den Einstellungen.
Schritt 1 ist der Export. Google teilt die Daten nach Dateityp, Zweck, Antwort und Googlebot-Typ auf. Jede Ausprägung enthält bis zu 1000 Beispiel-URLs. Manuell kommst du auf bis zu 45 Dateien, je nachdem, wie viele Statuscodes dein Server liefert. Das Chrome-Plugin von Valentin Pletzer lädt alle Berichte mit einem Klick gebündelt herunter.
Schritt 2 ist die Aggregation. Julianes Master-Template zerlegt den URL-Pfad, damit du Verzeichnisse auswerten kannst. Es fasst außerdem Informationen nach Zeitstempel zusammen. Du nutzt es in Google Sheets mit Apps Script oder komfortabler als n8n-Workflow.
Schritt 3 ist das Dashboard. Du bindest die zwei Ergebnisdateien an Looker Studio an. Dort filterst du kreuz und quer nach Statuscodes, Dateitypen, Verzeichnissen und Zeiträumen.
Starte die Auswertung mit der Statuscode-Verteilung und dem Bereich Hosts. Dort findest du oft schon alte Stagings oder irrelevante Subdomains. Das Template stellt Juliane frei zur Verfügung, du kannst sie direkt anschreiben. Details findest du im Abschnitt zu den Tools für die Logfile-Analyse.
Warum ist Crawling eine begrenzte Ressource?
Crawling ist eine begrenzte Ressource, weil täglich hunderte Millionen neue Dokumente erscheinen. Dazu kommen unzählige bekannte Dokumente, die Suchmaschinen immer wieder crawlen müssen. Juliane Bettinga beschreibt das als echte Wettbewerbssituation. Deine Website konkurriert mit allen anderen um die Aufmerksamkeit des Crawlers.
Verschwendest du Crawling auf unnötiges URL-Inventar, spürst du das in der Performance. Google selbst beschreibt das in seiner Dokumentation, und Juliane sieht es auch in der Praxis. Neue URLs entdeckt Google zu spät, crawlt sie zu spät und indexiert sie zu spät. Aktualisierungen an bestehenden URLs erkennt der Crawler verzögert. Gerade im Publishing, wo Aktualität zählt, kann das über die Schlagzeilen-Box entscheiden.
Unnötiges Crawling belastet außerdem deinen Server. Crawling-Spitzen können Ausfallzeiten provozieren und treiben Kosten. Und jede unnötig gecrawlte URL erzeugt einen CO2-Fußabdruck. Das betrifft nicht nur einen Bot, sondern beliebig viele, und potenziert sich in der Masse.
Was du konkret tun kannst: Behebe technische Fehler wie facettierte Navigation oder ungewollte Parameter-URLs. Sperre unnötige Verzeichnisse per robots.txt. Baue Redirect-Ketten ab und nutze 410 für dauerhaft gelöschte Inhalte. Verlinke wichtige Seiten intern gut. Mehr dazu findest du im Abschnitt zum Crawling-Ballast und auf unserer Seite zum Crawl-Budget.
Welche Daten liefert der Crawl-Statistiken-Bericht in der Google Search Console?
Der Crawl-Statistiken-Bericht in der Google Search Console liefert dir Crawl-Daten der letzten drei Monate. Du findest ihn unter den Einstellungen, allerdings nur bei einer Domain-Property. Bei Verzeichnis-Properties fehlt er.
In der Übersicht siehst du die Crawl-Anfragen insgesamt, die durchschnittliche Server-Antwortzeit und die Download-Größe. Darauf achtest du auf Peaks und Trends. Steigen die Crawl-Anfragen und gleichzeitig die Antwortzeit, drohen dir perspektivisch Kapazitätsprobleme am Server.
Darunter teilt Google die Daten in vier Bereiche auf: nach Dateityp, nach Zweck, nach Antwort und nach Googlebot-Typ. Jede Ausprägung enthält bis zu 1000 Beispiel-URLs. Der Zweck unterscheidet Discovery- und Refresh-Crawls. Diese Info liefern klassische Logfiles nicht.
Dazu kommt der Bereich Hosts. Er zeigt dir bis zu 20 meistabgerufene Subdomains der letzten 90 Tage. Subdomains musst du dafür nicht einzeln anlegen, die Domain-Property erfasst sie automatisch. Hast du mehr als 20 Subdomains, ist das laut Juliane schon ein Ansatzpunkt für die Optimierung.
Eine Einschränkung gibt es: Mehr als die Beispieldaten bekommst du nicht heraus, es gibt keine API dafür. Juliane aggregiert deshalb alle Berichte in einem Template. Wie das geht, beschreibt der Abschnitt zur Logfile-Analyse light in drei Schritten.
Wie unterscheidet sich die GSC-Analyse von einer klassischen Logfile-Analyse?
Die GSC-Analyse nutzt Beispieldaten aus den Crawl-Statistiken, die klassische Logfile-Analyse dagegen alle Server-Logs. In einem Projekt von Juliane Bettinga liefen beide parallel. Die Erkenntnisse waren am Ende nahezu gleich.
Klassische Logfiles sind vollständig, aber schwer zu beschaffen. In Unternehmen geht es um Terabytes, mit Beispielen von bis zu 30 GB pro Tag. Du kannst dir oft nur kurze Zeiträume ansehen, und manche Logs bleiben nur kurz gespeichert. Trends über Wochen oder Monate erkennst du so schwer. Außerdem brauchst du passende Tools oder Entwicklungsressourcen.
Die GSC liefert dir bis zu 1000 Beispiel-URLs pro Ausprägung, dafür aber drei Monate Verlauf. Das gibt dir mehr Interpretationsspielraum bei Trends und Peaks. Ein Plus: Die GSC zeigt dir den Crawl-Zweck, also Discovery oder Refresh. Diese Info fehlt in klassischen Logfiles komplett.
Warum reichen die Beispieldaten oft aus? Juliane sagt: „Probleme sind ja immer strukturelle Themen.“ Eine einzelne URL ruiniert selten dein Crawl-Budget. Systematische Fehler wie Parameter-URLs oder Redirect-Muster siehst du auch in den Stichproben.
Ein normaler Crawler wie Screaming Frog ist dagegen kein Ersatz. Er zeigt dir mit Inspection API nur das letzte Crawldatum, nicht die Frequenz. Für eine ganz detaillierte Auswertung brauchst du am Ende trotzdem die klassische Logfile-Analyse.
Was ist ein Logfile?
Ein Logfile ist im SEO-Kontext dein Bild davon, womit sich Suchmaschinen und andere Bots auf deiner Website beschäftigen. So beschreibt es Juliane Bettinga. Darin steckt, welche URLs und Ressourcen ein Bot abruft und wie oft er wiederkommt. Diese Frequenz siehst du mit keinem normalen Crawler.
Logfiles zeigen dir auch, was auf deinem Server liegt, ohne dass es dir sofort auffällt. Dazu gehören Ressourcen jenseits deiner offensichtlichen URL-Struktur, etwa CSS, JavaScript oder PDFs. Juliane spricht von einem Blick in den Maschinenraum. Du erkennst Missverhältnisse beim Crawling und Verzeichnisse, die Google auffällig oft besucht.
Der Haken: Logfiles werden schnell riesig. In Unternehmen geht es um Terabytes an Daten. Oft kannst du nur einzelne Tage oder höchstens eine Woche auswerten, ein ganzer Monat wird schwierig. Nur wenige Tools verarbeiten diese Mengen, eigene Lösungen brauchen Entwicklungsressourcen.
Deshalb setzt Juliane auf die Light-Variante mit der Google Search Console. Die Crawl-Statistiken liefern dir drei Monate Verlauf und bis zu 1000 Beispiel-URLs pro Ausprägung. In einem Vergleichsprojekt kam sie damit zu nahezu denselben Erkenntnissen wie mit echten Logfiles. Wie du startest, zeigt dir der Abschnitt zur Logfile-Analyse light in drei Schritten.