Changes Do Not Appear No Matter How Many Caches You Clear
You publish an edit, clear the cache, reload, and the old version is still there. The problem is almost never that caching failed — it is that you cleared one layer out of six.
The short version
- Six layers, and the plugin button clears one.
- Purge from the inside out: OPcache, object, server, plugin, CDN, browser.
- Test with a cache-busting query string to see the origin.
- Leftover drop-in files from an old host are a frequent cause.
The layers
| # | Layer | Cleared by |
|---|---|---|
| 1 | OPcache (compiled PHP) | Restarting PHP-FPM |
| 2 | Object cache (Redis/Memcached) | Flushing the backend |
| 3 | Server page cache (Varnish, FastCGI, LiteSpeed) | Host panel |
| 4 | Plugin page cache | The plugin button |
| 5 | CDN edge cache | CDN dashboard or API |
| 6 | Browser cache | Hard refresh, or waiting for expiry |
Purge in the right order
Inside out. Purging the CDN first just re-pulls the stale page from the server cache:
# 1. OPcache
sudo systemctl reload php8.3-fpm
# 2. object cache
wp cache flush
# 3. server cache
# host panel, or: sudo systemctl restart varnish
# 4. plugin cache
wp cache flush # or the plugin's own command
# 5. CDN
# dashboard, or the provider's purge API
# 6. browser
# Ctrl+Shift+R, or test in a private windowSee what the origin is actually serving
curl -s "https://example.com/your-page/?nocache=$(date +%s)" | grep -i 'the text you changed'A unique query string bypasses most caches. If the new content appears here, your edit saved correctly and the problem is purely caching. If it does not, the edit did not save — a different problem entirely.
# which caches are reporting?
curl -sI https://example.com/your-page/ | grep -iE 'cache|age|cf-|x-'Headers such as x-cache: HIT or a high age value tell you which layer is holding the old copy.
The leftover drop-in problem
Sites that have changed hosts accumulate caching drop-ins. These load automatically whether or not the plugin that created them still exists:
ls -la wp-content/ | grep -E 'object-cache|advanced-cache'
head -20 wp-content/object-cache.php # which system wrote it?Watch out
Do not delete a drop-in without identifying it. If it belongs to your current object cache, removing it makes the site slower rather than broken, which makes the cause hard to find later.
If only some visitors see the old version
- CDN edge caches are per-location. A purge propagates over seconds to minutes.
- Browser caches are per-visitor and expire on their own schedule.
- Check your cache-control headers — a long max-age on HTML means visitors hold the old page for that long.
curl -sI https://example.com | grep -i cache-controlHTML should have a short or zero max-age. Static assets should have a long one with versioned filenames. If HTML is being cached for a day in the browser, that is a configuration problem rather than a purge problem.
A sane target
- One page cache, at the server or CDN level.
- One object cache.
- No caching plugin at all if the host provides both.
- A written purge order anyone on the team can follow.
Common questions
Why does it look right when I am logged in?
Logged-in requests bypass the page cache. Always verify in a private window.
How long should a CDN purge take?
Seconds to a couple of minutes. Longer than five suggests the purge did not register.
Should I disable caching while developing?
On staging, yes. On production, no — verify with a cache-busting query string instead.
Sumit
Writes everything on TechMozz.