A content delivery network (CDN) is a global network of servers that store copies of a website’s files and serve them to visitors from the location nearest to them. Instead of every request traveling to the single server where the site is hosted, images, stylesheets, scripts, fonts, and often the pages themselves are delivered from an edge server a short distance away. The result is faster loading for visitors far from the origin server, less load on that server, and a layer of protection against traffic spikes and attacks.
Most sites that use a CDN today did not set one up deliberately. It came with the host, with Cloudflare’s free tier, or with a performance plugin. That is usually fine, and usually an improvement. It also means that when something on the site behaves strangely, the CDN is one of the first places to look, because it sits between what you publish and what the world sees.
How a CDN works
When a visitor requests a page, DNS points them not at the origin server but at the CDN. The CDN routes the request to the closest edge location, often called a point of presence. If that edge server already has a fresh copy of the requested file, it returns it immediately: a cache hit. If it does not, it fetches the file from the origin server, returns it to the visitor, and keeps a copy for the next person who asks: a cache miss, followed by a hit for everyone after.
How long the edge keeps that copy is controlled by cache headers, principally Cache-Control and its max-age directive, which the origin sends with each file, and by rules configured in the CDN itself. Static assets that never change once published, such as versioned stylesheets and images, can be cached for a year. HTML changes whenever you edit a page, so it is either cached for a short time, cached until explicitly purged, or not cached at the edge at all.
What a CDN actually improves
Latency. The physical distance between visitor and server sets a floor on how fast a response can arrive, and every round trip pays it. A visitor in Seattle requesting files from a server in Virginia waits noticeably longer than one in Richmond. Serving from a nearby edge removes most of that penalty, which matters most for the first bytes of the page and therefore for Core Web Vitals.
Origin load. Every request the edge answers is a request your hosting never sees. For an image-heavy site, a CDN can absorb the large majority of total bytes transferred, which keeps the origin free for the work only it can do: building pages, running queries, processing forms and orders.
Resilience. Traffic spikes from a campaign, a news mention, or a seasonal rush hit the edge first. Most CDNs also absorb distributed denial-of-service attacks, and many include a web application firewall and bot management.
Modern protocol support. A good CDN terminates connections with current TLS, HTTP/2, and HTTP/3, and applies Brotli compression, even when the origin server is older and does not.
Image handling. Many CDNs can resize images on the fly and convert them to WebP or AVIF based on what the visitor’s browser supports, which is often a larger speed win than any of the above.
What a CDN does not fix
A CDN shortens the trip. It does not make the thing at the end of the trip smaller or cheaper to build. A 4 MB uncompressed hero image is still 4 MB when it arrives from an edge server twelve miles away. A page that takes three seconds to assemble in PHP because of an unindexed database query still takes three seconds on every cache miss.
This is the most common misunderstanding we see: a site is slow, a CDN is switched on, the score moves a little, and the underlying problems remain. The order that works is to fix the page first, with properly sized images, sensible lazy loading, caching at the origin, and minification where it helps, then add a CDN so that an already-fast page is also fast everywhere.
A CDN also does little for a site whose audience is entirely local and whose server is already in the region. A Raleigh business serving Triangle-area customers from a data center in Virginia is starting from a short trip. The gains there come from the CDN’s compression, protocol support, image conversion, and attack protection rather than from distance.
The stale cache problem
The trade-off for edge caching is that there are now two answers to the question “what is on this page,” and they can disagree. You publish an update, the origin has the new version, and the edge keeps serving the old one until its cached copy expires or is purged. Visitors, and crawlers, see yesterday’s site.
We hit this on our own site. Our XML sitemap had been corrected in WordPress, and fetching it through the admin showed the corrected version, but the URL Googlebot actually requests was being served from the host’s edge cache, which still held the outdated file. Everything looked fixed from the inside. From the outside, nothing had changed. The lesson generalizes past sitemaps: after any change that matters, verify it at the public URL, requested the way a stranger would request it, not through the CMS.
The practical rules that follow from this:
Purge after publishing. Most WordPress CDN integrations purge automatically when a post is saved. Verify that yours does, and purge manually after theme file changes, which many integrations do not catch.
Watch the files nobody edits. robots.txt, sitemaps, and feeds are generated rather than published, so they often miss automatic purges and can sit stale for a long time without anyone noticing.
Version your assets. Stylesheets and scripts should carry a version string or hash in the filename or query string, so a change produces a new URL rather than relying on a purge to invalidate the old one.
Check query strings. Some CDN configurations treat ?page=2 and the bare URL as the same resource, or refuse to cache anything with a query string at all. Both behaviors cause confusing bugs.
Test in a private window. Logged-in sessions usually bypass the cache entirely, so the site looks correct to you and wrong to everyone else.
CDNs and SEO
A correctly configured CDN is good for search. It improves the field data Google collects for Core Web Vitals, it makes the site more available to crawlers, and faster response times let crawlers fetch more pages in the same window.
There are a few specific things to get right.
One canonical hostname. The CDN should serve the site at its normal domain, not a second hostname that duplicates every page. If assets are served from a separate CDN domain, that is fine; pages should not be.
Do not block legitimate crawlers. Aggressive bot rules and rate limits sometimes catch Googlebot, Bingbot, and AI crawlers such as GPTBot and ClaudeBot alongside the bad traffic. Verify crawler access after enabling any security feature, and check crawlability in Search Console’s crawl stats report for a rise in failed requests.
Watch redirects and headers. CDN-level rules for forcing HTTPS or stripping the www prefix can stack on top of the origin’s own rules and produce redirect chains. Each hop costs time, and 301 redirects should resolve in one.
Keep geographic targeting intact. A CDN does not change where a business is located or how local relevance is determined; serving from an edge in Denver does not make a Raleigh business look Colorado-based. But a CDN that geo-routes to entirely different content, or blocks whole countries, can affect what crawlers in a given location see.
Do not serve crawlers something different. Any configuration where bots receive different HTML from human visitors is cloaking, whether or not it was intended.
Choosing and configuring one
Cloudflare is the most common choice for small and mid-sized sites, with a capable free tier, DNS, a firewall, and bot protection. Managed WordPress hosts such as WP Engine and Kinsta include their own CDN, already integrated with the platform’s caching, which is usually the simplest option if you are on one. Bunny, Fastly, Amazon CloudFront, and Akamai serve higher-traffic or more specialized needs, with finer control over caching rules and edge logic.
Whichever you use, the configuration questions are the same: what gets cached at the edge and for how long, whether HTML is cached or only assets, how and when the cache is purged, whether images are optimized in transit, and which security rules are active and what they might be blocking. Those five answers determine nearly everything about how the CDN behaves.
A CDN also stacks with the caching already happening elsewhere. A typical WordPress site has an object cache in the database layer, a page cache from a plugin such as WP Rocket, the CDN’s edge cache, and the visitor’s browser cache. Each is a place an old copy can hide. When a change does not appear, work outward from the origin and check each layer in turn rather than clearing everything at once and learning nothing.
When a CDN is worth it
For most business sites, the answer is yes, because it now costs little or nothing and the security and protocol benefits alone justify it. It is clearly worth it when visitors are spread across regions or countries, when the site is image-heavy or serves video, when traffic is spiky, or when the site has been targeted by bots and scrapers. It matters less when the audience is tightly local, the site is small and already fast, and the host is nearby, though even then it rarely hurts.
What it should not be is the first move. A CDN placed in front of a slow site delivers a slow site more efficiently.
Getting it right
We configure CDN and caching layers as part of our page speed optimization services, and we verify the result at the public URL in field data rather than trusting a lab score or the view from inside the admin. If your site is fast for you and slow for everyone else, or changes you published are not showing up, book a discovery call.
