Cache invalidation: why your change is not showing up yet
You published, refreshed, and the old page is still there. Which cache is holding it, how to clear each one, and how a good setup makes the problem disappear.
The short answer
You changed the page, you published, you refreshed, and there it is: the old version. Nine times out of ten nothing failed. A copy of the old page is being served from a cache that has not yet expired: your own browser, the edge network near you, or a cache sitting in front of your origin. Find out which, clear it, and understand why a well-run setup never makes you ask.
Find the layer, in order
- Your browser. Open the page in a private window, or on another device. If the new version shows there, your browser was the culprit and nothing else needs doing.
- The edge. If the private window also shows the old version, the edge location near you still holds the previous copy. Purge the page, or the whole site, at the CDN. Check again from a public tool that fetches from several locations.
- The origin. If the origin itself serves the old version, the deployment did not finish or went to the wrong place. Check the deployment log; this is the only case where something actually failed.
| Symptom | Layer | Fix |
|---|---|---|
| Old for you, new for a colleague | Browser | Private window, hard refresh |
| Old in a private window too, new after a while | Edge | Purge, or wait for TTL |
| Old for everyone, everywhere, including a fresh fetch of the origin | Origin | Check the deployment |
| Page new, but an image or style still old | Browser or edge holding the file longer | Versioned file names |
How a good setup removes the question
Two techniques together make stale changes a thing of the past:
- Versioned file names. Every build gives changed styles, scripts and images a new name. The page references the new name; old copies are simply never asked for again. Those files can then be cached for a year without risk.
- Purge on publish. When a page changes, the publish step tells the edge to drop the old copy. The next visitor gets the new one, from the edge, at full speed.
On a modern static platform both happen automatically on every deployment: the build names the files, the deployment purges the pages. Changes are visible everywhere within seconds, and nobody has to know what a cache is.
What this means for you
Next time a change does not appear, check a private window before anything else, then ask for a purge. And ask whoever runs the site whether assets are versioned and pages are purged on publish. When both are true, you can stop thinking about caches entirely, which is the correct amount to think about them.
Frequently asked questions
I did a hard refresh and it is still old. Now what?
Then it is not your browser. The edge location near you still holds the previous copy within its time to live. Purge it, or wait for expiry, and check from a public tool that queries from several locations. If the origin itself shows the old version, the deployment has not completed.
Why does my colleague see the new version and I do not?
Different browser cache, or a different edge location with a different copy age. It is the clearest sign that the change is live and you are looking at a cached copy. A private window confirms it in seconds.
Can we make changes appear instantly, always?
Yes: purge the affected pages at the edge as part of every publish, and give changing files new names so old copies are never referenced. On a modern platform both happen automatically. Instant everywhere, without giving up the speed caching provides.
Sources
- MDN Web Docs: HTTP caching (accessed 2026-09-11)
- Cloudflare Developers: Purge cache (accessed 2026-09-11)