How I clear every cache layer when WordPress changes don't show up

Why don't WordPress changes show up straight away?

Because a cache is doing its job. Every layer between your edit and a visitor keeps a saved copy of the page, or of the files it loads, so it doesn't have to build them again. That copy doesn't know you've just pressed Update, and it keeps serving what it saved until it expires or somebody clears it. Sorting out which layer holds what is a regular part of my WordPress speed optimization service.

So the question isn't whether to clear the cache. It's which one, and in what order. Clear the wrong layer and nothing changes. Clear the right ones in the wrong order and an outer cache refills itself from an inner one that's still stale.

Before I purge anything, I rule out two causes that aren't caching at all. Is the change actually published, not sitting in a draft or a pending revision? And am I looking at the site I edited, not a staging copy or a domain whose DNS still points at an old host?

Which caches sit between an edit and a visitor?

Counting from the database outwards, these are the layers I expect on a typical WordPress site. Not every site has all of them, so finding yours comes first.

Two of those catch people out. Cloudflare doesn't cache HTML by default, only static files such as CSS, JavaScript and images. If a Cloudflare site keeps serving an old page, not just old styling, someone's usually added a cache rule that makes HTML eligible, so that's where I look first.

The other is the browser. Cloudflare's documentation says a purge doesn't affect assets already stored in a visitor's browser, and its default Browser Cache TTL is four hours. So a file that keeps the same URL can stay old on a returning visitor's screen long after every server has the new one.

How do I clear the WordPress cache manually, without a plugin?

Delete the page cache files over SFTP or the host's file manager. It's the fallback when a broken cached page stops the dashboard loading. WP Super Cache, for example, keeps its pages in wp-content/cache/supercache/ with a folder named after your host, and its documentation says the cache directory "is only for temporary files".

I delete the cached pages inside that folder and nothing else. Files like wp-content/advanced-cache.php and wp-cache-config.php are the plugin's setup, not cached pages, so removing them changes how caching runs rather than clearing it. Server caches run by the host, and Cloudflare, don't live in WordPress's files at all, so they still need their own purge.

How do I prove what's actually live?

I stop trusting screens and ask the server directly. A request from the command line has no browser cache behind it. I add a query string nobody's used before, like ?cb= followed by the time, because Cloudflare's default cache key includes the query string, so to the CDN it's a new address with no saved copy, unless someone's set the cache key to ignore query strings.

Then I read the headers, not the page. curl -sI shows them without the body. On Cloudflare, cf-cache-status says what the edge did: HIT means it served a saved copy, MISS means it fetched from the server, and DYNAMIC means it didn't treat the response as cacheable. Hosts add headers of their own, and the names vary.

Once the busted URL shows the change, I request the plain URL too. If the plain one's still old, an outer cache is holding it, which is the usual story behind a WordPress cache not clearing. If both are old, the problem sits further in: the change never reached the server, or it's stuck in the builder's CSS or the object cache. It's the same request I run against old URLs in the first hour after a site moves platforms.

The trap most guides skip makes a correct deploy look broken. A theme usually loads its stylesheet with a ?ver= number, and the WordPress reference says that when no version's given, it adds the installed WordPress version instead. Edit style.css without bumping the theme's version and the file's URL doesn't change, so a browser that saved the old file keeps using it.

It's caught me on my own site. A stylesheet fix shipped under an unchanged URL, every server-side check said the deploy was right, and browsers showed the old layout for hours. The fix wasn't another purge. It was the cache-busting pattern MDN describes: put a version or hash in the file's address and never change a file in place.

Why can a page builder keep showing old styles?

Because builders cache their own output, separately from every layer above them. Elementor's developer docs say the styles set in the editor are saved in the database and used to generate CSS files. If a file isn't regenerated, the database has the new colour and the file still has the old one. Divi 5 does much the same with a static CSS cache, and its help centre puts clearing it first after an update.

Elementor's Element Caching goes further, storing a widget's rendered HTML in the database. Elementor says it's off by default for widgets and meant for static elements, though containers and sections are always cached once it's on. Where it's on, I treat it as one more layer: Clear Files & Data, then purge outwards again. Its speed and cache options sit with the other Elementor SEO settings.

Builders also cause stale styling that isn't a cache at all, like custom CSS pasted into three places. That's where a cache question turns into what the builder's markup does to the page. On Divi, the Theme Options I check for search sit near the CSS settings, so I look at both.