Sprachen

CDN und SEO

Wie ein CDN SEO beeinflusst — schnelleres TTFB, bessere Core Web Vitals, Edge-Caching und geografisch verteilte Auslieferung — und worauf Sie achten müssen.

Erstveröffentlicht: 2. Juli 2026 · Zuletzt aktualisiert: 9. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2
1 Evidenzsignal auf dieser Seite

Ein CDN (Content Delivery Network) cached und liefert Inhalte von Edge-Servern nahe bei Besuchern und Crawlern aus. Es ist selbst kein Rankingfaktor, bewegt aber die Hebel, die Google und Bing tatsächlich nutzen: schnelleres TTFB und Core Web Vitals, bessere Verfügbarkeit, HTTPS-Auslieferung und Crawl-Effizienz. Die Risiken liegen in Fehlkonfigurationen: Ein kalter Cache lässt den Origin jede neue URL mindestens einmal bedienen; WAF- oder Bot-Verifizierungs-Interstitials können Googlebot und Bingbot unbemerkt blockieren; Canonical-Tags, HTTPS-Einstellungen und Cache-Header müssen die Edge-Schicht überstehen.

TL;DR — Ein CDN cached Inhalte und liefert sie von Edge-Servern nahe bei den Anfragenden aus. Das senkt TTFB und verbessert die Core Web Vitals, erhöht die Verfügbarkeit und den Schutz vor Traffic-Fluten und lässt Google schneller crawlen (Google erhöht die Crawl-Rate-Schwellen für CDN-gestützte Websites, abgeleitet von der ausliefernden IP). Es ist selbst kein Rankingfaktor. Die Fallstricke sind alle operativ: Ein kalter Cache zwingt den Origin weiterhin, jede neue URL mindestens einmal auszuliefern (ein Crawl-Budget-Kostenfaktor bei großen Launches); ein WAF oder Bot-Verifizierungs-Interstitial eines CDNs kann Crawler unbemerkt blockieren – der größte reale CDN/SEO-Fehlermodus; Canonical-Tags und die HTTPS-Konfiguration müssen den Edge überstehen; und Google nahm seine Empfehlung im Dezember 2024 innerhalb von weniger als einer Woche zurück, was das Sharding kritischer JS-/CSS-Ressourcen auf eine CDN-Subdomain betrifft (für kritische Ressourcen inzwischen nicht empfohlen, für große nicht kritische Assets wie Video weiterhin möglich). Die maßgebliche Quelle ist Googles Beitrag “Crawling December: CDNs and crawling” (Übersetzung) „Crawling im Dezember: CDNs und Crawling“.

Evidence for this claim A CDN can cache and serve content closer to users, affecting delivery performance rather than adding a direct search ranking signal. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: CDN Evidence for this claim Googlebot must receive accessible content and valid status codes regardless of whether a CDN sits in front of the origin. Scope: Current official or standards documentation. Confidence: high · Verified: Google: HTTP and network errors

Was ein CDN tatsächlich tut

Ein CDN ist ein Vermittler zwischen Ihrem Origin-Server und allen, die Ihre URLs anfordern – Besuchende und Crawler gleichermaßen. Googles eigener Beitrag „Crawling December“ vom Dezember 2024 formuliert es klar: CDNs sind ein Vermittler zwischen Ihrem Origin-Server und den Endnutzenden — “CDNs are basically an intermediary between your origin server” (Übersetzung) „CDNs sind im Grunde ein Vermittler zwischen Ihrem Origin-Server und den Anfragenden“; das CDN liefert einige Dateien in Ihrem Auftrag aus. Sein historisch größter Schwerpunkt ist Caching: Sobald eine URL angefordert wird, speichert das CDN ihren Inhalt eine Zeit lang, sodass Ihr Server diese Datei nicht erneut ausliefern muss. Google beschreibt den Zweck als Senkung der Latenz Ihrer Website — “Content delivery networks (CDNs) are particularly well suited for decreasing latency of your website” (Übersetzung) „Content-Delivery-Netzwerke eignen sich besonders, um die Latenz Ihrer Website zu senken“: Ihre Inhalte werden auch unter hoher Last schnell ausgeliefert.

Dieser einzelne Beitrag – verfasst von Martin Splitt und Gary Illyes – ist das maßgeblichste und aktuellste, was eine der beiden Suchmaschinen zu CDNs und SEO veröffentlicht hat, und die meisten Konkurrenzartikel verwenden ihn nicht. Fast alles Folgende baut darauf auf.

Es lohnt sich, genau zu sein, was ein CDN ist, denn der Begriff wird großzügig verwendet: Ein CDN ist ausdrücklich die verteilte Edge-Server-Topologie – das Netz aus Caching-/Auslieferungsknoten zwischen Ihrem Origin und den Anfragenden. Es ist weder gleichbedeutend mit allgemeinem Webhosting noch mit HTTP-Caching selbst (jeder Server oder Proxy kann eine Antwort cachen). Der Schutz durch eine Web Application Firewall und die TLS-Terminierung gehören ebenfalls nicht zur Kernfunktion eines CDNs: Die meisten CDN-Anbieter bündeln sie, weshalb die Begriffe verschwimmen, aber es sind separate Fähigkeiten, die über der Edge-Auslieferung liegen.

Hilft ein CDN bei SEO? Die ehrliche Antwort

Ein CDN ist kein Rankingfaktor. Es ist ein Hebel für Performance und Zuverlässigkeit, der mehrere Aspekte beeinflusst, die Google tatsächlich gewichtet. Drei davon sind wichtig:

Schnelleres TTFB und bessere Core Web Vitals

Die Auslieferung aus einem nahe gelegenen Edge-Cache verkürzt die Round-Trip-Zeit und senkt damit die Zeit bis zum ersten Byte – TTFB bildet den Vorlauf für LCP, die größte der Core Web Vitals. Google formuliert es als “Caching on the CDN, correlates with better conversions” (Übersetzung) „Caching auf dem CDN steht mit besseren Conversions in Zusammenhang“ und erklärt, dass das Auslagern von Medien, JavaScript, CSS und sogar HTML in die Caches eines CDNs die Serverlast reduziert und bedeutet, dass Seiten in den Browsern der Nutzenden schneller laden und dies mit besseren Conversions korreliert. Das ist das klarste und am besten belegbare SEO-Argument für ein CDN. Es überschneidet sich mit den verwandten Themen Caching, Resource Hints und Web-Performance-Tools in diesem Cluster – ein CDN ist einer der stärksten Hebel, die Sie betätigen können, um schlechte CWV- oder PageSpeed-Werte zu verbessern.

Dieser Vorteil ist allerdings an Bedingungen geknüpft. Ein Cache-Hit nahe bei den Anfragenden verkürzt die Round-Trip-Zeit; ein Cache-Miss, eine nicht gecachte personalisierte Antwort oder ein ungünstig platzierter Edge-Knoten kann TTFB unverändert lassen oder sogar zusätzlichen Aufwand verursachen. Ein CDN garantiert keinen niedrigeren TTFB in jeder Region und bei jeder Anfrage – es garantiert ihn nur, wenn der Edge die Antwort tatsächlich ausliefern kann.

Höhere Crawling-Raten-Schwellen für CDN-gestützte Websites

Das ist der unterschätzte Vorteil. Google leitet die verfügbare Serverkapazität aus der IP ab, die Ihre URLs ausliefert, und gestaltet seine Crawling-Infrastruktur ausdrücklich so, dass sie “Our crawling infrastructure is designed to allow higher crawl rates on sites that are backed by a CDN” (Übersetzung) „Googles Crawling-Infrastruktur ist darauf ausgelegt, höhere Crawl-Raten auf Websites zuzulassen, die von einem CDN unterstützt werden“ höhere Crawl-Raten auf CDN-gestützten Websites ermöglicht. Die Drosselungsschwelle ist “The threshold for this throttling is much higher when our crawling infrastructure detects that your site is backed by a CDN” (Übersetzung) „Die Schwelle für diese Drosselung liegt deutlich höher, wenn unsere Crawling-Infrastruktur erkennt, dass Ihre Website von einem CDN unterstützt wird“ deutlich höher, weil Google annimmt, dass der Server mehr gleichzeitige Anfragen verarbeiten kann. Für eine große oder häufig aktualisierte Website ist das ein echter, dokumentierter Vorteil: Mehr Ihrer Seiten können schneller gecrawlt werden. Seien Sie präzise bei dem, was hier tatsächlich garantiert ist: Es handelt sich um eine abgeleitete Kapazitätsschwelle, nicht um einen zugesicherten Gewinn bei Crawl-Budget, Indexierung oder Ranking. Google entscheidet weiterhin anhand seiner eigenen Crawl-Demand-Signale für Ihre Website, wie viel von dieser höheren Obergrenze es nutzt. (Und selbst bei vollständiger Nutzung ist das ein Effizienzgewinn beim Crawl-Budget, kein Rankingsignal – mehr Crawling bedeutet kein besseres Ranking.)

Zuverlässigkeit, Uptime und Schutz vor Überlastung

Google nennt zwei weitere Vorteile. Schutz vor Traffic-Fluten: CDNs können “identifying and blocking excessive or malicious traffic” (Übersetzung) „übermäßigen oder bösartigen Traffic erkennen und blockieren“ und so übermäßigen oder bösartigen Traffic erkennen und blockieren, Ihre Website auch dann nutzbar halten, wenn fehlgeleitete Bots sie überlasten würden. Und Zuverlässigkeit: “Reliability: Some CDNs can serve your site to users even if your site is down” (Übersetzung) „Zuverlässigkeit: Einige CDNs können Ihre Website für Nutzende ausliefern, selbst wenn Ihre Website ausgefallen ist“ – zumindest statische Inhalte, was genügen kann, damit Besuchende nicht abspringen statische Inhalte trotz Ausfalls auszuliefern. Das Ausmaß ist real: CDNs haben DDoS-Fluten mit mehreren Terabit pro Sekunde eigenständig erkannt und abgewehrt, die einen ungeschützten Origin-Server innerhalb von Sekunden offline nehmen würden. Verfügbarkeit ist stillschweigend auch ein SEO-Thema – anhaltende Ausfälle, die Googlebot Fehler liefern, kosten Sie mit der Zeit Einträge im Index.

Der Crawling-Budget-Haken: leere Caches bei neuen URLs

Hier liegt die Nuance, die fast jeder Konkurrenzartikel übersieht. Ein CDN entbindet Ihren Origin nicht davon, neue URLs auszuliefern. Bei der ersten Anfrage für eine URL ist der Cache des CDNs kalt – noch niemand hat sie angefordert, daher ist sie nicht gecacht – und Ihr Origin muss sie weiterhin mindestens einmal ausliefern, um den Cache aufzuwärmen. Googles Beispiel ist ein Webshop, der mehr als eine Million URLs startet: Selbst hinter einem CDN gilt “In short, even if your webshop is backed by a CDN, your server will need to serve those 1,000,007 URLs at least once” (Übersetzung) „Kurz gesagt: Selbst wenn Ihr Webshop von einem CDN unterstützt wird, muss Ihr Server diese 1.000.007 URLs mindestens einmal ausliefern“ diese 1,000,007 URLs mindestens einmal auszuliefern, bevor das CDN helfen kann. Das belastet das Crawl-Budget tatsächlich, und Google warnt, dass die Crawl-Rate wahrscheinlich einige Tage lang ansteigen wird.

Practical takeaway: if Sie’re launching a lot of URLs at once — a new Website section, a migration, a huge product catalog — plan für Ihre Origin to absorb Das initial Crawling. Die CDN protects Sie nach warm-up, nicht during it. Diese ist Die gleich “where Die load actually falls” thinking Das comes up in Website migrations.

Sollten statische Assets auf einer CDN-Subdomain liegen?

Eine wiederkehrende Architekturfrage lautet: Hosten Sie CSS, JS und Bilder auf einem separaten Hostnamen wie cdn.example.com, oder stellen Sie Ihren Haupt-Hostnamen hinter ein CDN? Google sagt, beides funktioniert – seine Crawling-Infrastruktur “supports either option without issues” (Übersetzung) „unterstützt beide Optionen ohne Probleme“ ohne Probleme. Das Aufteilen von Ressourcen auf einen eigenen Hostnamen kann den Web Rendering Service effizienter rendern lassen. Google nennt aber selbst den Vorbehalt: Es “may negatively affect page performance due to the overhead of a connection to a different hostname” (Übersetzung) „kann die Seiten-Performance durch den zusätzlichen Aufwand einer Verbindung zu einem anderen Hostnamen verschlechtern“ die Seiten-Performance beeinträchtigen.

Und hier änderte Google seine öffentliche Empfehlung in weniger als einer Woche. Der Begleitbeitrag vom 3. Dezember 2024 schlug zunächst vor, Ressourcen auf einem anderen Hostnamen zu hosten, um Crawl-Budget-Bedenken auf den Ressourcen-Host zu verlagern. Drei Tage später folgte eine Korrektur: Weil dies “can result in slower page performance due to the overhead of connection to a different hostname” (Übersetzung) „zu einer langsameren Seiten-Performance durch den zusätzlichen Aufwand der Verbindung zu einem anderen Hostnamen führen kann“ die Seiten-Performance verlangsamen kann, empfiehlt Google “recommend this strategy for critical resources” (Übersetzung) „diese Strategie für kritische Ressourcen empfehlen“ nicht mehr für kritische Rendering-Ressourcen wie JavaScript oder CSS – für große nicht kritische Assets wie Videos oder Downloads kann es aber weiterhin sinnvoll sein. Wenn Sie Ihren Haupt-Host bereits mit einem CDN betreiben, umgehen Sie den gesamten Zielkonflikt: ein Hostname für die Abfrage, kritische Ressourcen aus dem Cache des CDNs. Beachten Sie außerdem, dass der WRS JS/CSS unabhängig von Ihren HTTP-Cache-Headern bis zu 30 Tage cached, sodass Ressourcenänderungen verzögert sichtbar werden können.

Wenn CDNs SEO schaden: Bot-Blocking (das größte reale Risiko)

Das größte reale CDN/SEO-Problem ist nicht Duplicate Content, sondern dass das CDN Crawler unbemerkt aussperrt. Google sagt es direkt: Aufgrund des Schutzes vor Traffic-Fluten können “occasionally the bots that you do want on your site may end up in your CDN’s blocklist” (Übersetzung) „gelegentlich die Bots, die Sie auf Ihrer Website haben möchten, in der Blockliste Ihres CDNs landen“ in der Blockliste Ihres CDNs landen, typischerweise in der Web Application Firewall (WAF). Das kann verhindern, dass Ihre Website überhaupt in der Suche erscheint. Google unterteilt die Fehlerarten in harte und weiche Blockierungen.

Harte Blocks — und der zurückgegebene Statuscode ist entscheidend

  • HTTP 503 / 429 – die richtige Art, eine temporäre Blockierung zu signalisieren. Sie verschafft Ihnen Zeit zu reagieren, bevor etwas aus dem Index entfernt wird. Bevorzugen Sie diese Variante.
  • Netzwerk-Timeouts – schlecht. Google behandelt sie als terminale, “harte” Fehler. Das genaue Ergebnis – Entfernung aus dem Index, eine Senkung Ihrer Crawl-Rate oder beides – hängt laut Googles aktueller Dokumentation zu HTTP-Statuscodes sowie Netzwerk- und DNS-Fehlern von der Status-/Netzwerkfehlerklasse, der Dauer und dem Wiederauftreten ab. Ein einmaliger isolierter Timeout ist deutlich weniger riskant als ein anhaltendes Muster solcher Fehler.
  • Eine zufällige Fehlermeldung mit Status 200 (“weicher Fehler”) – der schlimmste Fall. Liest Google sie als harten Fehler, entfernt es die URL; wenn nicht, können alle Seiten mit demselben Fehler-Body als Duplikate entfernt werden.

Deutsche Fassung: Das Ranking of outcomes ist Die single most actionable thing in Diese whole topic: a clean 503 ist better than a “technically up” 200 error Seite.

Weiche Blocks — Bot-Verifizierungs-Interstitials

Wenn ein CDN eine „Sind Sie ein Mensch?“-Prüfung ausgibt, sieht der Crawler nur dieses Interstitial – nicht Ihre Seite. Googles Lösung ist eindeutig: Für solche Bot-Verifizierungs-Interstitials empfiehlt Google ausdrücklich, “we strongly recommend sending a clear signal in the form of a 503 HTTP status code” (Übersetzung) „wir empfehlen dringend, in Form eines 503-HTTP-Statuscodes ein klares Signal zu senden“ ein klares Signal in Form eines 503-HTTP-Statuscodes zu senden, damit der Inhalt nicht automatisch aus dem Index entfernt wird.

So debuggen Sie das

Googles Ablauf für harte und weiche Blockierungen: Verwenden Sie das URL Inspection Tool in der Search Console und sehen Sie sich den gerenderten Screenshot an – Ihre Seite bedeutet, dass alles passt; eine leere Seite, ein Fehler oder eine Bot-Prüfung bedeutet, dass Sie mit Ihrem CDN sprechen müssen. Prüfen Sie anschließend den Crawler anhand der veröffentlichten IP-Bereiche und entfernen Sie gegebenenfalls blockierte IPs aus Ihren WAF-Regeln oder setzen Sie diese auf eine Allowlist. Entscheidend ist Googles Warnung: “Remember that the IPs may end up on a blocklist automatically, without you knowing” (Übersetzung) „IP-Adressen können automatisch und ohne Ihr Wissen auf einer Blockliste landen“ automatisch auf einer Blockliste landen können, daher lohnt es sich, die WAF-Blocklisten regelmäßig zu prüfen. Google veröffentlicht Googles IP-Bereiche genau dafür; Bing veröffentlicht das Äquivalent (siehe den Bing-Abschnitt weiter unten).

Das ist übrigens eine Stelle, an der ich Dinge im gesamten Stack habe brechen sehen. In meinem SMX-Advanced-2018-Vortrag „Solving Complex SEO Problems” zeichne ich nach, auf wie vielen Ebenen Logik liegen kann – DNS, CDN, Middleware, Server, HTTP-Header, Locale – und der CDN-Edge ist eine davon. Wenn eine Weiterleitung oder Blockierung sich im Browser anders verhält als für Googlebot, verbirgt sich die Überraschung oft am Edge.

Cache-Header und Canonicalisierung über ein CDN

Doppelter Inhalt durch ein CDN ist ein beherrschbares Risiko, keine Strafe. So geht es tatsächlich schief:

  • Das CDN liefert Inhalte von seiner eigenen Domain aus, ohne den Canonical-Tag oder -Header Ihres Origins zu übernehmen – dadurch konkurriert die Edge-URL mit der echten URL.
  • Knoten in mehreren Regionen liefern geografisch unterschiedliche Inhalte aus, ohne korrektes hreflang, sodass eine Seite auf regionale Varianten aufgeteilt wird.
  • Die Verarbeitung von Query-Strings oder Cache-Keys erzeugt Duplikate auf Basis von Parametern.

Die Lösung ist dieselbe Disziplin, die in den Artikeln zu Canonicalisierung und Duplicate Content beschrieben wird: Stellen Sie sicher, dass Ihre Canonical-Tags und -Header den Edge unverändert passieren, und prüfen Sie diese nach einem CDN-Deployment, nicht davor. Denken Sie daran, dass Canonicalisierung eine Zusammenführung von Signalen ist – ein CDN, das Ihren Canonical entfernt oder überschreibt, ist nur ein weiteres Signal in die falsche Richtung.

Ein Mythos, den wir an dieser Stelle ausräumen sollten: Der Vary-Header betrifft die Korrektheit des Cachings, nicht ein SEO-Signal. Vary: User-Agent kann die Cache-Hit-Rate eines CDNs ruinieren, wenn das CDN sich weigert, variierte Antworten zu cachen. Google verwendet Vary jedoch nicht als Signal für die Indexierung von Mobil- oder Desktop-Versionen. Das ist ein Betriebsproblem, kein Rankingproblem.

HTTPS/TLS über ein CDN

Ein CDN fügt Ihrer Verschlüsselung einen zweiten Abschnitt hinzu: Origin↔Edge und Edge↔Client. Beide müssen HTTPS verwenden. Eine klassische Fehlkonfiguration ist der Modus „Flexible SSL“, bei dem Besuchende HTTPS sehen, das CDN aber über reines HTTP mit Ihrem Origin spricht – und HTTP-only-Asset-URLs in einer CDN- Konfiguration Warnungen zu gemischten Inhalten erzeugen. Stellen Sie außerdem sicher, dass Sicherheits-Header wie HSTS und CSP den Edge ebenfalls passieren. HTTPS ist für sich genommen ein leichtgewichtiges Rankingsignal, und ein CDN ist eine der einfachsten Stellen, an denen man es versehentlich rückgängig macht. Wenn Sie ein CDN einrichten oder wechseln, ohne Ihre URLs zu ändern, behandeln Sie es wie einen Hosting-Wechsel – Googles Leitfaden zum Ändern Ihres Webhostings deckt den Fall eines Website-Umzugs „ohne URL-Änderung“ ab.

Geteilte IPs und was nicht zählt

  • Eine gemeinsam genutzte CDN-IP-Adresse ist für Rankings unproblematisch. Googles John Mueller hat erklärt, dass Website-Betreiber nicht künstlich IP-Adressblöcke kaufen müssen. Dass Sie auf einer CDN-IP landen, die mit anderen Unternehmen geteilt wird, ist erwartbar und unbedenklich.
  • Die Wahl zwischen cdn.example.com und der Domain eines Drittanbieter-CDNs ist eine technische bzw. Performance-Entscheidung, keine SEO-Entscheidung, solange die Inhalte crawlbar sind – was sich direkt daraus ergibt, dass Google beide Hostnamen-Konfigurationen unterstützt.

Die Bing-Seite

Bing hat keinen einzelnen Erklärbeitrag zu „CDN und SEO“, der so detailliert wäre wie Googles Beitrag, aber dieselben Probleme und Lösungen gelten. Das direkte Gegenstück zu Googles WAF-Hinweisen: Bing veröffentlicht offizielle Bingbot-IP- Bereiche und ein Verifizierungstool, damit Website-Betreiber hinter einem CDN oder einer Bot-Management-Schicht vor einer Allow- oder Denylist-Prüfung bestätigen können, dass ein Crawler tatsächlich Bingbot ist – siehe Bingbot überprüfen und das Bingbot-Prüftool. Microsoft hat außerdem seine Bingbot-IP-Adressliste als JSON-Datei veröffentlicht, auf dieselbe Weise wie Google. Bings allgemeine Hinweise nennen Website- Geschwindigkeit als Optimierungsaspekt und führen die Nutzung eines CDNs als eine der Maßnahmen zur Verbesserung der Ladezeiten auf. Auch Bings Fabrice Canel hat auf hoher Ebene darüber gesprochen, dass auf CDNs gecachte und in der Cloud gehostete Inhalte neue Herausforderungen für Messung und plattformübergreifende Inhaltsverwaltung schaffen – eine faire Beschreibung der betrieblichen Realität, auch wenn daraus kein Rankingversprechen folgt.

Wo das einzuordnen ist

CDN-Entscheidungen berühren fast alles im Cluster Web-Performance – Caching, Resource Hints, Core Web Vitals und TTFB –, weil ein CDN einer der größten Hebel für all diese Bereiche ist. Sie reichen außerdem in das Crawling (Crawl-Budget, kalte Caches), die Indexierung (Canonicalisierung, Umgang mit Duplikaten), HTTPS und Website-Migrationen hinein. Das wiederkehrende Muster: Ein CDN ist ein unkomplizierter Gewinn für die wichtigen Signale, wenn Sie Ihre Canonical-Tags, HTTPS-Konfiguration und den Crawler-Zugriff durch den Edge hindurch intakt halten – und eine häufige Ursache für „indexiert ohne Inhalt“, wenn Sie das nicht tun.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.