301-Redirects einrichten
Standard-Vorgehen aller drei Vor-Anbieter: 138 URLs als tot abhaken, Redirect-Liste bauen, abrechnen.
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.
Ausgangslage
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 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.
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.
8 Tage · Schritt für Schritt
Vier Phasen, dokumentiert und reproduzierbar. Vom ersten Standard-Crawl bis zur belegten Hypothese, jeder Schritt einzeln im Repo nachvollziehbar.
Erster Screaming-Frog-Crawl mit Default-Konfiguration (5 Threads). Ergebnis: 138 URLs mit Status 502. URL-Liste exportiert.
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.
Dritter Crawl mit erweitertem Set (417 statt 360 URLs): 40 × 502, gleiches Pattern, deutlich weniger absolut. Fehler korrelieren mit Anzahl paralleler Requests.
7 technische Hypothesen formuliert und priorisiert. Top-Hypothese: PHP-FPM-Worker-Pool-Erschöpfung. Übergabe an Agentur mit Server-Diagnose-Kapitel im Audit-Report.
Stack & Werkzeuge
Was Kunden sagen
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.
Diese Diagnose ist kein Spezialfall. Sie ist ein Pattern, das du auf jede Website anwenden kannst, deren Sichtbarkeit ohne erkennbaren Grund sinkt.
Reproduzieren, bevor du redirectest. Ein einzelner Crawl reicht nie für eine 5xx-Diagnose.
Sequenziell gegen parallel testen. Ein curl-Loop mit einer Anfrage pro Sekunde ist die schärfste Differenzialdiagnose.
Hypothesen ranken, nicht raten. Wer alle möglichen Ursachen rankt und einzeln ausschließt, übergibt einen Befund statt einer Vermutung.
Ein einzelner Crawl ist eine Momentaufnahme. Server-Probleme, die unter paralleler Last entstehen, treten in unterschiedlicher Stärke je nach Tageszeit, Cache-Zustand und gleichzeitigem Traffic auf. Erst die Wiederholung zeigt, ob das Pattern strukturell ist.
Die Drei-Crawl-Verifikation kostet rund 30 Minuten Entwickler-Zeit pro URL-Set, also typisch 1 bis 2 Stunden. Das entspricht 108 bis 216 Euro Mehrinvestition gegenüber dem Risiko einer falschen Empfehlung.
Google reduziert die Crawl-Rate proportional zur Fehlerrate. Bleiben Fehler länger als 48 Stunden erhalten, beginnt Google die betroffenen URLs aus dem Index zu entfernen.
Ein einzelner Browser-Aufruf erzeugt nur einen Request. Concurrency-Probleme entstehen erst bei mehreren parallelen Requests, typisch bei Crawlern mit 5–8 Threads.
Ja, mit Screaming Frog (Enterprise oder Free) und einem curl-Loop. Die Methode ist dokumentiert und reproduzierbar, jede technische Agentur kann sie einsetzen.
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.