WordPress Changes Not Showing? Clear the Caches in This Order

When WordPress changes are not showing, the edit is mostly saved and an older copy of the page is still being served from one of up to five places, your browser, the page builder’s generated CSS, a caching plugin, your host’s server cache or a CDN such as Cloudflare. So the fix is to clear them in that order, from your own screen outwards, and to check the page in a private window while logged out, since a logged-in owner and a visitor are often shown two different copies. On an agency’s own website, a client logo which had been taken off still showed in three home page carousels until the page builder’s files and the caching plugin were both cleared, and the check which proved it was gone was a logged-out visit.

This post goes through how to confirm the change was saved, why you and your visitors can see different versions, and each cache in the order which I clear them.

First, check that the change was saved

On a published post or page the block editor’s main button now reads Save, and the change is only live once you press it, while a scheduled post waits for its date and a draft stays hidden whatever you save. WordPress’s guide to revisions also notes that autosaves do not overwrite published content, so an edit which the editor saved on its own while you were typing is still a draft until you press the button. I mostly open the page’s revisions to see when it was last saved, which is the quickest way to rule this step out.

Why you see one version and visitors see another

Caching plugins treat logged-in people differently, and the three which I meet most often each do it their own way. LiteSpeed Cache keeps a private cache for logged-in users by default, stored by session, while Breeze leaves logged-in users out of its cache unless you switch them on role by role, and WP Rocket only caches logged-in users with its User Cache add-on. Either way, the copy which you see while logged in is different from the copy your visitors receive, so a change can look finished to you and missing to them, or the other way round.

I would always check in a private window, logged out, before deciding whether a change has gone live, and I test shop and form steps the same way, since security and caching plugins mostly behave differently for administrators.

Clear the caches in this order

1. Your browser

A browser keeps copies of stylesheets and images, and a theme which loads its stylesheet with a version number in the address and a long cache time keeps the old file until that number changes. On a skincare brand’s website, the theme’s stylesheet was cached for a year under the same version number, so after the developer changed it, my browser kept showing the old layout with oversized footer icons, which looked exactly like a bug. Chrome’s keyboard shortcuts list a reload which ignores cached content, Ctrl, Shift and R on Windows or Command, Shift and R on a Mac, and a private window starts with an empty cache too.

2. The page builder’s files

Elementor writes the styles of every page into CSS files of its own, and those files keep the old version after some changes, especially after a page has been rebuilt or moved. Its help article on Clear Files & Data gives the route, Elementor, then Tools, then Clear Files & Data, and the front-end toolbar has a Clear Cache item under Edit with Elementor for the page which you are looking at. If a change still does not appear, Elementor’s article on changes which do not appear online suggests switching the CSS Print Method in Elementor’s performance settings between External File and Internal Embedding.

3. The caching plugin

Breeze puts Purge All Cache in the admin bar under its own menu, with separate purges for its internal cache, Varnish, Cloudflare and the object cache, as its plugin page describes, and LiteSpeed Cache has Purge All under its Toolbox. A full purge makes the next visitor to each page wait while the page is built again, and on a large wine shop the site slowed for a few minutes after every Purge All, so on a busy site I would purge in a quiet hour or purge the one page if the plugin offers it.

4. Your host

Many hosts run a server cache in front of WordPress which no plugin can see. Hostinger’s guide to clearing the cache gives three routes, Clear cache on the website dashboard, the Flush Cache button on the WordPress overview, and Flush cache under its CDN settings. On a course website hosted elsewhere, files which I uploaded over SFTP only appeared after a manual cache clear in the host’s own dashboard, since a file upload goes around WordPress and nothing tells the cache that a file has changed.

5. The CDN

Cloudflare and similar services keep copies of your pages and files on servers around the world. Cloudflare’s guide to purging everything clears the whole site from its Caching settings, and a custom purge clears a single address, while its Development Mode switches the cache off for three hours, which is handy while a designer is making a series of changes.

A cache-busting trap with ?m=

Adding a made-up query string to the address, such as ?v=2, is a quick way to ask for a fresh copy of a page, but the name matters. WordPress reads m as one of its own public query variables, which it uses for date archives, so ?m=1 asks for posts from the year 1, and on this website it returned the 404 page, which looked like the change had broken the post. I use ?v= with a number instead, and I suppose the same goes for p, s and page, which WordPress also reads.

When clearing every cache changes nothing

If the page is still old after all five, the edit is mostly in a different place from the one which is showing. The usual causes which I find are a duplicate page with the same title, where the change went into the copy, a header, footer or sidebar which comes from a template part or a global widget rather than the page itself, and a page builder setting which was changed for the desktop view only, so the phone still shows the old value. WordPress itself keeps very little between requests, since its object cache lasts for one page load unless a persistent cache plugin is installed, so if it is none of these, I would look at the plugins and the host before anything in WordPress.

The same order helps after an update which goes wrong, which my post on briefly unavailable for scheduled maintenance covers, and LinkedIn keeps a cache of its own for link previews, which LinkedIn preview image not showing goes into. My routine for updating WordPress plugins safely ends with the same logged-out check.

Frequently asked questions

Why are my WordPress changes not showing on the live site?

Mostly because a cache is still serving the old copy, from the browser, a page builder’s CSS, a caching plugin, the host or a CDN. Clear them in that order and check the page logged out in a private window.

Why can I see my changes when logged in but visitors cannot?

Caching plugins mostly serve logged-in users a separate copy or no cache at all, so you see the new page while visitors receive the cached one until the plugin’s cache is purged.

How do I clear the cache in WordPress?

Use your caching plugin’s purge button, such as Purge All Cache in the admin bar for Breeze or Purge All in LiteSpeed Cache’s Toolbox, then the flush button in your hosting panel and your CDN if you use one.

Why are my Elementor changes not showing?

Elementor serves styles from generated CSS files, so go to Elementor, then Tools, then Clear Files & Data, then purge your caching plugin, and if the change still does not appear, try switching the CSS Print Method.

Why are my WordPress changes not showing on mobile?

Either the phone’s browser has an old copy, which a private tab rules out, or the change was made for the desktop view only in the page builder, so the tablet and mobile settings still hold the old value.