You edit some text in the admin, save, open the site — unchanged. Edit again, still unchanged. You start wondering whether it saved at all.
Nearly everyone who has managed a website has spent half an hour on this. The cause is usually not the edit. It is that several layers of cache sit between you and the server, any of which may be holding the old version.
Work through them nearest first. The order matters, because starting close eliminates possibilities fastest.
Layer zero: are you editing the same thing you are viewing
Rule this out first, because it happens more than people admit.
Editing the Chinese page and viewing the English one, editing a draft rather than publishing, editing a similar page, or having two admin tabs open where one overwrote the other. These sound careless and occur easily on a site with many pages.
To confirm: temporarily insert a distinctive string into the text you are editing — ZZTEST123 — and save. Search for that string at every step below and the ambiguity disappears. Remove it afterwards.
Layer one: your browser
The nearest layer and the most frequent culprit.
Browsers store pages and assets locally and reuse them. Stylesheets and scripts in particular are held for a long time.
To eliminate: open the page in a private window, which ignores the existing cache. If it is current there, the problem is your browser and your visitors are seeing the right thing.
A hard refresh (Ctrl+Shift+R or Cmd+Shift+R) also works, but a private window is more thorough and does not disturb your normal browsing.
Still old in a private window? Continue.
Layer two: the CDN
If you use Cloudflare or similar, it holds a copy at locations near your visitors.
To confirm: add a random query parameter — ?x=12345. Addresses with parameters are usually not cached and go to the origin. If the version with a parameter is current, the CDN is holding the old one.
This test is useful because it also eliminates the browser at the same time — the new address was never cached there either.
To resolve: purge in the CDN dashboard. But the better question is why it did not expire by itself. Editing content should normally trigger a purge, and if it must be done by hand every time, that automation is missing and will eventually be forgotten.
Layer three: the site’s own page cache
Many systems save generated pages as files and serve those rather than running the software again. Every WordPress caching plugin works this way.
To confirm: look for a header added by the caching plugin (names vary), or simply purge from the admin and look again.
The characteristic failure here is a gap in the invalidation rules. Add a new template file that is not on the list of things that trigger a purge, and editing that template changes nothing — permanently, however many times you try.
We did this ourselves: a new template was missing from the watch list, deployment changed nothing visible, and it took a while to think of it. What defines this class of problem is that it raises no error. Everything looks correct; the content simply does not update.
Layer four: server-side object cache
Deeper than page caching — this stores database query results. Content changes, the query still returns the old value, and regenerating the page produces old data.
Uncommon, and not configured on most small sites. If the first three are eliminated and it is still stale, ask whoever maintains the site whether this is enabled.
Layer five: a static site that has not been republished
If your site is statically generated — pages built in advance, visitors receiving files — then editing content in an admin does not update the live site. It has to be regenerated and republished.
Not a bug, an inherent property of the architecture. But unless someone explained it, you will assume a caching problem and purge things indefinitely without effect.
Our own site works this way, so the process is fixed at two steps: edit, then run one publish command. It is written down, because forgetting it looks exactly like a caching problem.
A special case: the CDN cached a 404
Worth its own section, because the behaviour is counter-intuitive.
An image has not been uploaded yet. Someone — or a crawler — requests that address once, and the CDN records that there is nothing there. You then upload the image and visitors still see nothing, because the CDN is still serving the remembered 404.
You will check the upload and the path repeatedly, and both will be fine.
We have hit this twice and were quicker the second time. The random-parameter test identifies it too: if image-url?x=1 displays and the plain address does not, it is caching, and a purge resolves it.
Keep the order
Private window → random parameter → purge the site cache → ask about object caching → confirm whether republishing is required.
Five steps, each under a minute, and between them they locate almost everything. The important part is not skipping ahead. Most of the time lost to this is spent purging a CDN when the stale copy was in the browser all along.
One further observation: if you find yourself purging caches regularly, treat that as a signal. Content changes should invalidate caches automatically, and any step that depends on someone remembering will eventually be forgotten. It is worth having fixed once rather than handled repeatedly.
On the projects we deliver, invalidation follows content changes automatically and clients do not need to remember it. If your current site relies on manual purging, it is fair to ask why.