When Your Cache Plugin Is Fighting Your Host
We may earn a commission if you buy through our links. It does not change what we recommend or what you pay. How this works.
Sites that have changed hosts accumulate caching layers. The symptom is always the same: you publish a change, clear the cache, and the old version is still there. The cause is usually a drop-in file from a caching system you no longer use.
The short version
- Check wp-content for object-cache.php and advanced-cache.php first.
- Those files persist after the plugin that created them is deleted.
- Run one page cache and one object cache. Never two of either.
- Server and CDN caches clear separately from the plugin.
The layers, in order
| Layer | Where | Cleared by |
|---|---|---|
| Browser cache | Visitor’s device | Cache-control headers |
| CDN edge cache | Provider | CDN dashboard or API |
| Server page cache | Varnish, Nginx FastCGI, LiteSpeed | Host panel |
| Plugin page cache | wp-content/cache | The plugin |
| Object cache | Redis or Memcached | Flushing the backend |
| OPcache | PHP | Restarting PHP-FPM |
Clearing the plugin cache clears exactly one of these.
Find the leftovers
ls -la wp-content/ | grep -E 'object-cache|advanced-cache|db\.php'
cat wp-content/object-cache.php | head -20 # which system wrote it?
cat wp-content/advanced-cache.php | head -20These are drop-ins: WordPress loads them automatically regardless of which plugins are active. Deleting a caching plugin frequently leaves them behind, and they keep running.
Watch out
Do not delete a drop-in without checking what wrote it. If it belongs to your current caching system, removing it disables object caching and your site gets slower, not broken — which makes the cause hard to spot later.
The sequence that fixes most cases
1. Identify every caching layer in play
Host panel, plugin list, CDN dashboard, and the drop-in files.
2. Pick one page cache and one object cache
Usually the host’s page cache plus one object cache backend.
3. Remove the others completely
Deactivate, delete, and then remove their drop-in files.
4. Purge everything in order
Innermost first: OPcache, object cache, server cache, plugin cache, CDN.
5. Verify with a hard request
curl with a cache-busting query string, so you are looking at origin output.
# origin response, bypassing most caches
curl -sI "https://example.com/?cachebust=$(date +%s)" | grep -iE 'cache|age|x-'Signs of a conflict
- Changes appear logged in and not logged out.
- A hard refresh shows the new version but a normal load does not.
- The cache clears but the site is still slow, suggesting object caching is broken rather than page caching.
- Logged-in users see other users’ content — serious, and a sign a page cache is serving authenticated responses.
Watch out
If logged-in users ever see another user’s data, stop and disable page caching immediately. That is a cache configuration serving personalised responses to everyone, and on an e-commerce site it is a data-protection incident.
A sane target configuration
- One page cache, preferably at the server or CDN level.
- One object cache, with a healthy backend.
- No caching plugin at all if the host provides both.
- A documented purge order so anyone can clear everything correctly.
Common questions
Can I run a caching plugin on managed hosting?
Usually you should not. Most managed hosts cache at the server level and a plugin on top causes exactly these conflicts.
Do I need an object cache?
On a content site with a reasonable database, it helps. On a very small site the difference is marginal.
Why does the site look fine for me and broken for visitors?
You are logged in and bypassing the page cache. Always test in a private window.
Sumit
Writes everything on TechMozz.