CDN und SEO: wann es hilft und wo es schadet

Ein CDN ist kein Rankingfaktor, den Google direkt misst – aber es verändert eine ganze Reihe von Dingen, die Google sehr wohl misst und die genauso leicht in die falsche Richtung kippen können wie in die richtige. Die ehrliche Antwort auf die Frage, ob ein CDN dem Ranking hilft, lautet deshalb: manchmal ja, manchmal nein, und manchmal sabotiert es sich selbst, ohne dass irgendjemand das bemerkt, bis der organische Traffic einbricht.

Dieser Artikel behandelt bewusst nicht die allgemeine Frage nach Ladezeit, Hosting oder Time to First Byte – dazu gibt es eigene Diskussionen. Es geht hier um vier konkrete Mechanismen, über die ein CDN aktiv Schaden anrichten kann, ohne dass die Seite dadurch langsamer wird: blockierter Bot-Zugriff, gecachte Weiterleitungen und Fehlercodes, separate Bild-Hostnamen und geo-basierte Antworten.

CDN und Ranking: kein direkter Faktor, aber ein Hebel

Google hat wiederholt bestätigt, dass Ladeperformance über die Core Web Vitals in die Bewertung der Nutzererfahrung einfließt, allerdings als vergleichsweise schwaches Signal unter vielen anderen. Ein CDN kann diese Metriken verbessern, weil es statische Inhalte an einem Edge-Server ausliefert, der geografisch näher am jeweiligen Besucher liegt als der Origin-Server. Für eine Seite mit Publikum in Europa, Nordamerika und Asien kann das den gemessenen Largest Contentful Paint spürbar senken – vorausgesetzt, die Auslieferung ist tatsächlich korrekt konfiguriert.

Wichtig dabei: Die Core-Web-Vitals-Werte, die in die Bewertung einfließen, stammen aus echten Nutzerdaten, nicht aus dem Crawling selbst. Googlebot crawlt überwiegend aus US-amerikanischen IP-Bereichen, weshalb ein CDN die reine Crawling-Geschwindigkeit oft kaum verändert, wenn der Origin-Server bereits für US-Anfragen schnell antwortet. Der Effekt eines CDN auf das Ranking läuft also größtenteils über die tatsächlichen Besucher, nicht über den Bot – und genau deshalb wiegen die folgenden vier Fehlerquellen so schwer: Sie betreffen direkt das Crawling und die Indexierung, nicht nur die gemessene Geschwindigkeit.

Bot-Schutz blockiert den Googlebot

Fast jedes moderne CDN bringt einen Bot-Schutz oder eine Web Application Firewall mit, oft standardmäßig aktiviert. Diese Systeme bewerten jede Anfrage anhand eines Bot-Scores, stellen JavaScript-Challenges oder verlangen ein Captcha, sobald der Score verdächtig niedrig ausfällt. Googlebot kann keine JavaScript-Challenge lösen und kein Captcha ausfüllen – er bricht die Anfrage ab oder erhält eine Interstitial-Seite statt des eigentlichen Inhalts, die dann im schlimmsten Fall selbst indexiert wird.

Ein zweiter, subtilerer Fall betrifft Rate-Limiting. Wenn ein CDN Anfragen pro IP-Adresse und Sekunde begrenzt, um automatisierte Angriffe abzuwehren, gerät ausgerechnet ein produktiver Crawl-Vorgang ins Visier: Nach der Veröffentlichung vieler neuer Seiten oder einem großen Update ruft Googlebot in kurzer Zeit deutlich mehr URLs ab als sonst. Trifft diese Anfragewelle auf ein zu eng gesetztes Limit, antwortet das CDN mit Statuscode 429, und Googlebot reduziert daraufhin selbstständig seine Crawl-Rate für die Domain – unter Umständen für einige Zeit, nicht nur für den Moment der Drosselung.

Die Freischaltung darf sich nicht allein auf den User-Agent-String verlassen, denn dieser lässt sich beliebig fälschen. Seriöse CDN-Systeme prüfen echte Googlebot-Anfragen zusätzlich über eine Reverse-DNS-Auflösung der anfragenden IP-Adresse gegen die von Google veröffentlichten IP-Bereiche. Eine Regel, die nur prüft, ob der User-Agent den Text Googlebot enthält, schützt vor gar nichts und öffnet gleichzeitig eine Lücke für jeden, der sich als Googlebot ausgibt, um den Bot-Schutz zu umgehen.

• Crawling-Statistiken in der Search Console auf plötzliche Spitzen bei 429- oder 5xx-Antworten prüfen
• Server-Logs nach Anfragen mit dem User-Agent Googlebot filtern und deren tatsächlichen Statuscode auswerten
• Bot-Management-Regeln so setzen, dass verifizierte Crawler per IP-Bereich und Reverse-DNS erkannt werden, nicht nur per User-Agent

Gecachte Weiterleitungen und Fehlercodes

CDNs cachen aus Performance-Gründen möglichst viel am Edge – und ohne explizite Ausnahme gehören dazu auch Weiterleitungen und Fehlerseiten. Das wird zum Problem, sobald sich eine Weiterleitung ändert: Wird aus einem temporären 302 nachträglich ein permanenter 301, oder wird eine Weiterleitung nach einer Migration ganz entfernt, liefern einzelne Edge-Knoten je nach Region und Cache-TTL noch tagelang die alte Antwort aus. Googlebot, der zufällig von einem noch nicht aktualisierten Knoten bedient wird, sieht dann weiterhin die veraltete Weiterleitungskette und aktualisiert den Index entsprechend spät oder gar nicht.

Noch teurer wird es bei gecachten Fehlerantworten. Liefert der Origin-Server während eines Deployments kurzzeitig einen 500er oder 502er aus, und eine Regel, die grundsätzlich alles cacht, speichert diese Antwort mit ihrer Standard-TTL, bekommen alle nachfolgenden Besucher und jeder erneute Crawl-Versuch für die Dauer der TTL denselben Fehler – unabhängig davon, dass der Origin-Server längst wieder normal antwortet. Bei manchen Konfigurationen betrifft das sogar Challenge- oder Blockseiten des Bot-Schutzes selbst: Wird eine solche Seite versehentlich mit Statuscode 200 ausgeliefert und dann gecacht, hält das CDN sie aktiv, lange nachdem die eigentliche Blockierung vorbei ist.

Die Regel dagegen ist einfach zu formulieren, aber leicht zu vergessen umzusetzen: Antworten mit Statuscode 3xx, 4xx und 5xx gehören grundsätzlich nicht in den Edge-Cache, oder nur mit einer sehr kurzen TTL von wenigen Sekunden. Jede Änderung an Weiterleitungsregeln sollte außerdem mit einer aktiven Cache-Leerung am Edge einhergehen, statt darauf zu vertrauen, dass die TTL von selbst abläuft.

Bild-Hostnamen und separate CDN-Domains

Viele Setups liefern Bilder – teils auch CSS und JavaScript – über eine eigene Subdomain oder eine komplett andere Domain des CDN-Anbieters aus, meist um Cookies zu vermeiden und die Bandbreite zu trennen. Google indexiert Bilder aber über ihre tatsächliche URL, nicht über die Seite, auf der sie eingebettet sind. Wechselt der CDN-Hostname – etwa bei einem Anbieterwechsel von einer alten Subdomain zu einer neuen Standarddomain des neuen Anbieters – ohne dass die alten Bild-URLs per 301 auf die neuen weitergeleitet werden, laufen sämtliche zuvor in der Google-Bildersuche indexierten URLs ins Leere. Der Traffic aus der Bildersuche verschwindet, und es dauert oft Wochen, bis jemand den Zusammenhang mit dem CDN-Wechsel herstellt.

Eine zweite Falle betrifft Regeln, die für die Hauptdomain gelten, aber nicht automatisch für die Bild-Domain. Ein Disallow in der robots.txt der Hauptdomain oder ein Noindex-Meta-Tag auf HTML-Seiten hat keinerlei Wirkung auf Bild-URLs, die von einer eigenen CDN-Domain ausgeliefert werden – diese Domain braucht, falls gewünscht, eine eigene robots.txt oder eigene Auslieferungsregeln. Ebenso muss ein Eintrag im Bild-Sitemap den tatsächlichen CDN-Hostnamen referenzieren, unter dem das Bild ausgeliefert wird, nicht die kanonische URL der einbettenden Seite – sonst verweist die Sitemap auf eine URL, die es so gar nicht gibt.

Geo-basierte Antworten und Ländersperren

CDNs werden häufig genutzt, um Besucher je nach Standort automatisch auf eine passende Sprach- oder Länderversion umzuleiten, oder um ganze Länder aus Compliance- oder Kostengründen komplett zu sperren. Beide Mechanismen greifen in die eigentliche URL-Struktur ein, und genau das ist der Punkt, an dem sie SEO-relevant werden. Ein Geo-Redirect, der jeden Besucher aus einem bestimmten Land automatisch auf eine lokale Sprachversion schickt, tut dasselbe mit Googlebot – und Googlebots Anfragen kommen technisch von einer bestimmten IP-Herkunft, die sich unter Umständen wie eine ganz normale Länder-IP verhält.

Das Ergebnis: Google kann eine bestimmte Sprachversion nie direkt unter ihrer eigenen URL abrufen, weil jede Anfrage dorthin auf eine andere URL umgeleitet wird. Für die gegenseitige Validierung von hreflang-Angaben ist das fatal, denn diese setzt voraus, dass jede Sprachversion einzeln unter ihrer eigenen URL mit Statuscode 200 abrufbar ist, nicht nur über eine Weiterleitung erreichbar. Eine Ländersperre auf Firewall-Ebene kann denselben Effekt in einer noch gröberen Form haben: Wird ein ganzer IP-Bereich blockiert, weil er in einer Geo-IP-Datenbank einem gesperrten Land zugeordnet ist, und liegt zufällig ein Teil der von Google für das Crawling genutzten Infrastruktur in diesem Bereich, wird Googlebot ausgesperrt, ohne dass irgendjemand das beabsichtigt hätte.

Der zuverlässige Test dafür ist einfach: Dieselbe URL einmal ganz normal und einmal mit dem Googlebot-User-Agent von einer US-IP-Adresse abrufen und die Antworten vergleichen. Unterscheidet sich nur der ausgelieferte Inhalt, etwa Sprache oder Währung, ist das unproblematisch und sogar erwünscht. Ändert sich dagegen der Statuscode oder die Ziel-URL, liegt ein struktureller Fehler vor, der behoben werden muss, bevor er sich weiter auf die Indexierung auswirkt. Ein verwandtes, aber eigenständiges Problem entsteht am Cache selbst, unabhängig von expliziten Geo-Regeln: Cacht ein CDN geo-personalisierte Antworten unter demselben Cache-Key für alle Länder, weil der Vary-Header auf die Herkunft nicht korrekt gesetzt ist, kann ein Nutzer aus Land A zufällig den für Land B generierten und zwischengespeicherten Inhalt ausgeliefert bekommen. Trifft das denselben Cache-Eintrag, den auch Googlebot beim Crawlen erhalten hat, landet im Index dauerhaft die falsche Länderversion – ein Fehler, der rein am Caching liegt und nichts mit einer expliziten Weiterleitungsregel zu tun hat.

CDN SEO-sicher konfigurieren: die Checkliste

Die folgenden Punkte lassen sich unabhängig vom jeweiligen CDN-Anbieter prüfen und decken die vier beschriebenen Fehlerquellen ab.

• Googlebot im Bot-Management per IP-Bereich und Reverse-DNS verifizieren, nicht allein über den User-Agent-String
• Rate-Limiting-Schwellenwerte so großzügig setzen, dass Crawl-Bursts nach großen Content-Updates nicht als Angriff gewertet werden
• Statuscodes 3xx, 4xx und 5xx grundsätzlich von langen Cache-TTLs ausnehmen
• Bei jeder Änderung an Weiterleitungen oder robots.txt den Edge-Cache aktiv leeren statt auf den TTL-Ablauf zu warten
• Bild-Hostnamen dauerhaft stabil halten oder bei einem Anbieterwechsel per 301 auf die neue Domain weiterleiten
• Geo-Regeln ausschließlich auf Sprache, Währung oder Inhalt wirken lassen, niemals auf Statuscode oder Ziel-URL für Crawler
• Server-Logs regelmäßig nach echten Googlebot-Anfragen mit einem Statuscode ungleich 200 durchsuchen
• Vary-Header korrekt setzen, wenn Inhalte am Edge nach Land oder Sprache variieren, damit keine falsche Version gecacht wird

Wann sich ein CDN lohnt und wann nicht

Ein CDN lohnt sich in der Regel, wenn das Publikum tatsächlich über mehrere Kontinente verteilt ist, wenn große Mediendateien wie Bilder oder Videos einen relevanten Anteil der Seite ausmachen, oder wenn spürbare Lastspitzen, etwa durch Kampagnen oder Presseerwähnungen, regelmäßig vorkommen. In diesen Fällen wiegt der Geschwindigkeits- und Stabilitätsgewinn die zusätzliche Komplexität auf.

Für eine kleine, regional ausgerichtete Seite mit einem Origin-Server, der ohnehin nahe an der Zielgruppe liegt, kehrt sich die Rechnung dagegen oft um: Das CDN bringt kaum messbaren Geschwindigkeitsgewinn, fügt aber eine zusätzliche Stelle hinzu, an der Caching-Regeln, Bot-Schutz oder Header-Weitergabe falsch konfiguriert sein können – und genau diese Fehlkonfiguration ist es, die in der Praxis öfter Rankings kostet als das CDN an Ladezeit einspart.

Ein praktikabler Mittelweg, den viele Setups übersehen: Das CDN nur für wirklich statische Assets wie Bilder, CSS und JavaScript vorschalten und die eigentlichen HTML-Antworten, inklusive aller Weiterleitungen und Statuscodes, direkt vom Origin-Server ausliefern lassen. Damit bleibt die Angriffsfläche für die in diesem Artikel beschriebenen Probleme genau dort, wo sie leicht zu kontrollieren ist, während die Assets trotzdem von einem globalen Edge-Netzwerk profitieren. Vor jeder Einführung lohnt sich eine einzige, ehrliche Frage: Löst das CDN ein Problem, das tatsächlich vorliegt, etwa Ladezeit für entfernte Nutzer, wiederkehrende Lastspitzen oder Angriffsschutz, oder wird es eingeführt, weil es als Best Practice gilt, ohne dass jemand geprüft hat, ob der Origin-Server das Problem nicht längst selbst lösen könnte?

Ein Praxisbeispiel: der stille Traffic-Rückgang nach dem CDN-Wechsel

Ein häufiges Muster: Ein Online-Shop wechselt aus Kostengründen den CDN-Anbieter. Die Migration verläuft technisch reibungslos, die Seite lädt sogar messbar schneller, und niemand bemerkt zunächst ein Problem. Sechs Wochen später fällt auf, dass der organische Traffic auf Produktseiten seit dem Wechseldatum stetig sinkt, während die Rankings für die wichtigsten Keywords selbst noch stabil aussehen.

Die Ursache liegt in diesem Fall nicht in einem einzelnen großen Fehler, sondern in der Kombination von zweien: Der neue Anbieter liefert Produktbilder über eine andere Standard-Domain aus als der alte, und niemand hat die alten Bild-URLs weitergeleitet – der Rückgang in der Google-Bildersuche macht dabei anfangs einen kleineren Eindruck als der Rückgang bei den HTML-Seiten selbst. Gleichzeitig hat der neue Anbieter ein aggressiveres Standard-Rate-Limit, das nach jedem Bulk-Import neuer Produkte kurzzeitig einen Teil der Googlebot-Anfragen mit Statuscode 429 beantwortet, was die Neuindexierung frischer Produktseiten spürbar verzögert. Keiner der beiden Effekte für sich wäre auffällig gewesen; zusammen erklären sie den schleichenden Rückgang vollständig, sobald man Search-Console-Daten und Server-Logs nebeneinanderlegt, statt nur die Rankings selbst zu beobachten.

Diese Art von Fehler zeigt sich fast nie sofort und fast nie in den Rankings selbst zuerst – sie zeigt sich zuerst im Crawling-Verhalten und in den Impressionen, oft Wochen bevor jemand auf die Idee kommt, den CDN-Wechsel als Ursache zu prüfen. Wer nach einer CDN-Migration die Crawling-Statistiken und die Statuscode-Verteilung in den Server-Logs für vier bis sechs Wochen aktiv beobachtet, findet solche Effekte, bevor sie sich in echten Rankingverlusten niederschlagen.