Logfile Analyse für SEO: So beobachten Sie den Googlebot mit echten Daten

Der Googlebot besucht Ihre Website jeden Tag. Welche Seiten er abruft, welche er auslässt und wo er auf Fehler stößt, weiß allerdings nur Ihr Server. Eine Logfile Analyse macht aus diesen Einträgen belastbare Daten. In diesem Leitfaden zeigen wir, Talha Aslan und Team, unser Vorgehen aus technischen Audits: Googlebot Anfragen isolieren, gefälschte Bots aussortieren, meistgecrawlte und nie gecrawlte URLs finden, Statuscodes deuten und die Ergebnisse mit der Search Console abgleichen.

Warum ist das so wichtig? Weil externe Crawling Tools Ihre Website nach eigener Logik durchlaufen, während der Googlebot eigenen Prioritäten folgt. Deshalb deckt sich beides selten. Zum Beispiel erreicht ein Crawling Tool womöglich jede Produktseite, Ihre Logs zeigen aber, dass der Googlebot die Hälfte davon seit Monaten ignoriert. Außerdem decken Logs auf, wie Filterparameter und andere wertlose URLs Crawlingkapazität verbrauchen.

Kurz gesagt: Logdaten sind die Beweisebene der technischen Suchmaschinenoptimierung. Die echte Wirkung einer robots.txt Änderung, einer Bereinigung von Weiterleitungen oder neuer interner Verlinkung auf das Crawling sehen Sie erst in den Logs. Deshalb behandeln wir die Auswertung bei großen und sich schnell ändernden Websites als wiederkehrende Kontrolle, nicht als einmalige Aufgabe.

Welche Informationen enthält ein Access Log?

Ein Access Log ist eine einfache Textdatei, die jede Anfrage an den Server in einer eigenen Zeile speichert. Das genaue Format hängt allerdings von Ihrer Serversoftware ab. Dennoch enthält fast jede Installation die Felder, die Sie für SEO brauchen. Sobald Sie eine Zeile lesen können, haben Sie die halbe Arbeit erledigt.

• IP Adresse des Clients: die Adresse der anfragenden Maschine; sie ist die Grundlage jeder Googlebot Prüfung.
• Datum und Uhrzeit: der Zeitpunkt der Anfrage, aus dem Sie Crawlfrequenz und Spitzenzeiten ableiten.
• Anfragezeile: die Methode wie GET oder HEAD sowie der angefragte URL Pfad samt Parametern.
• Statuscode: die Antwort des Servers, etwa 200, 301, 404 oder 503.
• Antwortgröße: die gesendeten Bytes; leere oder verdächtig kleine Antworten fallen so auf.
• Referrer: die Seite, von der die Anfrage kam; bei Crawlern bleibt das Feld meist leer.
• User Agent: der Text, mit dem sich der Client ausweist; hier nennt der Googlebot seinen Namen.

Manche Installationen speichern zudem die Antwortzeit. Dieses Feld ist sehr wertvoll, denn es zeigt langsame URL Gruppen direkt an. Fehlt es, bitten Sie Ihren Hostinganbieter oder Ihre Entwickler, es in das Logformat aufzunehmen.

Wo finden Sie die Logdateien Ihres Servers?

Zunächst schauen Sie in Ihr Hosting Panel. Beim Shared Hosting können Sie die Rohdaten der Zugriffe meist in einem Bereich für Logs oder Statistiken herunterladen. Auf einem virtuellen oder dedizierten Server liegen die Dateien im Logordner Ihrer Webserversoftware. Fehlt Ihnen der Zugang, fragen Sie am besten Ihren Serveradministrator.

Vorsicht, falls Ihre Website hinter einem Content Delivery Network (CDN) läuft. Dann beantwortet das CDN einen Teil der Anfragen aus dem Cache, und diese Anfragen erreichen Ihren Ursprungsserver nie. Daher brauchen Sie zusätzlich die Logs des CDN. Sonst glauben Sie womöglich, der Googlebot crawle Ihre Seiten seltener, als er es tatsächlich tut.

Hinzu kommt der Datenschutz. Logs enthalten auch echte Besucherdaten, und IP Adressen können nach der DSGVO personenbezogene Daten sein. Deshalb empfehlen wir, vor jeder Weitergabe nur Crawlerzeilen zu behalten oder Besucher IPs zu maskieren. Welche Pflichten für Sie gelten, klären Sie bitte mit Ihrer Rechtsberatung; dieser Hinweis ist keine Rechtsberatung.

Wie viele Tage an Logdaten brauchen Sie?

Ein einzelner Tag Logdaten führt in die Irre. An manchen Tagen konzentriert sich der Googlebot auf bestimmte Bereiche, an anderen kommt er kaum vorbei. Daher arbeiten wir lieber mit mindestens mehreren Wochen, idealerweise mit einem vollen Monat ununterbrochener Daten. Bei großen Websites hilft ein längerer Zeitraum zudem, saisonale von strukturellen Veränderungen zu trennen.

Beispielszenario: Ein Onlineshop unter example.com hat seine Kategoriestruktur umgebaut, zwei Wochen später sinkt der Traffic. Ohne Logs aus der Zeit vor und nach der Änderung kann niemand sagen, wann der Googlebot auf die neuen URLs umgestiegen ist. Planen Sie die Aufbewahrung also so, dass sie wichtige Releases und Migrationen abdeckt.

Andererseits ist eine unbegrenzte Aufbewahrung auch keine Lösung. Legen Sie aus Speicher und Datenschutzgründen einen sinnvollen Zeitraum fest, komprimieren Sie ältere Dateien und verschieben Sie sie vom Server. Außerdem sollten Sie für jeden Zeitraum dieselben Filter verwenden. So bleiben Ihre Vergleiche wirklich vergleichbar.

Wie isolieren Sie Googlebot Anfragen in Ihren Logs?

Der erste Filter ist das Feld User Agent. Der Googlebot trägt dort seinen Namen ein, und seine Smartphone und Desktop Crawler nutzen getrennte Kennungen. Laut der offiziellen Googlebot Dokumentation indexiert Google die meisten Websites nach dem Prinzip Mobile First; deshalb stammen die meisten Anfragen vom Smartphone Crawler. Zeigen Ihre Zahlen das Gegenteil, gehen Sie der Ursache nach.

Allerdings beweist der User Agent allein nichts. Google selbst schreibt, dass andere Crawler den User Agent des Googlebot häufig fälschen. Anders gesagt: Nicht jede Zeile mit dem Wort Googlebot kommt von Google. Nach dem ersten Filter brauchen Sie also immer eine IP Prüfung.

In der Praxis gehen wir so vor. Zunächst ziehen wir alle Zeilen mit Google im User Agent heraus. Danach extrahieren wir die eindeutigen IP Adressen. Schließlich prüfen wir jede IP und behalten nur Zeilen von echten Google Adressen. Statt Tausender Zeilen prüfen Sie so nur einige Hundert IPs. Grundlagen zur Funktionsweise finden Sie in unserem Beitrag Was ist der Googlebot und wie verifizieren Sie ihn.

Wie erkennen Sie einen gefälschten Googlebot?

Google beschreibt zwei offizielle Wege zur Verifizierung. Der erste ist eine Reverse DNS Abfrage, und laut der Google Anleitung zur Überprüfung seiner Crawler reicht diese Methode für die meisten Fälle aus. Konkret ist die Logik einfach: Sie fragen, wem die IP gehört, wandeln den Namen zurück in eine IP um und prüfen, ob beide Enden übereinstimmen.

1. Führen Sie für die IP Adresse aus dem Log eine Reverse DNS Abfrage aus.
2. Prüfen Sie, ob der zurückgegebene Hostname auf googlebot.com, google.com oder googleusercontent.com endet.
3. Führen Sie für diesen Hostnamen eine Forward DNS Abfrage aus.
4. Bestätigen Sie, dass das Ergebnis exakt der ursprünglichen IP Adresse entspricht.

Scheitert auch nur einer dieser vier Schritte, stammt die Anfrage nicht vom Googlebot. Zum Beispiel zeigt die Reverse Abfrage vielleicht einen Namen im Google Stil, die Forward Abfrage liefert aber eine andere IP. Dann fälscht womöglich jemand den DNS Eintrag. Entfernen Sie solche Zeilen aus der Auswertung und geben Sie sie bei Bedarf an Ihr Sicherheitsteam weiter. Wenn Sie Reverse DNS aus dem E-Mail Umfeld kennen, erklärt unser Beitrag zum PTR Eintrag und Reverse DNS denselben Mechanismus aus anderer Sicht.

Wie funktioniert die automatische Prüfung über IP Bereiche?

Tausende IPs einzeln abzufragen, kostet Zeit. Deshalb bietet Google einen zweiten Weg: Es veröffentlicht die IP Bereiche seiner Crawler in öffentlichen JSON Dateien in CIDR Notation. Sie gleichen jede IP aus dem Log mit diesen Bereichen ab. Liegt die IP in einem Bereich, dürfen Sie die Anfrage als echt behandeln.

Die offizielle Verifizierungsseite trennt die Dateien nach Crawlertyp: eine Datei für die allgemeinen Crawler, eine für die Spezialcrawler und weitere Dateien für nutzerausgelöste Abrufe. Dateinamen und Umfang können sich ändern. Prüfen Sie die aktuelle Liste daher bei jeder Auswertung auf der offiziellen Seite.

Ein Tipp aus der Praxis: Laden Sie die Listen nicht einmal herunter, um sie dann ewig zu nutzen. Google kann seine Bereiche anpassen, und eine veraltete Liste stuft womöglich den echten Googlebot als Fälschung ein. Am sichersten holen Sie die Dateien direkt vor jeder Auswertung neu. Außerdem lassen sich beide Methoden kombinieren. Filtern Sie zunächst in großer Menge über die Bereiche, dann bestätigen Sie die wenigen zweifelhaften IPs per Reverse DNS.

Welche Google Crawler sollten Sie getrennt auswerten?

Allerdings kommt nicht jeder Google Bot aus demselben Grund. Die offizielle Dokumentation teilt die Crawler in drei Gruppen ein, und jede Gruppe geht anders mit der robots.txt um. Werfen Sie alle Google Anfragen in einen Topf, halten Sie womöglich Abrufe ohne SEO Bezug für Crawlingprobleme.

Für SEO zählen vor allem die allgemeinen Crawler. Zum Beispiel halten Sie AdsBot Anfragen als Landingpage Prüfungen in einem eigenen Tabellenblatt, damit Ihre Googlebot Daten sauber bleiben. Ebenso gruppieren Sie KI Crawler separat; dieses Thema behandeln wir im Beitrag über KI Crawler und die robots.txt.

Wie gehen Sie bei einer Logfile Analyse Schritt für Schritt vor?

Steht die Methode einmal, wiederholen Sie in jedem Zeitraum dieselben Schritte. Die folgende Reihenfolge ist das Gerüst, das wir in technischen SEO Audits nutzen. Befehle oder Softwarenamen nennen wir bewusst nicht, denn dieselbe Arbeit gelingt in einer Tabellenkalkulation ebenso wie in einem Logtool.

1. Wählen Sie den Zeitraum und sammeln Sie alle Server und CDN Logs dafür.
2. Bringen Sie die Zeilen in gemeinsame Spalten: IP, Zeit, URL, Statuscode, Größe und User Agent.
3. Filtern Sie Zeilen mit Google im User Agent und ziehen Sie die eindeutigen IPs heraus.
4. Prüfen Sie diese IPs über die offiziellen Bereichslisten oder per Reverse DNS und verwerfen Sie Fälschungen.
5. Gruppieren Sie URLs nach Vorlage: Kategorie, Produkt, Blog, Filter, interne Suche und statische Dateien.
6. Berechnen Sie je Gruppe Anfragen, Verteilung der Statuscodes und das letzte Crawldatum.
7. Vergleichen Sie die Ergebnisse mit Ihrer XML Sitemap und Ihrem Crawlerexport, um fehlendes und übermäßiges Crawling zu markieren.
8. Gleichen Sie die Erkenntnisse mit dem Bericht Crawl Stats in der Search Console ab.

Bei einer kleinen Website zeigt Ihnen unser kostenloses Tool zur Logfile Analyse die ersten Filter schnell an. Bei einer großen Website braucht eine Logfile Analyse dagegen Vorlagengruppen und regelmäßige Wiederholung. An diesem Punkt richten wir den Prozess im Rahmen unserer SEO Beratung für Sie ein und verfolgen ihn laufend.

Was verraten Ihnen die meistgecrawlten URLs?

Eine Rangliste nach Crawlfrequenz zeigt, was der Googlebot auf Ihrer Website für wichtig oder problematisch hält. Startseite und starke Kategorien weit oben sind dabei normal, denn sie erhalten viele interne Links. Das eigentliche Warnsignal erscheint, wenn wertlose URLs die Spitze der Liste füllen.

• Endlose URL Kombinationen aus Sortierung, Farbe und Größe als Filterparameter.
• Ergebnisseiten der internen Suche, auch Suchen ohne Treffer.
• Adressen mit Kalender, Paginierung oder Session ID.
• Aktions URLs wie In den Warenkorb oder Vergleichen.

Verbrauchen diese Gruppen einen großen Anteil der Anfragen, bleibt dem Googlebot weniger Zeit für Ihre wertvollen Seiten. Trotzdem ist eine Sperre per robots.txt nicht immer die richtige Lösung. Prüfen Sie zunächst, warum Ihre interne Verlinkung diese URLs überhaupt erzeugt. Filterstrukturen erklären wir im Beitrag über Facettennavigation. Zudem kann häufiges Recrawling derselben Inhalte ein Zeichen dafür sein, dass sich eine Seite oft ändert; lesen Sie es deshalb zusammen mit den Änderungsdaten.

Wie finden Sie wichtige Seiten, die nie gecrawlt sind?

Diese Frage liefert das wertvollste Ergebnis einer Logfile Analyse. Die Methode ist eine einfache Mengendifferenz. Sie erstellen eine Liste aller URLs, die existieren sollten, und vergleichen sie mit den URLs, die der Googlebot laut Log abgerufen hat. Jede Adresse aus der ersten Liste, die in der zweiten fehlt, hat im Zeitraum keinen Crawl erhalten.

Die Sollliste bauen wir aus drei Quellen: der XML Sitemap, den indexierbaren Seiten aus Ihrem eigenen Crawl und der Datenbank aktiver Produkte oder veröffentlichter Inhalte. Stehen zum Beispiel Hunderte Produkte in der Sitemap, haben im Log aber keine einzige Anfrage, liegen sie vermutlich zu tief in der internen Verlinkung.

Hier entscheidet die Klicktiefe. Seiten, die viele Klicks von der Startseite entfernt liegen, besucht der Googlebot tendenziell seltener; dazu mehr in unserem Beitrag Was ist Klicktiefe (Crawl Depth). Prüfen Sie dann den Status dieser Seiten in der Search Console. Der Status „Discovered, currently not indexed“ deutet oft auf dasselbe Muster hin.

Wie lesen Sie die Verteilung der Statuscodes?

Die Mischung der Antworten, die der Googlebot erhält, zeigt, wie sauber Ihre Website den Weg für Crawler freimacht. Die Google Dokumentation zu HTTP Statuscodes und Netzwerkfehlern erklärt das Verhalten jeder Codefamilie. Diese Übersicht nutzen wir, wenn wir die Verteilung aus einem Logexport deuten.

In einer gesunden Verteilung dominieren 200 Antworten, deshalb bilden sie Ihre Basis. Steigen die Anteile von Weiterleitungen und 404 Fehlern, zeigen Ihre internen Links vermutlich noch auf alte URLs. Das Verhalten bei 304 erklärt unser Beitrag zu 304 Not Modified und Last Modified.

Warum bremsen 5xx und 429 Antworten das Crawling?

Laut der offiziellen Dokumentation veranlassen 5xx und 429 Antworten die Google Crawler, vorübergehend langsamer zu crawlen. Liefert der Server wieder 2xx Antworten, erhöht Google die Crawlrate schrittweise. Also hinterlässt selbst ein kurzer Ausfall womöglich tagelang Spuren in Form von weniger Crawling.

Zählen Sie die 5xx Zeilen deshalb nicht nur, sondern tragen Sie sie über die Zeit auf. Beispielszenario: Häufen sich die Fehler jede Nacht im selben Zeitfenster, steckt vermutlich ein Backup oder ein Stapeljob dahinter, der zu dieser Stunde läuft. Ebenso deutet eine Häufung auf einer einzigen URL Vorlage auf ein Problem in deren Datenbankabfrage hin.

Dazu kommt die 429 Falle. Sicherheitsplugins und Ratenbegrenzer drosseln den Googlebot manchmal wie jeden anderen Bot. Da Google 429 als Überlastsignal deutet, crawlt es dann weniger. Andererseits beeinflussen Codes wie 401 und 403 laut Dokumentation die Crawlrate nicht; nutzen Sie sie daher nicht, um den Googlebot zu bremsen. Weitere Ursachen sinkender Crawlraten haben wir im Beitrag Warum der Googlebot weniger crawlt gesammelt.

Wie sehen Weiterleitungsketten im Log aus?

Im Log erscheint eine Kette als Folge von Anfragen desselben Crawlers innerhalb weniger Sekunden, die jeweils einen 3xx Code liefern. Zum Beispiel ruft der Googlebot zuerst die http Adresse auf, dann die https Version und danach die Version mit Schrägstrich am Ende. Jeder Schritt ist eine eigene Anfrage und kostet somit Crawlingkapazität.

Laut Google Dokumentation folgen die Crawler standardmäßig bis zu 10 Weiterleitungsschritten. Schon deutlich unter dieser Grenze erzeugen Ketten jedoch Verschwendung. Ordnen Sie deshalb jede URL mit 3xx Antwort ihrem Ziel zu und listen Sie alle Pfade mit zwei oder mehr Schritten auf. Danach lassen Sie Ihre internen Links direkt auf die finale URL zeigen.

In der Praxis liegt die Quelle einer Kette oft in einem alten Menülink, einem vergessenen Sitemap Eintrag oder einem veralteten Canonical Tag. Beheben Sie die Quelle nicht, läuft der Googlebot denselben Weg immer wieder, egal wie gründlich Sie die Weiterleitungsregeln aufräumen. Konkrete Lösungsschritte finden Sie in unserem Beitrag zur Weiterleitungskette (Redirect Chain).

Wie vergleichen Sie Logs mit dem Crawl Stats Bericht der Search Console?

Den Bericht Crawl Stats finden Sie in der Search Console in den Einstellungen der Property; er fasst das Crawling aus Sicht von Google zusammen. Laut der Hilfeseite der Search Console zu diesem Bericht steht er nur für Properties auf Stammebene zur Verfügung, also für eine Domain Property oder eine URL Präfix Property auf Stammebene.

Der Bericht zeigt drei Hauptdiagramme, in der englischen Oberfläche Total crawl requests, Total download size und Average response time. Hinzu kommt der Bereich Host status mit Problemen beim Abruf der robots.txt, bei der DNS Auflösung und bei der Serververbindung. Zudem gibt es Aufschlüsselungen nach Antwort, Dateityp, Zweck und Art des Googlebot. Die deutsche Oberfläche verwendet dafür übersetzte Bezeichnungen.

So gehen wir beim Vergleich vor. Für denselben Zeitraum stellen wir die verifizierten Googlebot Anfragen aus dem Log neben die Gesamtzahl im Bericht. Anschließend gleichen wir die Anteile der Statuscodes und die Verteilung nach Googlebot Art ab. Bewegen sich beide Trendlinien in dieselbe Richtung, funktioniert Ihre Datenerfassung. Eine allgemeine Einführung bietet unsere Google Search Console Anleitung für Einsteiger.

Warum stimmen Logdaten und Search Console nie genau überein?

Kleine Abweichungen zwischen beiden Quellen sind allerdings normal. Auch die Hilfeseite weist darauf hin, dass Google manche Anfragen womöglich nicht erfasst und die Summen daher leicht von Serverlogs abweichen können. Wer die Quelle der Lücke kennt, vermeidet Fehlalarme.

• Der Bericht umfasst nur die ausgewählte Domain; Anfragen an andere Domains, etwa für dort gehostete Bilder, fehlen.
• Der Bericht zählt jede Anfrage einer Weiterleitungskette einzeln und ordnet die Daten keiner kanonischen URL zu.
• Die Summen enthalten sowohl http als auch https Anfragen.
• Anfragen, die das CDN aus dem Cache beantwortet, tauchen in Ihren Ursprungslogs eventuell nie auf.
• Die Beispiel URLs im Bericht sind repräsentativ, aber nicht vollständig.

Wann ist eine Lücke also ein Problem? Liegt Ihre Logzahl deutlich unter dem Bericht, fehlt Ihnen vermutlich eine Logquelle, etwa das CDN. Liegt sie deutlich darüber, sind womöglich gefälschte Googlebot Zeilen durch die Prüfung gerutscht. In beiden Fällen kontrollieren Sie zuerst Ihre Erfassung und Ihre Verifizierung.

Was sagt das Verhältnis von Discovery und Refresh aus?

Die Aufschlüsselung nach Crawlingzweck zeigt zwei Werte. Discovery umfasst Anfragen an URLs, die Google noch nie gecrawlt hat; Refresh umfasst erneute Abrufe bekannter Seiten. In der deutschen Oberfläche heißen diese Werte Erkennung und Aktualisierung. Diese Trennung hilft also vor allem in Wachstumsphasen Ihrer Website.

Beispielszenario: example.com hat Hunderte neue Produkte ergänzt, doch der Anteil von Discovery bewegt sich kaum. Dieses Bild spricht dafür, dass den neuen Seiten interne Links oder Sitemap Einträge fehlen. Im Log prüfen Sie zudem, wann die erste Anfrage jede neue Produkt URL erreicht hat, und messen die Verzögerung in Tagen.

Umgekehrt sollten Sie aufmerksam sein, wenn der Anteil von Discovery hoch bleibt, obwohl Sie nichts Neues veröffentlichen. Meist erzeugen dann Parameter URLs oder endlose Paginierung ständig neue Adressen. Somit verbringt der Googlebot seine Zeit mit künstlichen URLs statt mit echten Inhalten. Eine Gruppierung der Log URLs nach Vorlage zeigt schnell, woher diese Adressen stammen.

Was zeigen Dateityp und Antwortzeit?

Die Aufschlüsselung nach Dateityp zeigt die Anteile von HTML, Bildern, JavaScript, CSS, PDF und weiteren Typen. In Ihren Logs treffen Sie dieselbe Unterscheidung über die Dateiendung oder den Content Type. Ein hoher Anteil an JavaScript und CSS bedeutet, dass der Googlebot diese Ressourcen zum Rendern lädt. Achten Sie deshalb darauf, sie nicht versehentlich zu sperren.

Die durchschnittliche Antwortzeit hängt direkt mit der Crawlingkapazität zusammen. Der Leitfaden von Google zum Crawl Budget erklärt, dass die Kapazitätsgrenze steigen kann, wenn der Server schnell und zuverlässig antwortet, und sinkt, wenn Fehler auftreten. Enthalten Ihre Logs die Antwortzeit, listen Sie die langsamsten URL Vorlagen auf und geben Sie sie priorisiert an Ihre Entwickler weiter.

Noch ein Detail: Laut offizieller Dokumentation ruft der Googlebot die ersten 2 MB des unkomprimierten Inhalts eines unterstützten Dateityps ab. Das Feld Antwortgröße im Log eignet sich daher gut, um übergroße HTML Seiten nahe dieser Grenze zu finden. Zum Beispiel blähen riesige eingebettete Datenblöcke die Seitengröße oft unbemerkt auf.

Für welche Websites hat eine Logfile Analyse Priorität?

Nicht jede Website braucht eine tiefe Auswertung. Als grobe Schätzung nennt der Crawl Budget Leitfaden von Google Websites mit mehr als einer Million eindeutiger Seiten und wöchentlichen Änderungen oder Websites mit mehr als zehntausend Seiten und täglich wechselnden Inhalten. Für diese Websites ist eine Logfile Analyse nahezu Pflicht.

Aber auch bei kleineren Websites liefert ein Blick in die Logs in diesen Fällen schnelle Antworten:

• Nach einer Migration oder einem Domainwechsel, um den Umstieg des Googlebot auf die neuen URLs zu verfolgen.
• Wenn die Search Console viele URLs als „Discovered, currently not indexed“ ausweist.
• Nach einem plötzlichen Trafficeinbruch, um Serverfehler auszuschließen.
• Wenn Sie vermuten, dass eine Sicherheitsebene Bots blockiert.

Wen das Crawl Budget wirklich betrifft, diskutieren wir im Beitrag Was ist Crawl Budget und für welche Websites ist es wichtig. Zusammengefasst: Je größer die Website, desto wertvoller die Logdaten.

Welche Deutungsfehler passieren am häufigsten?

Sie können Daten korrekt erfassen und trotzdem falsch lesen. Diese Fehler sehen wir in der Praxis am häufigsten:

• Sich auf den Filter nach User Agent verlassen und gefälschte Googlebot Zeilen mitzählen.
• Aus wenigen Tagen Daten dauerhafte Schlüsse ziehen.
• Die CDN Logs vergessen und einem unvollständigen Bild vom Ursprungsserver trauen.
• Spezialcrawler wie AdsBot mit den organischen Crawlingdaten vermischen.
• Hohe Crawlfrequenz automatisch als Rankingsignal deuten.
• Soft 404 Seiten für gesund halten, weil sie 200 liefern.

Der letzte Punkt verdient Aufmerksamkeit. Die Crawl Budget Dokumentation von Google hält fest, dass Soft 404 Seiten weiter gecrawlt und Ihr Budget verschwenden. Nicht jede 200 Zeile im Log bedeutet also echten Inhalt; prüfen Sie 200 Antworten mit sehr kleiner Größe separat. Wie Sie solche Seiten erkennen, erklärt unser Beitrag zu Soft 404 Fehlern.

Wie priorisieren Sie die Erkenntnisse und setzen sie um?

Eine Logfile Analyse erzeugt eine lange Liste von Problemen. Alles gleichzeitig anzugehen, verschwendet allerdings Kraft. Wir ordnen die Erkenntnisse nach zwei Achsen: Zahl der betroffenen URLs und geschäftlicher Wert dieser URLs. 5xx Fehler und fehlendes Crawling bei Vorlagen, die Umsatz oder Anfragen bringen, stehen zuerst. Parameter URLs mit geringem Wert folgen später.

Verknüpfen Sie jede Maßnahme mit einem Messpunkt. Begrenzen Sie zum Beispiel Filter URLs, nehmen Sie zwei bis vier Wochen später einen neuen Logzeitraum mit denselben Filtern. Dann berechnen Sie den Anteil dieser Gruppe erneut. So sehen Sie mit demselben Maßstab, ob die Änderung gewirkt hat, statt zu raten.

Verwechseln Sie Logerkenntnisse schließlich nicht mit einem Rankingversprechen. Sauberes Crawling hilft Google, Ihre Inhalte effizienter zu finden. Rankings hängen jedoch von der Qualität der Inhalte und vielen weiteren Faktoren ab. Betrachten Sie die Logarbeit daher als Teil Ihres technischen Fundaments, nicht als eigenständigen Wachstumshebel.

Wie setzen wir diesen Prozess gemeinsam auf Ihrer Website um?

Wir, Talha Aslan und Team, betrachten die Logfile Analyse als Beweisebene eines technischen SEO Audits. Wir richten Erfassung und Verifizierung der Logs ein, gruppieren URL Vorlagen, erstellen regelmäßige Berichte und übergeben die Erkenntnisse als umsetzbare Aufgaben an Ihre Entwickler. Danach verfolgen wir die Wirkung jeder Korrektur mit denselben Messgrößen.

Rankings garantieren wir nicht; niemand kann Entscheidungen von Google im Voraus zusagen. Wir zeigen Ihnen jedoch anhand der Logs, wo das Crawling hakt, beheben das Problem auf Ihrer Website und beobachten die Entwicklung danach. Um den Umfang je nach Größe Ihrer Website und Logzugang festzulegen, können Sie über unsere Seite zur SEO Beratung ein Angebot anfordern.

Grundlagen: Was ist Online Marketing? Arten, Beispiele und Vorgehen auf einer Seite, mit einem interaktiven Film durch das Gehirn.