Auf stabiler Infrastruktur kommt das nie vor! Es passiert nach großen technischen Änderungen - Plattform-Migrationen, Hosting-Wechsel, CDN-Updates - weil genau dann verborgene Probleme an die Oberfläche kommen. Nach unserer Erfahrung werden über 70 % der Crawls nach Migrationen beschuldigt, unabhängig von Crawl-Geschwindigkeit oder Website-Größe.
Das Timing erzeugt eine einfache - aber falsche - Schlussfolgerung:
Migration heute + Crawl heute + Probleme heute = Crawl ist das Problem.
Warum Post-Migrations-Crawls Probleme aufdecken
SEO-Crawls auf stabilen Seiten verursachen praktisch keine Last: Die Infrastruktur ist optimiert, Caches sind warm und Traffic-Muster bekannt.
Migrationen ändern all das. Neues CMS, neues Hosting, neue CDN-Regeln, überarbeitete Templates, neue Sicherheitsschichten - alles verhält sich anders. Der Crawl nach der Migration ist oft der erste systematische Traffic, der auch selten besuchte Seiten und uncached Pfade trifft.
Beim Crawl überprüfst du:
- Weiterleitungen wurden korrekt implementiert und Ketten minimiert
- Seiten, die indexiert werden sollen, sind erreichbar und liefern 200-Statuscodes
- Die interne Verlinkungsstruktur wurde während der Migration nicht zerstört
- Canonical-Tags, hreflang und strukturierte Daten haben die Migration überstanden
- Page Speed und Core Web Vitals haben sich nicht verschlechtert
Das führt zu einer unvermeidlichen Kollision: Der Moment, in dem du am meisten crawlen musst, ist genau der Moment, in dem Infrastrukturprobleme am wahrscheinlichsten auftreten..
Die Migration geht live. Die manuellen Tests sehen gut aus.
SEO-Crawl beginnt - das erste Mal erhält das System strukturierte, umfassende Requests.
Performance verschlechtert sich. Logs zeigen den SEO-Crawler klar. Er wird zum Hauptverdächtigen.
Crawl wird gestoppt. Der Traffic sinkt. Alle gehen davon aus, dass der Crawl die Ursache war.
Probleme treten wieder auf, obwohl der Crawler seit über 12 Stunden aus ist.
Die echte Ursache war unabhängig - Caching, Verbindungsgrenzen, CDN-Einstellungen, Codeineffizienzen oder unkontrollierter Bot-Traffic - aber das Team hat einen ganzen Tag damit verloren, dem falschen Problem nachzugehen.
Der Schuldzyklus kostet weit mehr als 30–60 Minuten. Er kann die Validierung über Tage verzögern, Entwicklerteams auf falsche Fährten schicken und echte Infrastrukturprobleme weiter die User Experience beeinträchtigen. Bis klar wird, dass der Crawler unschuldig ist, ist wertvolle Post-Migrationszeit bereits verloren.
Dein Crawl hat das Problem nicht verursacht - aber er ist Teil der Gesamtlast, die jetzt auf die Infrastruktur trifft. Und weil dein Crawl in den Logs am sichtbarsten ist, bekommt er die Schuld.
Was bei Migrationen tatsächlich schiefgeht
Migrationen führen zu spezifischen Infrastrukturänderungen, die nur unter realen Traffic-Mustern sichtbar werden.
1. Kapazitätsannahmen stimmen nicht mit Produktion überein
Staging-Umgebungen sind verkleinert und spiegeln selten echte Traffic-Muster wider.
Häufige Blindspots:
- Bot-Traffic-Volumen: Lasttests simulieren menschliches Verhalten, aber 51–60 % des Produktionstraffics sind Bots
- Datenbank-Performance bei hoher Last: Abfragen, die mit 100.000 Zeilen schnell laufen, timeouten bei 10 Millionen
- Verbindungs-Pool-Erschöpfung: Neue Infrastruktur-Limits zu niedrig für echte gleichzeitige Requests
- CDN-Verhalten unter Last: Cache-Misses, Origin-Shielding, Failover lassen sich im Staging nicht vollständig testen
- Drittanbieter-API-Rate-Limits: Dienste, die im Test gut funktionierten, stoßen unter Produktionsbedingungen an ihre Grenzen
Lasttests simulieren menschliche Sessions, Pausen und wiederkehrende Besuche. Bots nicht: Sie feuern Requests ohne Pause ab, umgehen Caches, crawlen selten besuchte Seiten tief und verteilen Traffic auf viele IPs. Dein Lasttest validierte 10.000 menschliche Nutzer - Produktion handhabt 10.000 menschliche plus 15.000 Bot-Requests, die nie getestet wurden.
2. Code-Änderungen bringen versteckte Performance-Probleme
Migrationen beinhalten oft mehr als Infrastruktur: Teams refaktorisieren Code, aktualisieren Abhängigkeiten und „verbessern“ Dinge. Diese Änderungen können Performance-Probleme bringen, die nur unter Last sichtbar werden:
- N+1 Datenbankabfragen, die beim Testen mit kleinen Datensätzen gut funktionierten
- Ineffiziente Schleifen oder Algorithmen, die bei Hunderten von Datensätzen akzeptabel funktionieren, aber bei Tausenden von Datensätzen einen Timeout verursachen
- Neue Skripte von Drittanbietern oder Zählpixel, die den Seitenaufbau verlangsamen
- Änderungen am Rendering, die Seiten rechenintensiver machen
Diese Probleme tauchen bei manuellen Tests nicht auf, da Entwickler nur kleine, saubere Datensätze testen und wenige Seiten besuchen. Dein Crawl ist das erste System, das jede Seitenart systematisch trifft - inklusive Archive, Kategorieseiten und Edge Cases.
3. Bot-Traffic, den niemand eingeplant hat
Die alte Infrastruktur hatte optimierte Bot-Regeln.
Neue Infrastruktur? Security-Teams starten oft mit Default-Regeln, die zu streng (blockieren legitime Crawler) oder zu locker (erlauben aggressives Scraping) sind. Monitoring hat keine Baselines, daher schwer zu erkennen, ob Traffic normal ist.
Inzwischen haben es bösartige Akteure oft gezielt auf neu migrierte Websites abgesehen. Sie suchen nach häufigen Migrationsfehlern: ungeschützte Staging-URLs, falsch konfigurierte Weiterleitungen, nicht übernommene Sicherheits-Header oder nicht zugängliche Admin-Panels. Dein SEO-Crawl beginnt zur gleichen Zeit, in der dieser opportunistische Bot-Traffic die neue Infrastruktur entdeckt.
Das Sichtbarkeits-Paradoxon: Warum dein Crawler immer zuerst auffällt
Wenn Probleme auftauchen, ist dein Crawler der offensichtliche Verdächtige - nicht, weil er Probleme verursacht, sondern weil er darauf ausgelegt ist, sichtbar zu sein.
Professionelle Crawler identifizieren sich eindeutig, während sich böswillige Bots hinter Chrome-Benutzeragenten verstecken, IPs rotieren und die Last verteilen.
- Identifizieren sich klar
- Dokumentierte IP-Bereiche
- Vorhersehbare Zugriffsmuster
- Respektieren robots.txt
- Leicht in Protokollen zu finden
- 2-5% des Gesamtverkehrs
- Spoofen Chrome/Firefox
- Rotieren durch Tausende von IPs
- Ahmen menschliches Verhalten zeitlich nach
- Ignorieren robots.txt
- WOLLEN unsichtbar sein
- 37 % des Traffics
Teams sehen die 200 Requests/Min von deinem Tool - aber nicht die 10.000/min von verteilten Bots.
“Bei jeder HTTP-Anfrage fungiert der User-Agent-Header als selbsterklärter Ausweis... Entscheidend ist jedoch, dass diese Identität vollständig selbst gemeldet wird.”
Wenn die Krisensituation eintritt: So reagierst du
Erstens, die harte Wahrheit: Wenn jemand anruft und sagt, dass dein Crawler Probleme macht, stoppe den Crawl sofort. Das ist kein Eingeständnis eines Fehlers - es ist professionelle Höflichkeit und kluges Krisenmanagement - es grenzt die Variablen ein und zeigt guten Willen.
Dann leite die Untersuchung zur richtigen Diagnose:
Fragen, die die Geschichte enthüllen
- “Welcher Prozentsatz des Traffics kommt vom Crawler?” Bemühe dich um Prozentsätze, nicht um absolute Zahlen. “1.000 Anfragen pro Minute” klingt überwältigend. “2,3% des gesamten Datenverkehrs” malt schon ein ganz anderes Bild.
- “Wie viele der Anfragen unseres Crawlers sind HTML-Seiten vs. statische Assets?” Moderne SEO-Crawler rendern JavaScript und fordern HTML sowie alle Assets (Bilder, CSS, JS, Schriftarten) an. Aber nur die HTML-Anfragen belasten deine Infrastruktur wirklich - sie greifen auf Datenbanken zu, führen Backend-Code aus und verbrauchen CPU. Statische Inhalte werden in der Regel über CDN bereitgestellt und belasten die Ursprungsserver nicht. Professionelle Crawler zwischenspeichern auch häufig genutzte Assets, so dass nur 3-5 einzigartige Ressourcen pro Seite neue Anfragen generieren. Bitte sie, in ihrer Analyse die HTML-Anfragen von den Asset-Anfragen zu trennen - wenn 70% der Crawler-Anfragen zwischengespeicherte Assets sind, sind die tatsächlichen Auswirkungen auf den Ursprungsserver minimal.
- “Wann genau haben die Performance-Probleme begonnen?” Vergleiche den Beginn deines Crawls mit dem Zeitpunkt, an dem die Migration live ging. Oft haben die Probleme schon vor deinem Crawl begonnen.
- “Treten Probleme nach Crawl-Stopp noch auf?” Wenn die Probleme weiterhin bestehen, nachdem du deinen Crawler gestoppt hast, ist das der unmittelbare Beweis dafür, dass er nicht die Ursache war.
- “Wie sieht die Aufschlüsselung des Datenverkehrs nach User-Agent aus?” Hilf ihnen, nicht nur “deinen Crawler gegen alle anderen” zu betrachten, sondern das gesamte Bild des Bot-Traffics zu sehen.
Segmentierung für bessere Log-Analysen
Die meisten Teams beginnen damit, die Gesamtzahl der Requests nach User Agent zu prüfen – eine Methode, die unvollständig und oft irreführend ist. Stattdessen sollte man eine aussagekräftigere Segmentierung nutzen, um die tatsächlichen Lastquellen zu identifizieren:
Segmentierung nach geografischer Verteilung: Plötzliche Spitzen aus unerwarteten Regionen deuten meist auf Bots hin. Wenn plötzlich 40 % des Traffics aus einem Land kommen, aus dem es keine reale Nutzerbasis gibt, handelt es sich sehr wahrscheinlich um Scraper, neu aktive AI-Crawler, automatisierte Tests oder CDN-Routing-Probleme.
Segmentierung nach IP-Präfixen: Menschlicher Traffic zeigt eine große Vielfalt an IPs mit typischen ISP-Clustern. Tausende ähnliche Requests von vielen unterschiedlichen IPs weisen dagegen auf verteilte Bots, Residential-Proxy-Scraper oder Low-Level-DDoS-Muster hin. Legitime Crawler nutzen kleine, stabile IP-Bereiche, die leicht zu verifizieren sind.
Segmentierung nach URL-Mustern und Endpunkten: Menschen und „gute“ Crawler verteilen ihren Traffic über normale Seiten. Häufungen auf Login-Seiten, Such-Endpunkten, APIs oder Formularen deuten auf Credential-Stuffing, Vulnerability-Scans oder gezieltes Scraping hin.
Segmentierung nach Request-Timing: Menschen zeigen unregelmäßige Muster mit natürlichen Pausen. Gute Crawler sind konstant und vorhersehbar. Bösartige oder automatisierte Aktivitäten laufen häufig 24/7, senden perfekt getaktete Requests oder treten plötzlich in Bursts aus neuen Quellen auf.
Vergleiche die Behauptungen der User Agents mit dem tatsächlichen Verhalten: Viele Bots fälschen ihre User Agents. Vergleiche den angegebenen UA mit IP-Eigentümer, Request-Rate und geografischer Herkunft. Ein „Chrome auf Windows“-UA mit 100 Requests pro Sekunde aus einem Rechenzentrums-IP-Bereich ist kein Mensch – sondern falsch klassifizierter Bot-Traffic.
„Euer Crawler hat 50.000 Requests in zwei Stunden erzeugt!“ klingt dramatisch und führt oft dazu, dass Crawls sofort gestoppt werden. „Euer Crawler macht in diesem Zeitraum 2,3 % des gesamten Traffics aus“ verändert das Gespräch grundlegend – von Schuldzuweisung hin zu Ursachenanalyse. Bestehe immer auf Prozentwerten und Kontext, nicht auf absoluten Zahlen, die ohne Vergleich bedrohlich klingen.
Was eine saubere Untersuchung normalerweise zeigt
Wenn Teams tiefer einsteigen und sauber segmentieren sowie Zeitachsen analysieren, zeigen sich meist folgende Muster:
- Cache-Fehlkonfiguration: CDN-Regeln wurden nicht korrekt migriert, sodass ein Großteil des Traffics den Cache umgeht und direkt die Origin-Server trifft
- Erschöpfte Datenbank-Connection-Pools: Die neue Infrastruktur ist mit zu wenigen DB-Verbindungen für das tatsächliche gleichzeitige Query-Volumen konfiguriert
- Aggressiver AI-Crawler-Traffic: Bots wie GPTBot oder ClaudeBot, die robots.txt ignorieren und Seiten alle paar Stunden erneut abrufen – mit 10–20× mehr Traffic als professionelle SEO-Crawler
- Verteilte Scraping-Operationen: Tausende IPs nutzen Residential Proxies und imitieren menschliche User Agents, um unentdeckt Inhalte abzugreifen
- Migrationsspezifische Performance-Probleme: Code-Änderungen mit ineffizienten Queries oder Algorithmen, die nur mit Produktionsdatenmengen timeouten
In der überwiegenden Mehrheit der Fälle macht dein SEO-Crawler während des Incident-Zeitraums nur 2–5 % des Gesamttraffics aus. Er ist sichtbar, identifizierbar und leicht in Logs zu finden – aber nicht ursächlich.
Den Schuldkreislauf verhindern: Koordinierung vor der Migration
Infrastrukturprobleme lassen sich nicht verhindern. Aber du kannst verhindern, dass dein Crawler dafür verantwortlich gemacht wird.
Vor der Migration: Erwartungen klar setzen
Die wichtigsten Gespräche finden vor dem Go-Live statt. Diese Vorbereitung dient nicht nur der Crawl-Freigabe – sie verhindert den teuren Schuldzyklus, der wertvolle Debugging-Zeit kostet:
- Crawl-Plan schriftlich festhalten: Wann startet der Post-Migration-Crawl, was wird validiert, erwartete Dauer und geschätztes Request-Volumen
- Technische Details vorab teilen: Gib dem Infrastrukturteam deine IP-Bereiche, User-Agent-Strings und maximalen Anfrageraten an, damit sie die Überwachung auf eine Whitelist setzen und entsprechende Warnungen einstellen können.
- Lege Kommunikationsprotokolle fest: Vereinbare, an wen du dich bei Problemen wendest, welche Kennzahlen ihr beide überwacht und welche Schwellenwerte eine Drosselung oder Unterbrechung des Crawlings rechtfertigen
- Kläre über das Sichtbarkeits-Paradoxon auf: Dein Crawler ist sichtbar, stellt aber nur einen kleinen Teil des Bot-Traffics dar. In den meisten Post-Migration-Fällen verursachen SEO-Crawler 2–5 % des Traffics, bekommen aber 100 % der Schuld.
- Vereinbare vorab die diagnostischen Schritte: Bei Performance-Problemen werden zuerst Traffic-Anteile, Content-Typen und geografische Verteilung geprüft – nicht reflexartig der Crawl gestoppt.
Eine häufig verpasste Chance in der Pre-Migration-Phase ist das Crawlen im Staging. Klassische Lasttests simulieren Menschen, ignorieren aber die 50–60 % Bot-Traffic im Live-Betrieb. Crawle das Staging mit erhöhter Rate – z. B. 20× normal – um realistische Bot-Last zu simulieren und JS-Rendering, Asset-Fetching und systematische Requests zu testen. In Kombination mit User-Load-Tests deckt das Kapazitätsgrenzen, Cache-Probleme und Datenbank-Bottlenecks vor dem Go-Live auf.
Während der Migrationswoche: Konservativ starten
Auch mit bester Planung bleiben Migrationen unvorhersehbar. Passe dein Vorgehen an:
- Warte ein paar Stunden nach dem Go-Live: Gib der Infrastruktur Zeit, damit sich die Caches aufwärmen können und das Monitoring eine erste Basislinie erstellen kann.
- Starte mit reduzierter Geschwindigkeit: Beginne mit 3-5 URLs pro Sekunde und nicht mit dem maximalen Durchsatz, auch wenn die Website zuvor höhere Raten bewältigt hat
- Überwache die Reaktionszeiten aktiv: Achte auf steigende Latenzzeiten, die auf eine Überlastung der Infrastruktur hindeuten, und drossle sie automatisch, wenn die Antwortzeiten normale Schwellenwerte überschreiten.
- Crawle in Phasen, wenn nötig: Bei umfangreichen Migrationen solltest du zuerst die Abschnitte mit hoher Priorität crawlen, die Stabilität der Infrastruktur prüfen und dann die gesamte Website erfassen.
Nach auftretenden Problemen: Lösung dokumentieren
Wenn Probleme auftreten und gelöst werden (was immer der Fall ist), erstelle eine Dokumentation, die zukünftige Crawls schützt:
- Zeitleiste der Ereignisse: Wann die Migration live ging, wann dein Crawl begann, wann die ersten Probleme auftraten, wann dein Crawl endete, wann die Probleme fortgesetzt oder gelöst wurden
- Traffic-Aufschlüsselung: Anteil deines Crawlers am Gesamttraffic, Segmentierung anderer Bot-Quellen
- Die eigentliche Ursache: Fehlkonfiguration der Infrastruktur, Bot-Traffic oder Code-Probleme
- Lösungsschritte: Welche Änderungen das eigentliche Problem behoben haben (Cache-Konfiguration, Abstimmung des Verbindungspools, Bot-Blockierungsregeln usw.)
Diese Dokumentation schützt den nächsten Crawl vor reflexartiger Schuldzuweisung und schafft nachhaltiges technisches Verständnis.
Der reale Impact professioneller SEO-Crawler
Zu verstehen, was legitime Crawler tun – und was nicht – hilft, ihren Wert zu verteidigen, wenn Kritik aufkommt.
Professionelle Crawler sind darauf ausgelegt, "höflich" zu sein:
- Konservative Ausfallraten: Beginnend mit 5-10 URLs pro Sekunde mit klaren Empfehlungen zur Abstimmung mit den technischen Teams vor der Erhöhung
- Automatische Drosselung: Wenn die Antwortzeiten des Servers steigen, wird die Crawl-Geschwindigkeit automatisch reduziert, um der Infrastruktur mehr Spielraum zu geben.
- Eindeutige Identifizierung: Konsistente Benutzeragenten und Dokumentation von IP-Bereichen, damit die Betriebsteams eine Whitelist erstellen oder entsprechend überwachen können
- Reagiert auf Serversignale: Automatische Ratenreduzierung bei 503, 429 oder wiederholten 500 Statuscodes
- Flexible Konfiguration: Die Fähigkeit, das Crawling-Verhalten an die spezifischen Anforderungen der Website und die technische Koordination mit den Kunden anzupassen
„Wenn bei Migrationen Probleme auftreten, wird der SEO-Crawler zum Sündenbock, weil er der sichtbarste Traffic in den Logs ist. Aber Sichtbarkeit ist keine Kausalität – unsere Crawler sind bewusst identifizierbar und gut erzogen, was sie paradoxerweise zum ersten Verdächtigen macht.“
Die wachsende Welle von AI-Crawlern und Scrapern hingegen ist aggressiver Bot-Verkehr, der die Infrastruktur tatsächlich überfordert.
Wir haben gesehen, wie AI-Bots Terabytes an Bandbreite verbrauchen und massive Verlangsamungen verursachen – während der gut erzogene SEO-Crawler beschuldigt wird, nur weil er erkennbare Spuren hinterlässt.
- AI-Crawler Die explosionsartige Zunahme neuer AI-Bots (GPTBot, ClaudeBot, Perplexity und Dutzende anderer) bedeutet, dass es jetzt viel mehr Crawler gibt, die gleichzeitig auf Websites zugreifen. Während etablierte Crawler wie der Googlebot nach jahrelanger Verfeinerung hochoptimiert sind, lernen diese neueren KI-Crawler immer noch optimale Crawl-Muster, und ihr kombiniertes Volumen führt zu noch nie dagewesenen Bot-Traffic-Spitzen
- Content Scraper die robots.txt komplett ignorieren und Wohn-Proxys verwenden, um die Erkennung zu umgehen
- Vulnerability-Scanner die nach häufigen Migrationsfehlern und falsch konfigurierten Sicherheitseinstellungen suchen
- Verteilte DDoS-Aktivitäten die unter den pro-IP-Ratengrenzen bleiben, aber die Infrastruktur kollektiv überfordern
Das Muster durchbrechen
Migrationen führen zu neuer Komplexität. SEO Crawls machen sie sichtbar.
Dein Crawler wird zum Sündenbock, weil er sichtbar ist - nicht weil er die Ursache ist.
Den Schuldzyklus zu durchbrechen erfordert:
Erwartet Instabilität der Infrastruktur nach der Migration
Zu verstehen , dass Crawls Probleme aufdecken, nicht erzeugen
Saubere Log-Analyse statt bloßer Request-Zahlen
Koordinierung vor dem Go-Live , damit Ursachen analysiert werden – nicht sichtbarer Traffic
Denn das eigentliche Problem waren nie deine 200 Requests pro Minute – sondern eine neue Infrastruktur, die mit Produktionsverhalten inklusive 50–60 % Bot-Traffic nie getestet wurde.
English 
German