CDN (Content Delivery Network)

A CDN (Content Delivery Network) is a mesh of geographically distributed edge servers that serve your content from a location near each visitor instead of hauling every request back to your origin. For SEO, a CDN is leverage on three things at once: latency (TTFB and Core Web Vitals), availability under load (including crawler load), and — increasingly — a programmable layer where SEO fixes can ship without touching the origin codebase.

It can also quietly wreck things. A CDN sits between every crawler and your site, which means a misconfigured one is a site-wide problem wearing a performance costume.

Reading what the edge is doing

You can see a CDN's behavior in its response headers. A request through Cloudflare, for example:

$ curl -sI https://example.com/products/trekking-poles/

HTTP/2 200
cf-cache-status: HIT
age: 1834
server: cloudflare
cf-ray: 8e42a1bc9d0f2a51-CDG

cf-cache-status: HIT means the Paris edge (CDG in the ray ID) answered from its own copy — the origin never saw the request, and the visitor got the page at local latency. MISS means the edge had to fetch from origin; DYNAMIC means the CDN isn't caching this content type at all — the default for HTML on most CDNs, and the single most overlooked line in performance audits. Fastly and Akamai expose equivalents (x-cache: HIT, etc.). What governs those hits and misses — Cache-Control, s-maxage, TTLs — is a topic of its own, covered on the caching page; this page is about what the distributed layer does to search.

CDN layers and their SEO effects

That edge-compute row has grown into its own discipline — redirect maps, hreflang injection, and A/B-testable meta changes running entirely at the CDN. If that's the direction you're heading, start with edge SEO with CDN workers and the broader look at CDN edge caching for SEO.

One hostname, or duplicate-site hell

A CDN must serve your content on your canonical hostname. Two setups create duplicate full-site copies: a legacy "pull zone" domain (cdn.example.com or example.b-cdn.net) that mirrors HTML pages and gets indexed, or a staging origin reachable directly by IP/alt-hostname behind the CDN. Both put your entire site in the index twice. Asset subdomains for images are fine; crawlable HTML mirrors are not — canonical tags plus blocking the mirror hostname is the standard cleanup.

How to check it on your own site

1. Identify the CDN and cache behavior: curl -sI https://yoursite.com/ | grep -iE 'server|cf-cache|x-cache|age|via'. No cache-status header on HTML usually means HTML isn't edge-cached at all.
2. Test from more than one region. Edge behavior differs per PoP. A quick pass with WebPageTest from two or three locations shows whether TTFB actually drops far from your origin — the entire point of the CDN.
3. Verify Googlebot isn't being challenged. GSC → URL Inspection → Live Test on key templates. Then check Crawl Stats for spikes in 403/429 or "server connectivity" errors — the signature of WAF rules catching crawlers.
4. Hunt for mirror hostnames. Search site:cdn.yoursite.com and any provider-issued hostname you've ever used. Anything indexed there is a duplicate to kill.
5. Diff origin vs edge. Fetch the same URL from origin directly (hosts-file override or curl --resolve) and through the CDN. Any difference in titles, canonicals, or redirects means edge logic exists — document it.

Common mistakes

• WAF blocking Googlebot or AI crawlers. Bot protection tightened after a scraping incident, and suddenly Googlebot gets JS challenges it can't pass. Fix: verify legitimate crawlers by IP range (Google publishes theirs) and allowlist them explicitly, not by user-agent string alone.
• HTML never cached, CDN credited anyway. "We're on a CDN" while every page request is DYNAMIC and rides to origin. The CDN is accelerating your logo. Fix: deliberate HTML caching rules with sensible TTLs and purge-on-publish.
• Stale pages pinned at the edge. Prices, titles, or noindex changes shipped weeks ago; the edge copy predates them; Googlebot keeps re-reading the old version. Fix: purge hooks wired into the CMS publish action.
• Redirects cached without care. A temporary 302 cached at the edge outlives its purpose, or a redirect loop gets frozen into the cache. Fix: explicit low/no-cache rules on 3xx responses.
• Edge rewrites nobody wrote down. A worker rewriting canonicals or injecting noindex, deployed by a contractor, invisible in the repo. Fix: edge code lives in version control with the same review bar as origin code.

FAQ

Is a CDN a ranking factor?

No — speed and successful crawling are what matter, and a CDN is one way to buy both. A fast single-origin site loses nothing by lacking one.

Does serving pages from different IPs/locations confuse Google?

No. Google handles anycast and distributed serving fine, and CDN geography does not affect geotargeting — that comes from ccTLD, hreflang, and GSC settings.

Should images live on a CDN subdomain or the main domain?

Either works. Same-domain (proxied through the CDN) is simpler and keeps image URLs stable; a dedicated asset subdomain is fine too — just never let it serve crawlable HTML.

Can Googlebot hit a different cache than my users?

Yes — different PoPs hold different copies, and some setups cache per-device or per-header variants. This is why "it looks fine to me" proves nothing; test with the URL Inspection live test, not your browser.

Do AI crawlers have CDN problems too?

More than Googlebot, in practice — GPTBot, ClaudeBot and similar bots don't execute JS challenges and get filtered by default bot rules constantly. If AI visibility matters to you, audit your bot-management allowlists for them specifically.