pixie.
ESLet’s talk
PERFORMANCE AND SECURITYTechnical

Cache and CDN: why you cannot see a published change

Cache and CDN: why you sometimes cannot see a change you just published, what Cache-Control does and how to force an update when you need to.

By Pixie Estudio5 min read

You published a change, you open the page and everything looks the same. You reload and nothing. On one phone it shows, on another it does not. That situation almost always has one name: cache. Understanding how cache and CDN work saves hours of confusion and lets you configure your site to be fast without showing old content.

This technical guide explains in which places a copy of your website is stored, who decides how long it lasts, how to check which version you are seeing and how to make a change show up instantly when you need it.

Cache and CDN: what they are and why they exist

A cache is a stored copy of a resource (a page, an image, a stylesheet) so that it does not have to be requested again every time. It saves time and bandwidth: if the browser already has the logo, it does not download it again. The downside is that if the resource changes and the copy is not updated, the old version keeps showing.

There are several layers of cache between your server and whoever looks at your website:

  1. The browser of each visitor.
  2. A CDN (content delivery network) that keeps copies on servers close to visitors. MDN explains what a CDN is.
  3. Server or application caches: already generated pages that get reused.
  4. Intermediate proxies, rarer today.

A published change has to go through all the layers, and each one may keep serving the old version for a while.

Cache-Control: who decides how long it lasts

Your server tells browsers and CDNs what to do with each response through the Cache-Control header. The main values, documented on MDN:

Value What it means
max-age=31536000 It can be stored for that time (in seconds) without asking again
no-cache It can be stored, but it has to be revalidated with the server before use
no-store Never store it
public / private Whether a CDN can also store it (public) or only the browser (private)
immutable The file never changes while its max-age lasts

A detail that causes confusion: no-cache does not mean "do not store", but "check before using". A page with no-cache is served quickly if it has not changed, and updated if it has. The guide on HTTP caching on MDN develops the whole model.

The strategy that works: two different rules

A modern site usually combines two policies:

  • Files with a unique name (with a "fingerprint" or hash), such as app.4f9c2.js or styles.a81b3.css: they can be stored forever (long max-age and immutable), because when the content changes, the name changes. That way the browser requests the new file with no cache in its way.
  • HTML pages, which point to those files: they must always be revalidated (no-cache), so that the visitor receives the new HTML, which in turn references the new files.

If the HTML is stored for a long time, the browser may try to load files that no longer exist after a deployment. That is the origin of many "it broke after publishing" reports.

How to know which version you are seeing

Before assuming the change was not published, check:

  1. Open a private window. If the change shows up there, it was your browser's cache.
  2. Force a reload (Ctrl + Shift + R on Windows and Linux, Cmd + Shift + R on Mac).
  3. Look at the headers in the browser's developer tools (Network tab): look for Cache-Control and, if there is a CDN, headers that indicate whether the response came from its cache (they are usually called Age or CF-Cache-Status, depending on the provider).
  4. Try a parameter in the address (?v=2) to skip the cache for that URL and confirm the change exists on the server.
  5. Query from the terminal, which does not use the browser cache:
curl -I https://yourcompany.com.ar/page/

That shows you the exact headers any client receives.

How to force an update

  • In the browser: forced reload or clearing the site's data.
  • In the CDN: most offer purging the cache (for the whole site or for specific addresses). After an important change, purging avoids waiting for it to expire.
  • On the server or in the application: clear the application cache or the caching plugin's cache.
  • For static files: changing the name (versioning) is more reliable than depending on purges.

What should not be cached

  • Pages with personal or session data (private or no-store).
  • API responses that change all the time.
  • Payment steps and forms with state.

Common mistakes

  • Giving a long max-age to HTML pages. Visitors see old versions and, after a deployment, may load files that do not exist.
  • Confusing no-cache with no-store.
  • Purging the CDN but not the browser cache (or the other way around), and seeing different results depending on the place.
  • Changing a file without changing its name and expecting everyone to reload it.
  • Not testing in a private window before reporting that "it was not published".

Frequently asked questions

Why does my client see the change and I do not?

Every browser has its own cache. Try a private window or force the reload.

Can cache affect my rankings?

Well used, it helps: a fast site is crawled better. Badly configured, it can make outdated content show. For more about speed, see the guide on Core Web Vitals.

How long does a change take to show for everyone?

It depends on the Cache-Control that the previous responses had and on whether you purged the CDN. With a good configuration, it is immediate or almost.

What to do next

If you asked for a change and you cannot see it, check first with these steps and, if it persists, write to us from support. If you would like us to take care of your site's cache configuration, take a look at the website tune-up. And to learn how to ask for changes clearly, read how to ask for website changes without losing time.

More guides