WordPress Changes Not Showing? Find the Cache

Updated for WordPress 7.1 and PHP 8.3 — 7 September 2026.

WordPress changes not showing on the front end almost always means you are looking at a cached copy, not a lost edit. The work is not saved and gone; it is sitting in the database while something between you and it serves an older version. Nine times in ten the fix is finding which of four or five caching layers is holding the stale page, and the trick is testing them in the right order so you stop at the first one that answers.

Confirm the change actually saved before blaming a cache

Thirty seconds of checking here saves you an hour of purging caches that were never the problem. Open the post or page in the editor again and look at the content. If your edit is not there, this is not a caching issue — it is a failed save, and the usual causes are a session that expired mid-edit, a browser tab left open overnight, or a plugin conflict in the editor.

While you are in the editor, check the revision history. WordPress stores revisions automatically, and if your text appears in a revision but not in the published version, you published an older revision over the top of it.

Test in a private window first

A private or incognito window is the fastest way to split the problem in half, and it costs you one keystroke. Load the page in a private window, logged out.

• The change appears in a private window but not your normal one — the stale copy is in your own browser. Hard-refresh, or clear that site’s cached files. Nothing on the server is wrong.
• The change is missing in both — the stale copy is on the server side, and you can stop looking at your own machine entirely.

This matters because logged-in users usually bypass page caching altogether. If you only ever check while logged in, you are testing a different code path from the one your visitors get, and you can spend an afternoon chasing a problem your readers never had — or miss one they all have.

Work through the caching layers in order

Test from the visitor’s edge inwards, because the outermost layer masks everything behind it. Purging your object cache while a CDN is serving a day-old HTML file tells you nothing.

• CDN or edge cache. Cloudflare and similar proxies hold your HTML at locations near your visitors. This is the outermost layer and the one most often forgotten, because it lives in a dashboard away from WordPress.
• Host-level page cache. Most managed WordPress hosts cache full pages themselves, usually clearing automatically when you publish. Usually.
• Caching plugin. If one is installed, it is writing static HTML files and serving those instead of running WordPress.
• Object cache. Redis or Memcached holding database query results. This one rarely causes missing content changes, but it does cause stale options, menus and widget output.
• Page builder cache. Elementor, Divi and Bricks generate their own CSS files per page. A styling change that will not appear while the text updates fine is nearly always this.

That last one catches people out constantly. If your text edits show but your design edits do not, stop purging page caches and regenerate the builder’s CSS instead.

Read the response headers to find the culprit

Response headers tell you which layer served the page, which turns guesswork into a two-minute answer. Open your browser’s developer tools, go to the Network tab, reload the page, and click the request for the document itself.

Look for headers such as cf-cache-status, x-cache, age, and any header carrying your host’s or plugin’s name. A status of HIT with a large age value means you are being served a stored copy that old, in seconds. MISS or BYPASS means that layer is not the one holding your change, and you can move inward to the next.

Chrome’s Network panel documentation covers reading these if the tooling is unfamiliar. It is worth ten minutes of learning once; you will use it for the rest of your career.

Purge from the outside in

Clear the outermost layer first, then retest before touching the next one, or you will never learn which layer was actually at fault. Purge the CDN, reload in a private window, and check. Still stale? Purge the host cache, retest. Then the plugin, then the object cache.

If you have WP-CLI access over SSH, the object cache is a single command:

wp cache flush

That flushes the persistent object cache. It does not touch page caches, CDNs or builder CSS — those are separate systems with separate controls, and expecting one command to clear everything is a common and frustrating misconception. The WP-CLI cache documentation is explicit about that scope.

When two caching layers fight each other

Running a caching plugin on a host that already caches at the edge produces symptoms that look like neither system misbehaving. The two layers hold different ideas about what is current, and you get changes that appear for some visitors and not others, or appear and then revert.

In practice this is the single most common cause of “I purged everything and it came back” — one layer repopulates from the other’s stale copy. Pick one layer and let it do the job. I go into what this costs a store specifically in how to speed up WooCommerce without breaking checkout, where a stale cache is not a cosmetic problem but a wrong basket.

Frequently asked questions

Why do my changes show when logged in but not logged out?

Logged-in users normally bypass page caching so that admins see live content. Logged-out visitors get the cached copy. Seeing the change only while logged in is strong evidence that a page cache is serving a stale file, not that your edit failed.

I cleared my browser cache and nothing changed. What now?

Your browser was not the problem. Test in a private window to confirm, then work outward-in through the server-side layers: CDN, host cache, caching plugin, object cache.

Why do CSS changes lag behind text changes?

Stylesheets are separate files with their own cache lifetimes, registered through wp_enqueue_style(), and page builders compile their own CSS per page. Text lives in the HTML; styling usually does not. Regenerate the builder’s CSS rather than purging page caches again.

How long should I wait before assuming something is broken?

A correctly configured platform clears the cache on publish, so the change should appear within seconds. If you are still waiting after a couple of minutes and a private window shows the old version, something is holding it — waiting longer will not help.

Could this be a staging site rather than a cache?

Yes, and it is worth ruling out early. Check the URL in the address bar carefully. Editing staging and checking production is a surprisingly common way to lose an afternoon.

Related reading

• WordPress site down after an update — when the page is not stale but broken.
• How to speed up WooCommerce without breaking checkout — what must never be cached in a store.
• How to make Core Web Vitals pass on WordPress — caching as an optimisation rather than a bug.
• Fixing mixed content warnings — another problem that survives a purge.
• All knowledge base articles