You Don't Need a CDN for SEO

"You need a CDN for SEO," they tell you, and I've heard this from agencies and consultants and conference speakers for years, repeated with such confidence and frequency that Cloudflare's marketing team must be absolutely thrilled, because here's the thing that nobody wants to admit: for most sites, a CDN does almost nothing for your rankings, because the math doesn't work, because the bottlenecks are elsewhere, because you've been sold a solution to a problem you don't have by people who either don't understand the math or have financial incentives not to understand it.

The Speed of Light Problem

Let's do some math, the kind of math that CDN vendors hope you never do yourself: light travels through fiber optic cable at roughly 200 kilometers per millisecond, and New York to London is about 5,500 km, which means round trip latency is around 55ms minimum, usually 70-80ms in practice, and so a CDN edge server in London serves your UK users with roughly 20ms latency instead of roughly 80ms from your New York origin, which means you saved 60 milliseconds, sixty whole milliseconds, a duration so small that you could not perceive it if you tried, and now I want you to open Chrome DevTools on any website and look at the waterfall and find me a site where 60ms is the bottleneck, because I'll wait, and while I'm waiting you'll actually see 800ms parsing JavaScript and 1.2 seconds downloading hero images that should be WebP and 2 seconds waiting for third-party analytics to load and 400ms of layout shifts from lazy-loaded ads, and your CDN's heroic 60ms savings is a rounding error in a 4-second page load, the equivalent of worrying about the temperature of your coffee while your house is on fire.

Core Web Vitals Don't Measure What CDNs Fix

Google's Core Web Vitals are LCP, CLS, and INP, and let's see what CDNs actually do for each of these metrics that Google claims to care about: Largest Contentful Paint measures when your main content renders, which is dominated by render-blocking resources and image optimization and client-side JavaScript, and yes a CDN shaves off network latency, but if your LCP element is a 2MB unoptimized JPEG that triggers after 1.5 seconds of JavaScript execution then saving 60ms on delivery changes absolutely nothing; Cumulative Layout Shift measures visual stability, and CDNs have zero impact on this because CLS is about reserving space for images and ads rather than network speed; and Interaction to Next Paint measures responsiveness to user input, which is about JavaScript execution time on the client, and CDNs don't help because your user's browser is doing the work and the CDN is just sitting there having delivered the bytes that are now causing problems.

None of the metrics Google actually uses for rankings are meaningfully improved by edge caching, but the CDN vendors hope you don't notice this, hope you'll conflate "faster delivery" with "better Core Web Vitals" without examining whether those things are actually related in your specific situation.

The TTFB Red Herring

"But CDNs improve Time to First Byte!" you protest, and yes, they do, they absolutely do, and TTFB barely matters for rankings, because TTFB measures how quickly your server starts sending a response, and Google cares about this for crawl efficiency at scale, meaning if you're running a 50-million-page e-commerce site and Googlebot is waiting 3 seconds per page then you have a crawl budget problem. But if you're running a 500-page B2B site, your server could respond in 200ms or 400ms and Google doesn't care, because they'll crawl your whole site either way, because TTFB is not a ranking factor for normal sites, because the scenarios where TTFB matters are scenarios that don't apply to the vast majority of people being sold CDNs for SEO purposes.

When a CDN Actually Matters

CDNs aren't useless, I should be clear about that, but they're not SEO tools, they're infrastructure tools, and the legitimate use cases have almost nothing to do with rankings: DDoS protection is the real reason to use Cloudflare, because if someone decides to attack your site then a CDN absorbs the traffic, and that's genuinely valuable, but it's not SEO; global media delivery matters if you're Netflix streaming video to 200 countries, but if you're a SaaS company with a marketing site you're not Netflix and you don't need what Netflix needs; genuinely slow origins can be masked by CDNs, so if your origin server is a decade-old WordPress install with 47 plugins running on shared hosting in a single datacenter then a CDN masks the problem, but the real fix is fixing your origin rather than hiding behind edge servers; and massive static asset serving makes sense when you're serving 50GB of downloadable software where edge caching saves you bandwidth costs, but SEO doesn't enter the equation at all.

What Actually Improves Page Speed

If you care about Core Web Vitals (and you probably shouldn't obsess over them, but that's another take), here's what actually moves the needle: smaller JavaScript bundles, because every KB of JS is parsed and compiled and executed on the user's device, and a CDN doesn't make their phone faster no matter how many edge locations it has; optimized images, because serving WebP and responsive sizes and lazy loading below the fold is where seconds live rather than milliseconds; fewer third-party scripts, because every analytics tool and chat widget and A/B testing snippet adds latency, and removing what you don't need provides more benefit than any CDN configuration; server-side rendering, because you should stop making users' browsers do work that your server could do once; and proper caching headers, which you don't need a CDN for because your origin server can set cache-control headers just fine.

The Marketing Machine

Why does everyone believe CDNs are essential for SEO? Follow the money, as they say, because CDN vendors sponsor every SEO conference and publish "research" showing speed correlations with rankings and have trained an entire generation of SEOs to recommend CDNs reflexively, and agency SEOs love CDN recommendations because they sound technical and sophisticated, because "we need to implement edge caching with intelligent origin shielding" sounds so much more impressive than "delete half your JavaScript," and nobody ever got fired for recommending Cloudflare because it's a safe, credible-sounding recommendation that costs money and changes nothing meaningful, which is exactly what a lot of technical recommendations in SEO amount to.

A CDN is a solution looking for a problem. For most sites, the problem isn't network latency. It's everything you're making the browser do after the bytes arrive.

The Bottom Line

If you're already using a CDN, fine, keep it for DDoS protection because it's probably not hurting you, but if someone tells you that you need a CDN for SEO, ask them to show you the specific bottleneck it will fix, ask them to open your site in DevTools and point to the latency problem, and watch them struggle to find something that matters.

Your rankings aren't suffering because your server is in Virginia instead of having edge nodes in 47 countries, because your rankings are suffering because your content isn't good enough and your JavaScript is bloated and you're chasing phantom ranking factors instead of doing the hard work, and no amount of edge caching will fix problems that exist on the other side of the network connection. Stop optimizing for milliseconds and start optimizing for seconds, or better yet, start optimizing for users who actually want what you're offering, which is a different kind of optimization entirely.