Log-Errors analysieren
Jeder Status-Code in deinen Server-Logs ist ein Signal. Manche sind harmlos, manche kosten dich Sichtbarkeit, andere sind Sicherheitswarnungen. BotScope filtert sie nach Bot, Pfad und Zeit — damit du nicht im Rauschen suchst, sondern direkt zur Ursache kommst.
HTTP-Status-Codes und was sie für dich bedeuten
- 200 OK — Alles gut. Wird trotzdem interessant, wenn ein bestimmter Bot plötzlich nichts mehr abruft trotz 200 — Indiz für Rendering-Probleme.
- 301 / 302 — Redirect. Häufige Crawler-Beobachtung: alte URLs sind in der Sitemap, Googlebot folgt 301-Ketten. Mehr als ein Hop = Verlust von Crawl-Budget.
- 304 Not Modified — Bot hat die Ressource gecached. Vermehrte 304 sind ein gutes Zeichen für effiziente Caching-Header.
- 404 Not Found — Tote Links. Bots crawlen tote URLs immer wieder. BotScope zeigt dir welche 404 von echten Suchmaschinen besucht werden — die musst du fixen oder per 410 dauerhaft kennzeichnen.
- 410 Gone — Bewusst entfernt. Effektiver als 404, da Google die URL aus dem Index nimmt.
- 429 Too Many Requests — Dein Server drosselt einen Bot. Riskant bei Googlebot — du verlierst Indexierungsfrequenz.
- 500 / 502 / 503 / 504 — Server-Fehler. Bursts dieser Codes während Bot-Visits = Server unter Last. Crawler reduzieren ihre Frequenz nachhaltig.
⚠️ 502 Bad Gateway — der unterschätzte Killer
Ein 502 ist kein „normaler" Fehler — er bedeutet: dein Reverse-Proxy (nginx, Cloudflare, Load-Balancer) hat keine Antwort vom Backend (PHP-FPM, Node, Gunicorn) bekommen. Drei typische Ursachen, die sich in den Logs unterscheiden lassen:
502er kommen in Bursts während Traffic-Peaks — Backend-Worker erschöpft, neue Requests laufen ins Timeout. BotScope zeigt 502-Bursts pro Stunde sowie welche Pfade besonders betroffen sind (oft API-Endpoints oder rechenintensive Pages).
502 auf ALLEN Pfaden gleichzeitig = Backend-Service crashed oder neu gestartet (Deploy, OOM-Kill). Verteilung in BotScope ist dann flach über alle URLs — keine Spitzen, sondern eine Linie.
502 nur auf bestimmten Pfaden (z.B. einer neuen API-Route oder einem geänderten location-Block) → nginx-Upstream-Definition stimmt nicht. Vergleich „läuft seit Änderung" zeigt's sofort.
🚨 5xx auf robots.txt → Deindexierungs-Risiko
Kritisch: Liefert dein Server /robots.txt mit einem 5xx-Status (auch nur kurzzeitig), kann Google deine komplette Domain aus dem Index nehmen.
Der Grund: ohne lesbare robots.txt weiß Google nicht, ob es die Inhalte überhaupt indexieren darf. Im Zweifel zieht Google sich zurück — und entfernt vorsorglich alle URLs aus dem Index, bis die robots.txt wieder verfügbar ist.
BotScope-Check: Filtere nach /robots.txt + Status 5xx über die letzten 30 Tage. Selbst wenige Treffer von Googlebot sind ein Warnsignal — wenn das mal eine Stunde anhält, droht der Sichtbarkeits-Crash.
Best Practice: /robots.txt sollte statisch ausgeliefert werden (von nginx direkt, nicht über PHP/Node) und nie durch Backend-Code laufen. Damit ist sie unabhängig von Backend-Crashes.
📊 Praxis-Szenario
Ein Shop bemerkt einen plötzlichen Drop in der organischen Sichtbarkeit. Die Search Console zeigt nur „Crawling-Fehler" generisch. Mit BotScope filterst du:
- Bot: Googlebot (Smartphone)
- Status: 5xx
- Zeitraum: letzte 7 Tage
Ergebnis: 3.200 Treffer, alle auf /api/product-stock/ zwischen 03:00 und 04:30. Ursache: Nightly-Cron für Bestandsupdates blockiert die DB. Fix: Lock entfernen — Googlebot crawlt wieder normal, Rankings erholen sich innerhalb von 14 Tagen.
Was BotScope dir abnimmt
- Filtert 404s nach Bot — du siehst nur Fehler, die echte Crawler tatsächlich treffen
- Burst-Erkennung für 5xx-Cluster — meldet sich, wenn ein Bot plötzlich Server-Fehler bekommt
- Status-Verteilung pro Pfad — du erkennst sofort welche URL chronisch fehlerhaft ist