Umzug auf ein CDN ohne SEO-Schaden: Warum der Googlebot danach plötzlich mehr crawlt und wie du Server, Cloudflare und Black-Friday-Seiten vorbereitest

01 / Der Effekt

Warum der Googlebot nach dem CDN-Umzug mehr crawlt.

Ein CDN (Content Delivery Network) verteilt deine Seiten, Bilder, CSS- und JavaScript-Dateien auf Server in vielen Rechenzentren, die näher an den Besuchern stehen. Das senkt die Ladezeit und soll den eigenen Server, den sogenannten Ursprungsserver, entlasten. Genau das Gegenteil erleben manche Betreiber in den ersten Tagen. Google schreibt im Search Central Blog, dass sich Website-Betreiber melden, bei denen der Crawler-Traffic direkt nach dem Umzug fast sofort ansteigt [1].

Der Grund liegt darin, wie Google festlegt, wie viel es crawlt. Jede Website hat ein Crawling-Kapazitätslimit, intern auch „Hostload“ genannt. Es begrenzt, wie lange und mit wie vielen parallelen Verbindungen Googles Crawler deinen Server beschäftigen [4]. Antwortet der Server gleichmäßig schnell, steigt das Limit. Wird er langsamer oder liefert Serverfehler (5xx) oder 429, sinkt es [4]. Zeigt dein DNS plötzlich auf ein schnelles CDN, sehen Googles Systeme kürzere Verbindungs- und Antwortzeiten. Für sie sieht es aus, als hättest du gerade neue Hardware bekommen, also fahren sie die Anfragerate hoch [1]. Das passiert nicht schlagartig, und viele CDNs glätten Lastspitzen, aber es passiert [1].

Der leere Cache ist das eigentliche Problem

Ein neues CDN startet mit leerem Cache. Beim ersten Abruf einer URL an einem Standort hat der Edge-Server noch keine Kopie. Er holt die Antwort beim Ursprungsserver, speichert sie und liefert sie aus. Erst ab dem zweiten Abruf derselben URL kommt sie direkt aus dem Cache [1]. Menschen rufen meist wenige beliebte Seiten auf, etwa Startseite, Top-Artikel oder laufende Aktionen. Die sind schnell im Cache. Crawler machen das Gegenteil: Sie gehen systematisch die ganze Breite deiner URLs durch [1]. Schnellere Antworten plus viele bisher nicht gecachte URLs bedeuten: Der Ursprungsserver trägt die Last, bis die Caches gefüllt sind [1].

Bei Cloudflare kommt eine Eigenheit dazu, die viele WordPress-Betreiber nicht kennen: Cloudflare cacht HTML und JSON standardmäßig nicht, sondern nur bestimmte Dateiendungen wie Bilder, CSS oder JavaScript [10]. Ohne eigene Cache-Regel geht also jeder Seitenabruf des Googlebots weiter an deinen Server, egal wie warm der Cache ist [10]. Das CDN macht dann die Bilder schnell, entlastet aber beim HTML wenig (Einschätzung). Ob du HTML cachen lässt, hängt davon ab, ob deine Seiten für alle gleich aussehen. Warenkorb, Kundenkonto und WordPress-Login dürfen nicht im Cache landen.

02 / Der teure Fehler

Pauschaler Bot-Schutz kann dich aus der Suche werfen.

Wer nach dem Umzug steil ansteigende Anfragen in den Server-Logs sieht, denkt schnell an einen Angriff. Der naheliegende Reflex: im CDN-Dashboard den Bot-Schutz für alles einschalten. Davor warnt Google ausdrücklich [1]. Pauschale Regeln behandeln jeden automatisierten Zugriff gleich, auch die Crawler, die du haben willst. Fängt ein CDN oder eine Web Application Firewall (WAF) Anfragen mit einem CAPTCHA oder einer anderen Prüfung ab, scheitern Googles Crawler daran [1].

Für Google sieht die Website dann absichtlich gesperrt oder kaputt aus. Bleibt das so, fahren die Crawler zurück, und Seiten sowie Shopping-Einträge fallen nach und nach aus der Suche [1]. Barry Schwartz fasst es bei Search Engine Roundtable so zusammen: Legitime Suchmaschinen-Crawler zu blockieren, kann ein viel größeres SEO-Problem werden als der ursprüngliche Anstieg [2].

So steuerst du das in Cloudflare

Google empfiehlt, im CDN und in der Firewall verifizierte Bots zuzulassen und unerwünschte Bots gezielt per robots.txt oder Regel zu sperren, statt alles Automatisierte zu blockieren [1]. In Cloudflare heißt das konkret:

• Verifizierte Bots: Cloudflare führt eine Liste von Bots, die sich eindeutig ausweisen (per Signatur, veröffentlichter IP-Liste oder Reverse DNS) und sich an robots.txt und vernünftige Abrufraten halten. Suchmaschinen-Crawler gehören ausdrücklich dazu [7].
• Bot Fight Mode (kostenlos): stellt erkannten Bots rechenintensive Aufgaben. Er lässt sich weder per WAF-Regel noch per Page Rule überspringen, „Skip“, „Bypass“ und „Allow“ wirken dort nicht [8]. Wenn du Ausnahmen brauchst, ist er das falsche Werkzeug. Angefochtene Anfragen siehst du unter Security › Analytics › Events mit dem Eintrag „Bot Fight Mode“ [8].
• Super Bot Fight Mode (ab Pro): lässt dich je Gruppe festlegen, was passiert: „Definitely automated“, „Likely automated“ und „Verified bots“. Ausnahmen legst du per WAF-Regel mit der Aktion „Skip“ an [9]. Verifizierte Bots sollten auf „Allow“ stehen (Einschätzung).

Wie du KI-Crawler in Cloudflare sperrst, ohne Googlebot, Bingbot und Applebot zu treffen, habe ich in Cloudflare prüft jetzt, ob Bots deine robots.txt einhalten beschrieben.

Ist das wirklich Google?

Ein User-Agent „Googlebot“ beweist nichts, den kann jeder setzen. Google beschreibt zwei Wege zur Prüfung [5]. Für Einzelfälle: Reverse-DNS-Abfrage der IP aus dem Log mit dem Befehl host. Der Name muss auf googlebot.com, google.com oder googleusercontent.com enden. Dann eine Vorwärts-Abfrage auf diesen Namen, die wieder die ursprüngliche IP ergeben muss [5]. Für viele Anfragen: die IP mit Googles veröffentlichten IP-Listen abgleichen [5]. Die JSON-Dateien liegen seit März 2026 unter developers.google.com/crawling/ipranges/, die alten Pfade unter /search/ werden auslaufen [13]. Wer eine eigene Firewall-Regel pflegt, sollte den neuen Ort verwenden.

03 / Vorbereitung

Cache vorwärmen, bevor du den DNS umstellst.

Googles zweiter Rat: Bevor der ganze Traffic über das neue CDN läuft, die wichtigsten Seiten in kontrolliertem Tempo über das CDN abrufen, damit die Caches gefüllt sind [1]. Google nennt drei Gruppen: die Seiten mit dem meisten Traffic, Seiten für kommende Spitzen wie Aktions- und Saisonseiten und die am häufigsten gecrawlten URLs [1]. Für einen Shop im November sind das die Black-Friday-Landingpage, die Kategorien mit Angeboten und die Bestseller.

Woher du die Listen bekommst (Einschätzung):

• Meister Traffic: GA4-Bericht „Landingpage“ oder der Leistungsbericht der Search Console, sortiert nach Klicks.
• Am häufigsten gecrawlt: deine Server-Logs, gefiltert auf verifizierte Google-IPs. Die Crawling-Statistik der Search Console zeigt nur Beispiel-URLs, keine vollständige Liste [6].
• Aktionsseiten: aus deiner Kampagnenplanung, auch wenn sie noch kaum Besucher haben.

Ein einfacher Weg ist eine Textdatei mit einer URL pro Zeile und eine kleine Schleife im Terminal, die jede URL einmal abruft und eine Sekunde wartet:

cat top-urls.txt | while read url; do
  curl -s -o /dev/null -w "%{http_code} $url\n" "$url"
  sleep 1
done

Zwei Grenzen solltest du kennen. Erstens füllt jeder Abruf nur den Cache des Standorts, über den er läuft, bei einem Abruf aus Hamburg also eher den nächstgelegenen [1] (Einschätzung zur Reichweite). Zweitens bringt das Vorwärmen beim HTML nichts, wenn dein CDN HTML gar nicht cacht, wie Cloudflare ohne Cache-Regel [10]. Ob ein Abruf aus dem Cache kam, zeigt bei Cloudflare der Antwort-Header CF-Cache-Status: HIT heißt aus dem Cache, MISS heißt vom Ursprungsserver geholt, DYNAMIC heißt, dass die Datei gar nicht für den Cache vorgesehen ist [15]. Google erwähnt augenzwinkernd noch eine Alternative: Freunde bitten, jeweils zwei verschiedene URLs aufzurufen [1].

Der richtige Zeitpunkt

Black Friday ist am 27. November 2026. Einen CDN-Umzug würde ich nicht in die Woche davor legen. Plane lieber zwei Wochen Puffer, damit du Crawling, Fehlerquoten und Ladezeiten in Ruhe beobachten kannst, oder verschiebe den Umzug auf Januar (Einschätzung). Was sonst vor dem Aktionstag zu tun ist, steht in meinem Black-Friday-Fahrplan für Shopify.

04 / Notbremse

429 oder 503 senden, aber nur kurz.

Wird die Last auf dem Ursprungsserver trotzdem kritisch, solange die Caches warmlaufen, empfiehlt Google eine kurze Bremse: per Server- oder CDN-Regel den Statuscode 429 (Too Many Requests) oder 503 (Service Unavailable) senden, für wenige Stunden, höchstens ein bis zwei Tage [1][3]. Sieht Google viele solche Antworten, drosselt es das Crawling für den ganzen Hostnamen, auch für URLs, die normal antworten. Sinkt die Zahl der Fehler, steigt die Rate automatisch wieder [3]. Mit dem Header Retry-After kannst du angeben, wann Google es wieder versuchen soll, in Sekunden oder als Datum [3].

Länger solltest du das nicht machen. Sieht der Googlebot über mehrere Tage dieselben Statuscodes auf einer URL, kann sie aus dem Index fallen [3]. Die Search-Console-Hilfe nennt an anderer Stelle „höchstens zwei oder drei Tage“ [6]. Halte dich an den strengeren Wert. Google warnt außerdem vor Nebenwirkungen: Neue Seiten werden langsamer gefunden, Preise und Verfügbarkeit langsamer aktualisiert, und Google-Ads-Kampagnen können pausiert werden [3]. Mitten in einer Rabattaktion ist das genau das, was du nicht willst.

Was du nicht tun solltest: Googlebot mit 403 oder einer Challenge-Seite abweisen [1]. Das ist für Google kein „bitte langsamer“, sondern eine Sperre. Wichtig ist auch, wo die 503 entsteht. Am besten im CDN oder Webserver, bevor PHP und WordPress überhaupt starten, sonst kostet jede abgewiesene Anfrage wieder Serverleistung. Warum das so ist, habe ich im Beitrag zu PHP2Shell erklärt. Wie Google mit den einzelnen Statuscodes umgeht, steht in 404-Fehler in der Search Console. Klappt das alles nicht, kannst du bei Google eine niedrigere Crawling-Rate beantragen. Die Prüfung kann mehrere Tage dauern, eine höhere Rate lässt sich nicht beantragen [3].

05 / Kontrolle

So prüfst du den Umzug in der Search Console.

Ob Google nach dem Umzug mehr crawlt und dabei auf Fehler stößt, zeigt der Bericht „Crawling-Statistik“. Du findest ihn unter Einstellungen › Crawling-Statistik. Er steht nur für Domain-Properties und URL-Präfix-Properties auf Stammebene zur Verfügung [6]. Google schreibt selbst, dass Websites mit weniger als 1.000 Seiten ihn wahrscheinlich nicht brauchen [6]. Bei einem CDN-Umzug lohnt der Blick trotzdem, weil du dort Vorher und Nachher siehst.

• Crawling-Anfragen insgesamt und durchschnittliche Reaktionszeit: Nach dem Umzug sollte die Reaktionszeit fallen. Steigen dann die Anfragen, ist das der beschriebene Effekt und kein Angriff [1][6].
• Hoststatus: zeigt Probleme beim Abruf der robots.txt, bei der DNS-Auflösung und der Serververbindung. Liegt etwa der Anteil fehlgeschlagener DNS-Anfragen an einem Tag über 5 %, gilt das als Problem [6]. Gerade beim DNS-Wechsel zum CDN ist das die wichtigste Anzeige.
• Nach Antwort: Ein wachsender Anteil Serverfehler (5xx) heißt, dass dein Ursprungsserver nicht mitkommt [6]. Ist die robots.txt einen Tag lang nicht erreichbar, pausiert Google das Crawling [6]. Achte darauf, dass dein CDN sie zuverlässig ausliefert.
• Nach Googlebot-Typ und Dateityp: zeigt, ob vor allem Seiten, Bilder oder Ressourcen abgerufen werden [6].

Der Bericht erfasst laut Google nicht jede Anfrage, kleine Abweichungen zu deinen Server-Logs sind normal [6]. Für die Zeit direkt nach dem Umzug sind die Logs deines Ursprungsservers ohnehin genauer, weil sie zeigen, was am Cache vorbei bei dir ankommt (Einschätzung). Setz dir außerdem in der Search Console eine Anmerkung zum Umzugstag, dann findest du ihn später im Leistungsbericht wieder.

06 / Shopify

Was das für Shopify-Shops heißt.

Für Shopify-Händler ist das Thema weitgehend erledigt. Jeder Shopify-Onlineshop läuft bereits über ein CDN, das Cloudflare betreibt, ohne Aufpreis [11]. Shopify rät sogar, Hinweise von Testtools zu ignorieren, die ein CDN empfehlen, weil es schon eingebaut ist [11]. Ein eigenes Cloudflare-Proxy davorzuschalten, ist nicht vorgesehen: Shopify unterstützt den Cloudflare-Proxy nicht, auch nicht als „Orange-to-Orange“. Wer seine Domain bei Cloudflare verwaltet, muss die Einträge, die auf Shopify zeigen, auf „DNS only“ stellen [12].

Damit hast du auch keinen Einfluss auf Bot-Regeln und Cache-Verhalten des Shopify-CDN. Eine Einstellung dafür beschreibt die Shopify-Hilfe nicht (Einschätzung). Für deine eigenen Crawler, etwa Screaming Frog, kannst du im Shopify-Admin unter Online Store › Preferences im Abschnitt „Crawler access“ eine Web-Bot-Auth-Signatur erstellen. Sie gilt höchstens drei Monate. Suchmaschinen brauchen keine, um deinen Shop zu indexieren [14]. Kümmere dich als Shopify-Händler vor Black Friday lieber um saubere Filter-URLs und Produktdaten. Welche Einstellungen dabei zählen, steht in Shopify-SEO: Die 12 Einstellungen, die kleine Shops wirklich voranbringen.

FAQ

Häufige Fragen zum CDN-Umzug.

Schadet ein CDN meinem Ranking?

Nicht an sich. Google beschreibt ein CDN als sinnvolle Verbesserung für wachsende Websites [1]. Zum Problem wird erst, wenn der Ursprungsserver unter der Crawl-Last zusammenbricht oder der Bot-Schutz Googles Crawler aussperrt [1].

Kann ich Googlebot per robots.txt kurz ausbremsen?

Die Search-Console-Hilfe nennt das als Sofortmaßnahme, die aber bis zu einem Tag braucht und nicht lange bleiben sollte [6]. Für einen vorübergehenden Engpass empfiehlt Google eher 429 oder 503 [1][3]. Zum Umverteilen von Crawling-Budget taugt robots.txt laut Google nicht [4].

Wie lange dauert es, bis sich das Crawling einpendelt?

Eine feste Dauer nennt Google nicht. Laut Hilfe sollte die Crawling-Frequenz über ein bis zwei Wochen relativ stabil sein [6]. Ich würde nach dem Umzug mindestens zwei Wochen beobachten (Einschätzung).

Quellen

Quellen

1. Google Search Central Blog (Cherry Prommawin, Gary Illyes): „Moving to a CDN without overwhelming your origin (or blocking Googlebot)“, 11. November 2026 – developers.google.com · abgerufen 12.11.2026.
2. Search Engine Roundtable (Barry Schwartz): „Google: How Moving to a CDN Can Accidentally Overwhelm Your Website“, 11. November 2026 – seroundtable.com · abgerufen 12.11.2026.
3. Google Crawling Infrastructure: „Reduce the Google crawl rate“, Stand 06.10.2026 – developers.google.com · abgerufen 12.11.2026.
4. Google Crawling Infrastructure: „Optimize your crawl budget“, Stand 22.07.2026 – developers.google.com · abgerufen 12.11.2026.
5. Google Crawling Infrastructure: „Verify requests from Google crawlers and fetchers“, Stand 20.03.2026 – developers.google.com · abgerufen 12.11.2026.
6. Search Console-Hilfe: „Bericht ‚Crawling-Statistik‘“ – support.google.com · abgerufen 12.11.2026.
7. Cloudflare Docs: „Verified bots“, Stand 02.11.2026 – developers.cloudflare.com · abgerufen 12.11.2026.
8. Cloudflare Docs: „Bot Fight Mode“, Stand 03.08.2026 – developers.cloudflare.com · abgerufen 12.11.2026.
9. Cloudflare Docs: „Super Bot Fight Mode“, Stand 03.08.2026 – developers.cloudflare.com · abgerufen 12.11.2026.
10. Cloudflare Docs: „Default cache behavior“ – developers.cloudflare.com · abgerufen 12.11.2026.
11. Shopify Help Center: „Improving your online store's web performance“ – help.shopify.com · abgerufen 12.11.2026.
12. Shopify Help Center: „Connecting a Cloudflare domain to Shopify“ – help.shopify.com · abgerufen 12.11.2026.
13. Google Search Central Blog (Gary Illyes): „New Location for the Google Crawlers' IP Range Files“, 31. März 2026 – developers.google.com · abgerufen 12.11.2026.
14. Shopify Help Center: „Crawling your store“ – help.shopify.com · abgerufen 12.11.2026.
15. Cloudflare Docs: „Cloudflare cache responses“ – developers.cloudflare.com · abgerufen 12.11.2026.

Alle Quellen am 12. November 2026 abgerufen. Aussagen ohne belastbare Quelle sind im Text als Einschätzung gekennzeichnet; die Ziffern in eckigen Klammern verweisen auf die Nummern dieser Liste.