To clear the WordPress cache completely, clear from the inside out: object cache first, then page cache (your caching plugin and your host’s, both), then the CDN, then the browser. The order matters because the layers nest, and an outer layer will happily refill itself with the stale content you just cleared from view but not from the source.
That is the whole article in one paragraph. The rest is how to clear each layer, how to tell it worked, and the part almost nobody tells you: what it means when you clear everything and the problem is still there.
Why the order matters
“Did you clear the cache?” is the most common instruction in WordPress support, and it usually arrives with no explanation of which cache. Most sites have four layers, and they nest like copies of copies:
- The object cache holds raw data: query results, options, sessions.
- The page cache holds finished pages built from that data. Many sites have two of these, one from a plugin and one from the host.
- The CDN holds copies of pages and assets at the network edge, close to your visitors.
- The browser holds whatever the CDN sent it last time.
Each layer feeds the next one out. Clear the browser while the CDN is stale, and the browser refills with the stale page. Purge the CDN while your page cache is stale, and the CDN pulls the stale page from your server and stores it again. This is why the change you made “shows on my phone but not my laptop,” and why clearing caches at random feels like whack-a-mole.
Clear from the deepest layer outward and nothing refills from stale source material. Here is each layer, in order.
1. Object cache: the deepest layer
The object cache stores data, not pages: the database answers WordPress asked for recently, held in memory by Redis or Memcached so they do not need asking again. Not every site has one. If you are on quality managed hosting, you probably do. This layer rarely causes “my change isn’t showing,” but when it holds a stale option or menu, it can poison every page built after it, which is exactly why it gets cleared first.
How to clear it: If you have server access, wp cache flush from WP-CLI clears it in one command. Otherwise look for a “flush object cache” button in your host’s panel, or in the Redis/Memcached plugin’s settings page if your site uses one.
How to know it worked: The flush is immediate. If your host’s panel shows an object-cache hit rate, it will dip and rebuild over the next minutes. That rebuild is normal and costs little.
2. Page cache: the one you probably have twice
The page cache stores finished HTML so your server does not rebuild a page for every visitor. This is the layer people usually mean by “the cache,” and it is the most common home of a stale page. The trap: many sites run two page caches without knowing it, one from a caching plugin and one at the server level from the host. Clearing the plugin’s cache while the host’s cache keeps serving the old page is the single most common way “I cleared the cache” turns out to be false.
How to clear it: In your caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, whichever you run), use “purge all” or “clear cache,” not the single-page purge, when you are troubleshooting. Then check your hosting panel for a separate server cache button; hosts running Varnish or NGINX caching put a purge control in the dashboard. Press both. If you only find one, ask your host directly whether a server-level cache exists. On our managed WordPress hosting, this layer is one cache, not two, which removes the trap entirely.
How to know it worked: Load the page in a private window. The first load after a full purge is noticeably slower, because the server is rebuilding the page. That slow first load is your confirmation, not a problem.
3. CDN: the copy at the edge
A CDN keeps copies of your pages and assets on servers near your visitors. It is why your site is fast in Sydney when your server is in Dallas, and it is also why a change can look live to you and stale to everyone else: your requests and theirs are answered by different edge servers, each with its own copy.
How to clear it: In your CDN dashboard (Cloudflare and the like), use “purge everything” while troubleshooting. Targeted single-URL purges are kinder to performance, but when you are chasing a stale page you want certainty, not efficiency. If your CDN runs through your host, the host panel usually has the purge button.
How to know it worked: Check the response headers in your browser’s DevTools Network tab. A header like cf-cache-status or x-cache reading MISS on the next load, then HIT after, means the edge refilled from your now-fresh origin. Exactly what you want.
4. Browser: last, on purpose
The browser cache is the only layer most people ever clear, and they clear it first, which is backwards. Refreshing before the deeper layers are clean just re-downloads the stale page and stores it again.
How to clear it: Do not clear your whole browser history. Hard-refresh the page (Cmd+Shift+R on Mac, Ctrl+Shift+R on Windows), or better, check the site in a private window, which uses no prior cache at all. The private window is the honest test: it sees your site the way a first-time visitor does.
How to know it worked: If the private window shows the fresh page, you are done, and anyone still seeing the old version is looking at their own browser’s copy, which expires on its own.
A footnote on OPcache: there is a fifth cache, PHP’s OPcache, which stores compiled code rather than content. You cannot clear it from WordPress, and you almost never need to; it matters after code deployments, not content changes. If a code change refuses to appear, that is a question for your host, and a good one gets it done in minutes.
The 10-second version
Troubleshooting a stale page and short on time? Purge your page cache (plugin and host), then check in a private window. That resolves most cases. If it does not, run the full order above: object cache, page cache, CDN, browser.
When the cache will not clear
Some of you arrived here from searching “wordpress cache not clearing.” When the stale content survives a full inside-out pass, it is almost always one of these:
- Two page caches, one forgotten. The most common cause, covered above. If you have ever installed a second caching plugin “to compare,” confirm the loser is fully deactivated, not just idle. Two page caches with different rules do not just go stale; they slow the site down, fighting over the same job.
- A CDN TTL doing its job. If your CDN is set to hold pages for a day, it will, purge buttons aside, if the purge only covered assets and not HTML. Check whether your CDN caches HTML at all, and purge everything, not just files.
- The page is cached per-device or per-cookie. Mobile and desktop variants, logged-in cookies, currency or geo variants: each is its own cache entry. You cleared one variant and tested another.
- It is not caching. The change never saved, a page builder holds its own stored copy of the layout, or you edited a template the page does not actually use. Caching is the first suspect and not always the guilty one.
Here is the deeper pattern we see across client sites: if you are clearing caches every week just to keep the site behaving, the cache is not your problem. It is your painkiller. Caching exists to make a fast server faster, not to make a slow server tolerable, and a site that falls apart whenever the cache is empty is telling you what sits underneath it. You can measure that directly: run our free speed audit. It reads your site’s real response numbers, including the server speed your cache usually hides. It takes about 30 seconds and does not ask for your email.
If the uncached numbers come back bad, the fix is not another purge button. We wrote up that diagnostic separately: why your WordPress backend is slow, because wp-admin is the one place caching never reaches, and it shows your server’s true speed with the makeup off.
The four layers at a glance
| Layer | What it stores | Where it lives | How to clear it |
|---|---|---|---|
| Object cache | Data: queries, options | Redis/Memcached on your server | wp cache flush, host panel, or plugin button |
| Page cache | Finished HTML pages | Caching plugin AND often the host | “Purge all” in the plugin, plus the host’s purge button |
| CDN | Pages and assets at the edge | Cloudflare or your host’s CDN | “Purge everything” in the CDN dashboard |
| Browser | Whatever it received last | Each visitor’s device | Hard refresh; test in a private window |
One honest note on who clears what: on a well-run managed platform, you should rarely be doing any of this. Cache invalidation on a content change should be automatic, the layers should be configured to agree with each other, and a human should own the configuration. That is how we run it, including for WooCommerce stores, where a stale cart or price is not an inconvenience but a refund. If cache-clearing has become a weekly chore on your site, that chore is a symptom.
FAQ
How do I clear my WordPress cache?
Clear from the inside out: flush the object cache (if your host runs Redis or Memcached), purge all in your caching plugin and in your host’s server cache, purge your CDN, then hard-refresh or test in a private window. The order prevents outer layers refilling from stale inner ones.
How do I clear the WordPress cache manually, without a plugin?
With WP-CLI: wp cache flush clears the object cache. Server page caches and CDNs are cleared from your hosting or CDN dashboard, not from WordPress itself. In the browser, a hard refresh (Cmd+Shift+R or Ctrl+Shift+R) bypasses the local copy.
Why is my WordPress cache not clearing?
Usually a second cache you forgot: a host-level page cache behind your caching plugin, or a CDN still holding HTML. Also check per-device cache variants and whether the change actually saved. If stale content survives a full inside-out clear of all four layers, the cause is not caching.
How often should I clear my WordPress cache?
Rarely, on purpose. A well-configured stack invalidates its own cache when content changes. Clear it when troubleshooting a stale page or after major changes to your theme or plugins. If you need to clear it on a schedule to keep the site behaving, the underlying configuration or hosting is the real problem.
Does clearing the cache speed up WordPress?
No, the opposite: the first loads after a purge are slower while the cache rebuilds. Clearing fixes stale content, not speed. If your site is slow, the cause lives in your server, plugins, or configuration, and it shows most honestly in the uncached backend.
Bottom Line
Your WordPress site has four cache layers: object cache, page cache (often twice), CDN, and browser. Clear them in that order, inside out, so no layer refills from a stale one, and verify in a private window. The two traps that defeat most people are the second page cache they did not know they had and the CDN holding HTML by design. And keep the verdict in view: clearing the cache is a test, not a fix. If the problem survives all four layers, or if clearing has become a ritual, the cache was never your problem, and the real one is measurable in about 30 seconds.
