Logfile-Analyse: Bot-Crawling und Serverantworten prüfen
Eine Logfile-Analyse zeigt, welche HTTP-Anfragen am Server angekommen sind, wann sie ankamen und wie der Server darauf antwortete. Für die Crawl-Analyse ist das die Auswertungsgrundlage: Sie prüft tatsächliche Bot-Aufrufe. Der Befund erfordert verifizierte Bots, normalisierte URLs und wiederkehrende Muster in den Serverantworten.
Die Methode beantwortet vier Fragen: Ruft ein verifizierter Crawler wichtige URLs ab? Erhält er die erwartete HTTP-Antwort? Verbrauchen unbenötigte URL-Varianten Aufmerksamkeit? Treten bei bestimmten Bereichen der Website Verfügbarkeitsprobleme auf?
Damit vertieft sie das Crawling aus den Grundlagen. Sie bewertet weder inhaltliche Qualität noch Suchpositionen.
Der Hub Technisches SEO: Infrastruktur, Architektur und Jamstack ordnet Serverantworten, Crawling und Indexierung in die technische Lieferkette einer URL ein.
Was Serverlogs belegen
Ein Logeintrag belegt einen Request, der die Serverinfrastruktur erreicht hat. Er zeigt, ob ein Bot eine URL aufrief und den Statuscode 200, 301, 404 oder 503 erhielt. Er zeigt nicht, ob eine Suchmaschine die URL danach indexiert, als kanonisch auswählt oder für eine Suchanfrage anzeigt. Ein 200-Response ist ein Auslieferungsbefund, keine Indexierungszusage.
Die Search Console ergänzt die Analyse. Ihr Bericht „Crawling-Statistik“ fasst Google-Anfragen, Antworttypen, Reaktionszeiten und Hostprobleme zusammen. Google weist darauf hin, dass Zählungen von Serverlogs abweichen können. Du nutzt die Search Console zur Prüfung von Trends und Serverlogs für die Einzel-Request-Ebene.
| Die Logfile-Analyse beantwortet | Sie beantwortet nicht |
|---|---|
| Wurde eine URL von einem verifizierten Bot angefragt? | Wird die URL indexiert oder in Suchergebnissen platziert? |
| Welchen HTTP-Status und welche Antwortgröße erhielt der Bot? | Löste der Inhalt die Suchaufgabe? |
| Welche Pfade, Parameter oder Weiterleitungen treten wiederholt auf? | Ist die Seite für Nutzende schnell und bedienbar? |
| Zu welchen Zeiträumen häufen sich Fehler oder Drosselungen? | Welche Umsatzwirkung eine Änderung bringt |
Für die Einordnung von Indexierung, Suchleistung und Geschäftszielen brauchst du zusätzliche Datenquellen. Der SEO-Strategie-Hub verbindet diese Ebenen im Gesamtplan.
Datengrundlage vor der Auswertung sichern
Kläre zuerst, an welcher Schicht die Requests einlaufen. Bei einer einfachen Serverarchitektur liefert das Access-Log des Webservers die Daten. Bei CDN, Reverse Proxy oder Load Balancer entstehen Antworten an der Edge. Dann müssen die Logs dieser Schicht vorliegen; ein Origin-Log unterschlägt sonst Bot-Aufrufe am Randnetzwerk.
Du exportierst einen zusammenhängenden Zeitraum und bewahrst die Rohdatei unverändert auf. Eine Arbeitskopie dient für Filter, URL-Normalisierung und Zuordnungen. Beschränke den Zugriff auf die Dateien, weil IP-Adressen und Parameter personenbezogene Daten enthalten können. Entferne oder maskiere ungenutzte Felder.
| Logfeld | Nutzen für die Crawl-Analyse | Prüffrage |
|---|---|---|
| Zeitstempel | Ordnet Requests einer Störung, einem Release oder einer Migration zu. | In welchem Zeitfenster trat das Muster auf? |
| Client-IP | Dient zur technischen Bot-Verifizierung. | Passt die IP zum verifizierten Crawler? |
| User-Agent | Liefert einen Hinweis auf den behaupteten Bot. | Welcher Bot gibt sich an? |
| Methode und Request-Ziel | Trennt Seiten-, Ressourcen- und Sonderanfragen. | Welche URL inklusive Parameter wurde angefordert? |
| HTTP-Status | Beschreibt das Ergebnis der Serverantwort. | War die Antwort beabsichtigt? |
| Antwortgröße und Dauer | Zeigt auffällige Antwortmuster. | Häufen sich ungewöhnliche Antworten in einem Bereich? |
| Hostname / vHost | Trennt Subdomains und Umgebungen. | Wurde die richtige Property ausgewertet? |
Achte auf die Zeitbasis. Vereinheitliche Zeitzone und Zeitformat vor Vergleichen. Behalte Hostname, Pfad und Query-String zunächst getrennt. Query-Parameter zeigen, welche Varianten ein Crawler abruft.
Bots verifizieren
Ein User-Agent ist eine Selbstauskunft. Jede Anfrage kann sich als Googlebot ausgeben. Du filterst Kandidaten nach User-Agent und prüfst anschließend die IP-Adresse. Für Google-Anfragen umfasst dieser Ablauf: Reverse-DNS-Lookup der IP-Adresse, Prüfung auf eine Google-Domain (googlebot.com oder google.com) und anschließender Forward-DNS-Lookup. Die zurückgelieferte IP muss mit der Ursprungs-IP übereinstimmen.
- →Kandidat anhand des User-Agents markieren.
- →Reverse DNS für die IP ausführen.
- →Zulässigen Hostnamen prüfen.
- →Hostnamen wieder auflösen.
- →Nur bei identischer IP als verifizierten Google-Crawler zählen.
Bei großen Datenmengen vergleichst du die IP-Adressen mit den veröffentlichten IP-Bereichen von Google. Du dokumentierst Prüfvariante, Bot-Kategorie und Prüfdatum. Nicht verifizierte Anfragen heißen im Bericht „Googlebot-User-Agent“.
Diese Prüfung verhindert Fehlbefunde: Ein fremder Crawler mit gefälschtem User-Agent wird sonst als Googlebot gewertet. Das kann falsche Regeln an Firewall, Rate Limits oder interner Verlinkung auslösen.
URLs normalisieren
Die Roh-URL ist der Nachweis; die normalisierte URL bildet das Analyseobjekt. Speichere beide Werte. Die Normalisierung macht Varianten vergleichbar, ohne die Ursache zu verdecken.
Trenne Schema, Host, Pfad und Query-String. Gruppiere Query-Parameter nach Namen und Wertemustern. Entferne Parameter nicht unangemessen: Genau diese Daten zeigen Filter-, Sortier-, Sitzungs- oder Tracking-Varianten.
Ergänze die Logdaten um einen Sollbestand aus XML-Sitemaps, Seitenexport und URL-Architektur. Eine Sitemap zeigt Erwartungen: Welche URLs sollen Suchmaschinen abrufen? Google empfiehlt Sitemaps mit lastmod-Angabe.
Spalten in der Arbeitsdatei erfassen URL-Gruppe, Seitentyp, Sitemap-Status, erwarteten Statuscode, Redirect-Ziel und verantwortliches Team. Eine URL-Gruppe wie /ratgeber/, /produkt/ oder /suche/ macht Muster sichtbar.
Serverantworten aus Bot-Sicht bewerten
HTTP-Statuscodes beschreiben das Ergebnis eines Requests: 2xx steht für erfolgreiche Auslieferung, 3xx für Weiterleitung, 4xx für nicht erfüllbare Client-Anfragen und 5xx für Serverfehler. Für die Crawl-Analyse bewertest du Statuscode, URL-Zweck und Wiederholung gemeinsam.
| Befund im verifizierten Bot-Traffic | Bedeutung für die Prüfung | Nächster Schritt |
|---|---|---|
| 200 auf einer Soll-URL | Der Server hat die Ressource ausgeliefert. | Stichprobe von Inhalt, Ziel-URL und Seitengruppe prüfen. 200 belegt keine Indexierung. |
| 301 oder 308 | Der Bot soll einer dauerhaften Weiterleitung folgen. | Ziel prüfen, Ketten und Schleifen nachverfolgen, interne Links auf das Ziel umstellen. |
| 302 oder 307 | Der Server leitet vorübergehend weiter. | Prüfen, ob die temporäre Weiterleitung gewollt ist. |
| 304 | Eine bedingte Anfrage nutzt die gespeicherte Version. | Zusammen mit Request-Headern und Cache-Regeln bewerten; kein Fehler. |
| 404 oder 410 | Die Ressource ist nicht verfügbar. | Bei entfernten Seiten korrekt; Herkunft und interne Links prüfen. |
| 403 | Zugriff verweigert. | WAF-, Authentifizierungs- und Bot-Regeln für die IP prüfen. |
| 429 oder 5xx | Drosselung oder Serverfehler blockiert die Antwort. | Zeitfenster, URL-Gruppen und Serverereignisse prüfen. Crawl-Kapazität sinkt bei 429 und 5xx. |
Bewerte 404 nicht automatisch als Fehler. Bei einer endgültig entfernten Seite ohne interne Links ist die Antwort gewollt. Problematisch wird 404 bei wichtigen URLs oder wenn interne Links, Sitemaps oder Parameter-Muster dorthin führen.
Weiterleitungen brauchen Kontext. Jeder Schritt einer Kette erzeugt einen eigenen Request. Der Crawl-Statistik-Bericht zählt bei einer Kette von Seite 1 zu Seite 2 zu Seite 3 getrennte Anfragen. In den Logs prüfst du Ziel, Kettenlänge und verlinkende Quellen.
Die Auswertung in sieben Arbeitsschritten
- →Fragestellung und Sollzustand festlegen: Formuliere eine überprüfbare Frage, etwa: „Erhalten verifizierte Google-Crawler auf Produktseiten die vorgesehenen Antworten?“ Definiere Sollzustand, URL-Gruppen, Statuscodes und Umzüge.
- →Rohdaten prüfen und Logschicht dokumentieren: Notiere Quelle, Zeitraum, Zeitzone, Format und Infrastruktur. Fehlt die Client-IP, entfällt die DNS-Verifizierung. Fehlt der Query-String, bleiben Parameter-Varianten verdeckt.
- →Bot-Kandidaten filtern und verifizieren: Trenne verifizierte Google-Crawler, andere echte Bots und unverifizierte User-Agents.
- →URLs normalisieren und mit dem Sollbestand verbinden: Ordne Requests URL-Gruppen zu. Kennzeichne Sitemap-Status, Weiterleitungen und entfernte Seiten.
- →Nach URL-Gruppe, Status und Zeit aggregieren: Zähle Requests, eindeutige URLs und letzte Anfragen je Gruppe. Schlüssele nach Statuscode und Zeitraum auf. Eine einzelne wichtige URL mit wiederholtem Fehler geht vor viele normale Ressourcen-Aufrufe.
- →Auffälligkeiten an einzelnen Requests prüfen: Öffne für jeden Befund konkrete URLs. Prüfe Response, Redirect-Ziel, Links, Sitemap und Code-Historie.
- →Maßnahmen dokumentieren und erneut messen: Erstelle ein Ticket mit URL-Gruppe, Logbeleg, Zielverhalten, Team und Prüftermin. Wiederhole die Auswertung nach der Änderung.
Wiederkehrende Befunde priorisieren
Priorisiere nach Betroffenheit, technischer Schwere und Beleglage. Betroffenheit erfasst die Rolle der URL (Kategorie, Fachbereich, Umzugsroute). Schwere beschreibt die Auswirkung auf den Abruf. Beleglage verlangt wiederholte verifizierte Bot-Requests.
| Priorität | Typischer Befund | Erforderliche Prüfung |
|---|---|---|
| Sofort | Verifizierte Bots erhalten wiederholt 5xx oder 429 auf wichtigen URL-Gruppen. | Server-, CDN- und WAF-Logs mit dem Zeitfenster abgleichen; Auslieferung stabilisieren. |
| Hoch | Zielseiten werden über Weiterleitungsketten erreicht oder erhalten unerwartet 403 oder 404. | Redirect-Ziele, Zugriffsregeln, Sitemap und Verweise prüfen. |
| Geplant | Unbekannte Parameter- oder Filtervarianten werden wiederholt abgerufen. | URL-Zweck, interne Auslöser, Canonicals und robots.txt prüfen. |
| Beobachten | Vereinzelte 404-Aufrufe alter, nicht mehr verlinkter URLs. | Herkunft dokumentieren und auf Wiederholung prüfen. |
Setze Maßnahmen nicht allein wegen hoher Request-Zahlen um. Google beschreibt Crawl-Budget als Zusammenspiel von Crawl-Kapazität und Crawl-Nachfrage. Eine kleine Website braucht oft nur die Pflege von Sitemap und Search Console; eine tiefe Log-Analyse lohnt sich bei großen oder fehlerhaften Beständen.
Typische Fehlinterpretationen vermeiden
- →Ein Bot-Aufruf belegt keine Suchposition.
- →Weniger Bot-Requests bedeuten nicht automatisch ein Problem.
- →Ein 404-Status ist nicht bei jeder URL ein Fehler.
- →Ein Googlebot-User-Agent beweist keine Anfrage von Google.
Trenne Crawling und Indexierung. Eine gecrawlte URL wird nicht automatisch indexiert. Ein Indexierungsbericht zeigt nicht, ob ein Request an der Edge mit 403 endete.
Logfile-Analyse misst keine Browser-Performance; dafür ist die Prüfung der Core Web Vitals zuständig.
Zeigen Logs dauerhafte Abrufe gelöschter oder geänderter Seiten, verbindet sich Technik mit Redaktion. Die Content-Redaktion nimmt URL-Änderungen in ihren Ablauf auf. Ob ein Beitrag überarbeitet, zusammengeführt oder gelöscht wird, prüft die Redaktionelle SEO.
Ergebnis in die SEO-Steuerung überführen
Ein Logfile-Bericht hält für jede Auffälligkeit fest: verifizierte Bot-Gruppe, URL-Gruppe, Zeitraum, gemessene Antwort und Zielverhalten. Ergänze Links zu Beispiel-Requests.
Die SEO-Strategie ordnet Arbeitspakete in die Roadmap ein. Nach der Umsetzung prüfst du dieselben Muster in den Logs erneut.
Nächster Schritt
OLDSCHOOLSEO wertet technische Befunde aus und ordnet sie in die Suchmaschinenoptimierung für Unternehmen ein. Die Übersicht aller Leistungen steht unter Suchmaschinenoptimierung Stuttgart.
Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen
Sandra Krone und Michael Kienzler | Seriöse Suchmaschinenoptimierung aus Stuttgart | Seit 2018
▋
Michael Kienzler ist Partner und Gründer von OLDSCHOOLSEO. Seine Arbeit beginnt bei der Analyse der technischen Architektur und der Daten, um daraus die Potenziale für die redaktionelle und strategische Weiterentwicklung abzuleiten.