Why Your Website Changes Aren’t Showing Up: Caching & CDN Explained

You updated the banner. Fixed the typo on the homepage. Changed a price. You checked the backend and it’s all there. But visitors are still seeing the old version, or at least some people see the change, others don’t. You clear your browser cache and spam Ctrl+R and F5. Still no change. That’s the bit that’s supposed to fix it. You ask your developer. They say it’s cached. This is getting confusing.

They’re right. But that answer probably raises more questions than it answers.

Here’s what’s actually happening.

What caching is

Your browser caching recently visited pages to make browsing faster is just one example of this. The same principle applies at the server level, and at greater scale.

Modern websites aren’t like Word documents sitting on a server waiting to be opened. When you request a page, the server builds it on the fly, pulling content from a database, applying templates, checking rules, and delivering the result. That computation happens in milliseconds, but it’s real work. The thing is, for a large portion of visitors, the results are identical. Most people hitting your homepage or a product page get exactly the same output. They’re not logged in, they’re not in a special cohort, there’s nothing to distinguish their request. So rather than recomputing the same answer thousands of times, caching saves a copy of that output and serves it directly.

This is a good thing. It’s why your site can handle traffic spikes without falling over. The problem comes when that saved copy goes stale.

What a CDN is

A CDN (Content Delivery Network) is a network of servers spread across the globe. When your site uses a CDN, copies of your content are distributed to servers in dozens of locations. Someone in Perth gets served from a server nearby. Someone in London gets served from one closer to them.

There are two reasons this matters. The first is speed. Fetching a page from a server in Singapore is faster than fetching it from one in Sydney if you’re sitting in Kuala Lumpur.

This is also why the physical location of your origin server matters less than you might think once a CDN is in front of it. Your visitors are hitting an edge node close to them, not the origin. Where you locate your server tends to be driven by data sovereignty requirements, compliance obligations, or where your team is based, not by proximity to your users.

The second is load. If every request from every visitor around the world directly hits your web server, you have a fragile setup.

DDoS and the Slashdot effectSlashdot was a tech news site popular in the late 90s and early 2000s, and it was so widely read that when it linked to a smaller site, the resulting flood of traffic would frequently take that site offline. The Slashdot effect became shorthand for any sudden traffic surge that buckles an origin server. The result looks similar to a DDoS attack. The server gets overwhelmed and goes down either way. The difference is intent: a DDoS is malicious, the Slashdot effect is just enthusiastic. CDNs are a big part of the reason you rarely hear that term anymore. Distributing requests across dozens of nodes around the world means no single server absorbs everything at once.

Here’s the important part: those CDN nodes work by storing cached copies of your content. The CDN and caching are two separate things. The CDN is a network that deploys caching at a global scale. That’s why the terms get used interchangeably. It’s not sloppy language. The concepts genuinely overlap.

So why are visitors seeing an old version?

When you make a change on your site, the update goes to your origin server, the main one your site lives on. But all those CDN nodes around the world still have the old version saved. They don’t know anything changed.

Until something tells them to fetch a fresh copy, they’ll keep serving the cached one.

We’ve seen this with a publishing client we support. A content update would go live, the team would check it on their end and see the change, then get reports from users who still saw the previous version. The server was fine. The CDN was doing exactly what it was built to do. That was the problem.

The fix is cache invalidation, which means telling the CDN nodes to discard their saved copies and pull a fresh version from the origin. Depending on how your CDN is configured, this might happen automatically after a set time period, or it might need to be triggered manually after a deployment.

If it’s not configured well, changes can take hours to reach everyone. Or longer.

The question worth asking

You don’t need to know how to configure a CDN. But if your developer tells you a change isn’t live yet because of caching, it’s worth asking: is this a server cache or a CDN cache? The answer tells you whether it’ll resolve on its own, how long it might take, and whether someone needs to push a button.

That’s the distinction that actually matters in practice. Not the technical detail, but knowing there are two layers where things can get stuck, and that your developer should have a clear answer about which one it is.

If they don’t, that’s worth a follow-up conversation.