Case Study · SEO-Audit · Server-Diagnose · NDA

// case_001 · drei_crawl_verifikation Drei Crawls. Ein curl-Test. Drei Jahre Sichtbarkeit, die niemand bemerkt hat.

Ich habe einen Server-Bug gefunden, der nur Googlebot trifft, nicht Menschen. Drei Standard-SEO-Audits hatten ihn vorher als „138 tote URLs" abgehakt und 301-Redirects empfohlen. Wir haben ihn reproduziert, mit curl gegengeprüft und die wahre Ursache identifiziert: ein Server-Concurrency-Problem, das seit drei Jahren still Rankings frisst.

3Crawls
über 8 Tage zur Reproduktion
138 → 0
5xx-Fehler bei curl-Kreuztest
7
Hypothesen, priorisiert
30Min
Entwicklerzeit Quick-Fix

Ausgangslage

Eine Sichtbarkeit, die seit Jahren sinkt. Eine Website, die einwandfrei aussieht.

Die beauftragende Agentur hatte ein altes Problem: Ein internationaler B2B-Konzern verlor seit drei Jahren kontinuierlich Sichtbarkeit. Drei externe Audits zuvor hatten Inhalts-Empfehlungen geliefert, Backlinks geprüft, Performance gemessen. Die Sichtbarkeit fiel weiter.

Der Riss im Plan

Der erste Screaming-Frog-Crawl meldete 138 URLs mit Status 502 (Bad Gateway). In jedem Standard-Audit-Workflow ist das ein klares Signal: Diese URLs sind tot, 301-Redirects einrichten, fertig. Drei Anbieter vor uns hatten genau das empfohlen. Niemand hatte jemals geprüft, ob die URLs wirklich tot sind.

Was wir vorgefunden haben

Ein technisch gepflegter Konzern-Auftritt mit über 5.000 URLs, mehrsprachig aufgebaut, sauberer interner Verlinkung. Hosting bei einem etablierten Provider, Monitoring grün. Genau die Situation, in der Standard-Audits versagen, weil die Symptome nur unter Crawl-Last entstehen.

Drei Wege, eine Entscheidung

301 setzen, eskalieren oder noch einmal hingucken.

Drei Optionen lagen am Tisch. Wir haben sie nicht für die Agentur entschieden, sondern mit ihr, anhand von Risiko, Kosten und langfristiger Wirkung.

Option A · Übernehmen

301-Redirects einrichten

Standard-Vorgehen aller drei Vor-Anbieter: 138 URLs als tot abhaken, Redirect-Liste bauen, abrechnen.

Risiko Ursache bleibt unentdeckt
Zeit 2 Tage
Kosten niedrig
Folge Sichtbarkeit fällt weiter
Option B · Eskalieren

Sofort den Hoster anrufen

Annahme: „Der Server hat ein Problem." Tickets aufmachen, Hoster bittet um Detail-Reproduktion. Ohne Diagnose ein langes Hin und Her.

Risiko Hoster sieht nichts
Zeit Wochen
Kosten hoch (Eskalations-Schleifen)
Folge Verantwortungs-Pingpong
Option C · Diagnostizieren

Drei-Crawl-Verifikation

Drei Crawls über 8 Tage in unterschiedlichen Konfigurationen plus manueller curl-Kreuztest auf identische URL-Liste. Erst diagnostizieren, dann handeln.

Risiko kontrollierbar im Test
Zeit 8 Tage Diagnose
Kosten Bruchteil von Option B
Folge Ursache + Fix-Pfad belegt

8 Tage · Schritt für Schritt

Was zwischen „138 Tote" und „Concurrency-Bug" passiert ist.

Vier Phasen, dokumentiert und reproduzierbar. Vom ersten Standard-Crawl bis zur belegten Hypothese, jeder Schritt einzeln im Repo nachvollziehbar.

Phase 01
Standard-Crawl & Befund

Erster Screaming-Frog-Crawl mit Default-Konfiguration (5 Threads). Ergebnis: 138 URLs mit Status 502. URL-Liste exportiert.

Tag 1
Phase 02
Reproduktion + curl-Kreuztest

Identischer Crawl 8 Tage später: wieder 138 × 502, identische URL-Liste. Parallel curl-Loop sequenziell: 0 × 502, alle 200/302/404. URLs nicht tot.

Tag 8
Phase 03
Concurrency-Verifikation

Dritter Crawl mit erweitertem Set (417 statt 360 URLs): 40 × 502, gleiches Pattern, deutlich weniger absolut. Fehler korrelieren mit Anzahl paralleler Requests.

Tag 8 spät
Phase 04
Hypothesen + Übergabe

7 technische Hypothesen formuliert und priorisiert. Top-Hypothese: PHP-FPM-Worker-Pool-Erschöpfung. Übergabe an Agentur mit Server-Diagnose-Kapitel im Audit-Report.

Tag 9

Stack & Werkzeuge

Was im Werkzeugkasten lag.

Crawler

Screaming Frog SEO Spider

  • 3 Crawls über 8 Tage
  • 5 Threads default vs. 2 Threads Smoke
  • 360 / 360 / 417 URLs Set-Größe
  • Status-Code-Vergleich pro URL-Set
Cross-Check

curl + bash

  • Sequenzielle Loops, 1 Req/sec
  • Identische URL-Liste wie Crawl
  • HTTP-Status-Code-Logging
Datenbasis

GSC + Server-Logs

  • Crawl-Frequenz über 90 Tage
  • 5xx-Korrelation mit Bot-Traffic
  • Cross-Reference URL-Set

Was Kunden sagen

Eine Stimme aus dem Mandat.

Drei Audits vorher hatten uns die 138 URLs als Tote verkauft. Erst die Drei-Crawl-Verifikation hat gezeigt, dass das eigentliche Problem nicht die URLs waren, sondern unsere Hosting-Konfiguration. Mit dem Befund konnten wir endlich gezielt zum Hoster gehen, statt im Nebel zu stochern.

White-Label-Auftraggeber Werbeagentur · Sinngemässe Wiedergabe · Diskretions-Versprechen aktiv
NDA-geschützt

Drei Patterns, die diesen Case wiederholbar machen.

Diese Diagnose ist kein Spezialfall. Sie ist ein Pattern, das du auf jede Website anwenden kannst, deren Sichtbarkeit ohne erkennbaren Grund sinkt.

01

Reproduzieren, bevor du redirectest. Ein einzelner Crawl reicht nie für eine 5xx-Diagnose.

02

Sequenziell gegen parallel testen. Ein curl-Loop mit einer Anfrage pro Sekunde ist die schärfste Differenzialdiagnose.

03

Hypothesen ranken, nicht raten. Wer alle möglichen Ursachen rankt und einzeln ausschliesst, übergibt einen Befund statt einer Vermutung.

Häufige Folgefragen

Sichtbarkeit fällt ohne erkennbaren Grund? Lass uns 30 Minuten draufgucken.

Wenn dir 138 angeblich tote URLs in den Reports stehen oder die Crawl-Frequenz ohne Erklärung sinkt, kann eine Drei-Crawl-Verifikation in 8 Tagen Klarheit bringen. Erstes Telefonat kostenlos, NDA Standard.