Warum gerät der SEO-Crawler nach der Migration unter Verdacht?

Das typische Muster

Die Migration geht am frühen Nachmittag live, die manuellen Tests sehen gut aus. Am Abend startet der Crawl zur Prüfung. Kurz danach wird die Website langsam, und im Log steht gut sichtbar der SEO-Crawler.

Das gleiche Zeitfenster verleitet zu einem falschen Schluss. Migration, Crawl und Probleme fallen auf denselben Tag, also muss der Crawl schuld sein. Nach unserer Erfahrung aus vielen Migrationen gerät der Crawl danach in den meisten Fällen unter Verdacht, unabhängig von Tempo und Größe der Website. Gezählt haben wir das nicht systematisch. Verloren geht dabei oft mehr als eine Stunde. Teams suchen tagelang an der falschen Stelle, und die eigentliche Prüfung nach dem Go-live stockt.

Warum passiert das gerade nach Migrationen?

Auf einer eingespielten Website erzeugt ein SEO-Crawl kaum spürbare Last. Die Infrastruktur ist abgestimmt, die Caches sind warm, und die Muster im Traffic sind bekannt. Nach einer Migration ist vieles neu, vom CMS über Hosting und CDN bis zu Templates und Sicherheitsregeln. Der Crawl ist oft der erste Traffic, der auch selten besuchte Seiten und ungecachte Pfade abruft. Geprüft wird dabei, ob Weiterleitungen stimmen, ob Seiten mit 200 antworten, ob interne Links, Canonicals, hreflang und strukturierte Daten erhalten sind und ob die Ladezeiten passen.

1. Die Kapazität passt nicht zur Produktion

Staging-Umgebungen sind kleiner und bilden echten Traffic selten ab. Lasttests simulieren Menschen mit Sitzungen, Pausen und Besuchen auf beliebten Seiten. Bots rufen ohne Pause ab, umgehen Caches und gehen tief in selten besuchte Seiten. Laut Bad Bot Report 2025 von Imperva war 2024 mehr als die Hälfte des Web-Traffics automatisiert, nämlich 51 %. Schädliche Bots machten 37 % aus. Die Zahlen stammen von einem Anbieter für Bot-Schutz. Die Methodik ist im Blogbeitrag nicht beschrieben.

• Datenbankabfragen, die mit wenigen Datensätzen schnell sind, laufen mit Millionen Datensätzen in ein Timeout.
• Die Zahl der Datenbankverbindungen ist für die echte Last zu knapp eingestellt.
• Wie das CDN mit Cache-Misses und Ausfällen umgeht, lässt sich auf Staging kaum testen.
• Externe Dienste stoßen erst unter Produktionslast an ihre Limits.

2. Code-Änderungen bremsen unter Last

Viele Teams nutzen die Migration, um Code umzubauen und Abhängigkeiten zu aktualisieren. Dabei entstehen Probleme, die erst unter Last auffallen. Dazu gehören zu viele Einzelabfragen an die Datenbank pro Seite, Schleifen, die bei Tausenden Datensätzen zu langsam werden, neue Skripte und Tracking-Pixel sowie Templates, die aufwendiger zu berechnen sind. Bei manuellen Tests mit wenigen Seiten bleibt das unsichtbar. Der Crawl ruft dann zum ersten Mal Archive, Kategorien und seltene Parameter-Kombinationen ab.

3. Bot-Traffic, den niemand eingeplant hat

Die alte Infrastruktur hatte abgestimmte Regeln für Bots. Auf der neuen gelten oft Standardregeln, die entweder legitime Crawler blockieren oder aggressives Scraping durchlassen. Das Monitoring hat noch keine Vergleichswerte. Deshalb ist schwer zu sagen, was normal ist. Gleichzeitig suchen Scanner gezielt nach typischen Migrationsfehlern wie offenen Staging-URLs, fehlenden Security-Headern oder erreichbaren Admin-Bereichen.

Warum fällt der SEO-Crawler zuerst auf?

Ein professioneller Crawler gibt sich zu erkennen. Der User-Agent ist laut HTTP-Standard eine Selbstauskunft des Clients, und schädliche Bots geben sich dort gern als Chrome oder Firefox aus.

Nach unserer Erfahrung macht der SEO-Crawler im Zeitfenster eines solchen Vorfalls meist nur 2 bis 5 % des gesamten Traffics aus. Auch das ist ein Erfahrungswert aus Projekten und keine systematische Messung.

Wenn der Anruf kommt

Meldet sich das Infrastruktur-Team, stoppst du den Crawl sofort. Damit gibst du keinen Fehler zu. Du trennst die Variablen und zeigst Entgegenkommen. Danach helfen fünf Fragen bei der Diagnose.

1. Welchen Anteil an allen Anfragen hatte der Crawler? „1.000 Anfragen pro Minute“ klingt nach viel. „2,3 % des Traffics“ ordnet die Zahl ein.
2. Wie viele Anfragen gingen auf HTML und wie viele auf Assets? Ein rendernder Crawler lädt Bilder, CSS, JavaScript und Schriften mit. Last auf dem Origin erzeugen vor allem die HTML-Anfragen, Assets kommen meist aus dem CDN.
3. Wann genau begannen die Probleme? Oft lag der Beginn vor dem Crawl oder zwischen Go-live und Crawl.
4. Halten die Probleme an, seit der Crawl steht? Dann war er nicht die Ursache.
5. Wie verteilt sich der Traffic auf alle User-Agents? Der Blick auf alle Bots zeigt mehr als „Crawler gegen den Rest“.

Das Log richtig segmentieren

Meist zeigt sich dann eine dieser Ursachen. CDN-Regeln wurden nicht sauber übernommen, und der Traffic geht am Cache vorbei. Die Datenbank hat zu wenige Verbindungen. KI-Bots oder verteilte Scraper erzeugen viel Last. Manchmal bremst auch neuer Code erst bei echten Datenmengen. Wie du Bots im Log erkennst, steht im Ratgeber Logfile-Analyse.

Vor dem Go-live abstimmen

Schwächen einer neuen Infrastruktur lassen sich vorab kaum ausschließen. Dass der Crawler dafür die Schuld bekommt, lässt sich vermeiden. Diese Punkte klärst du mit dem Infrastruktur-Team vorab.

• Crawl-Plan schriftlich, mit Startzeit, Zielen, Dauer und erwarteter Zahl an Anfragen.
• IP-Adressen, User-Agent und maximale Rate, damit das Team den Crawler freigeben und beobachten kann.
• Ansprechpartner auf beiden Seiten und Schwellenwerte, ab denen der Crawl gedrosselt oder pausiert wird.
• Ein kurzer Hinweis, dass der Crawler im Log auffällt, aber nur einen kleinen Teil des Bot-Traffics ausmacht.
• Vereinbarte Diagnose-Schritte für den Ernstfall, also Anteile, HTML gegen Assets und Herkunft prüfen, bevor jemand eine Ursache benennt.

Bot-Last auf Staging testen

Klassische Lasttests lassen Bots meist weg. Lass deshalb den Crawler auf Staging mit deutlich erhöhter Rate laufen. Bewährt hat sich etwa das 20-Fache des Normalbetriebs. Zusammen mit dem Lasttest für Nutzer zeigt das Engpässe bei Kapazität, Cache und Datenbank vor dem Go-live. Auf Staging darf der Crawl hart sein, in der Produktion bleibt er behutsam. Mehr dazu im Ratgeber SEO-Check vor dem Go-live.

In der Woche der Migration

1. Nach dem Go-live ein paar Stunden warten, bis Caches warm sind und das Monitoring erste Vergleichswerte hat.
2. Mit reduzierter Rate starten, auch wenn die alte Website mehr vertragen hat. Das Tempo stimmst du vorher mit dem Infrastruktur-Team ab.
3. Antwortzeiten beobachten und drosseln, sobald sie steigen.
4. Bei großen Websites in Abschnitten crawlen, die wichtigsten Bereiche zuerst.

Danach dokumentieren

Halte nach einem Vorfall fest, wann die Migration live ging, wann der Crawl startete und stoppte, wann die Probleme begannen und endeten. Dazu kommen der Anteil des Crawlers am Traffic, die tatsächliche Ursache und die Maßnahme, die sie behoben hat. Diese Notiz schützt den nächsten Crawl und baut Wissen im Team auf.

Was tut ein rücksichtsvoller Crawler?

KI-Bots und robots.txt

GPTBot und ClaudeBot befolgen laut OpenAI und Anthropic die robots.txt. Anthropic unterstützt zusätzlich Crawl-delay (Stand 07.04.2026). OpenAI beschreibt, wie du GPTBot und OAI-SearchBot per robots.txt steuerst, und veröffentlicht die IP-Bereiche. Für ChatGPT-User, der Seiten im Auftrag eines Nutzers abruft, gelten die Regeln laut OpenAI unter Umständen nicht. Last durch KI-Bots entsteht vor allem durch Menge und häufige Abrufe. Ob ein Bot echt ist, prüfst du über die veröffentlichten IP-Bereiche. Mehr dazu im Ratgeber KI-Crawler.

Häufige Fehler

• Den Crawl direkt nach dem Go-live mit voller Rate starten.
• Absolute Anfragezahlen vergleichen statt Anteile am Traffic.
• Asset-Anfragen eines rendernden Crawlers als Last auf dem Origin zählen.
• Lasttests nur mit simulierten Nutzern fahren.
• IP-Adressen und User-Agent des Crawlers erst nach dem ersten Vorfall weitergeben.
• Nach dem Stopp nicht prüfen, ob die Probleme weiter bestehen.

Häufige Fragen