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 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 window

See 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?

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-control

HTML 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.