WordPress Changes Not Showing? How to Find (and Clear) the Cache That’s Hiding Them

You change a headline, swap a button color, or fix a typo, click Update, and WordPress says “Post updated.” Then you open the live site and nothing has changed. You refresh. Still the old version. WordPress changes not showing on the live site is one of the most common “is my site broken?” moments, and it almost never means anything is broken. It means a cache somewhere between your server and your screen is still handing out an old copy.

The fix is knowing which cache is holding the old version, and clearing the right one instead of randomly clicking every “Purge” button you can find.

Why Are My WordPress Changes Not Showing?

WordPress changes usually don’t show because a cached copy of the page is being served instead of the updated one. The cache can live in your browser, in a WordPress caching plugin, on the hosting server, or on a CDN like Cloudflare, and any one of them can keep serving the old version after you click Update.

Caching is a good thing. A cached page loads fast because the server doesn’t rebuild it from PHP and the database on every visit. The trade-off is that a cached page is a snapshot, and snapshots don’t update themselves the instant you edit something.

A typical WordPress site can have four cache layers stacked on top of each other:

1. Browser cache: your own browser stores CSS, JavaScript, images, and sometimes whole pages.
2. Plugin cache: WP Rocket, LiteSpeed Cache, W3 Total Cache, and similar plugins save static HTML copies of pages, plus minified and combined CSS and JS files.
3. Server cache: many hosts run their own page cache (Varnish, Nginx FastCGI cache, LiteSpeed server cache) and object cache (Redis or Memcached).
4. CDN cache: services like Cloudflare keep copies of files on servers around the world.

The changes only appear once every layer between the server and the visitor has dropped its old copy.

How to Tell Which Cache Is the Problem

The fastest way to find which cache is serving the old WordPress page is to compare what you see while logged in with what a logged-out visitor sees. Most caching plugins and server caches skip logged-in users, so if your changes show while logged in but not in a private window, the page cache is the culprit.

Run these three quick checks before clearing anything:

• Private/incognito window. If the change shows here but not in your normal browser, it’s your browser cache.
• Logged in vs logged out. If you see the change while logged in but a private window shows the old version, it’s a page cache (plugin, host, or CDN).
• Content vs styling. If new text appears but a CSS change (colors, spacing, fonts) doesn’t, the problem is a cached or minified stylesheet, not the page itself.

The content-vs-styling check is the one most people skip, and it saves the most time. According to Cloudflare’s own documentation, the Cloudflare CDN does not cache HTML by default; it caches static files like CSS, JavaScript, and images based on file extension. So on a default Cloudflare setup, updated text usually appears quickly while an updated stylesheet can stay stale until the CDN cache is purged.

Symptom	Most likely cache	Fix
Change shows in private window only	Browser cache	Hard refresh (Ctrl+Shift+R / Cmd+Shift+R)
Change shows logged in, not logged out	Plugin or server page cache	Purge plugin cache, then host cache
Text updates, CSS doesn’t	Minified CSS, CDN, or page builder CSS files	Clear minify cache, regenerate CSS, purge CDN
Nothing changes anywhere, even logged in	Not a cache issue	Check you edited the right site, page, or file

Fix 1: Clear Your Browser Cache

A hard refresh forces the browser to download fresh copies of the page and its files instead of using stored ones. Press Ctrl+Shift+R on Windows or Linux, or Cmd+Shift+R on a Mac, in Chrome, Edge, or Firefox.

If a hard refresh doesn’t work, open Chrome DevTools (F12), right-click the reload button, and choose “Empty Cache and Hard Reload.” That clears cached files for the current site only, without wiping every saved login in the browser.

Browser cache is the right suspect when only you see the old version. If a client or friend on a different device also sees the old page, the cache is on the server side and clearing your browser won’t help.

Fix 2: Purge the WordPress Caching Plugin

Every major WordPress caching plugin has a one-click purge option, usually in the admin bar at the top of the dashboard. Clearing the plugin cache deletes the saved HTML copies so WordPress rebuilds each page fresh on the next visit.

• WP Rocket: admin bar > WP Rocket > Clear and preload cache.
• LiteSpeed Cache: admin bar > LiteSpeed icon > Purge All.
• W3 Total Cache: admin bar > Performance > Purge All Caches.
• WP Super Cache: admin bar > Delete Cache.

Pay attention to minification and file combining. Plugins like WP Rocket, LiteSpeed Cache, and Autoptimize generate their own combined CSS and JS files, and those files are sometimes cached separately from the pages. If a CSS change still doesn’t show after a full purge, look for a separate “clear minified files” or “purge CSS/JS” option, or temporarily turn minification off to confirm it’s the cause.

If you’re still choosing a caching plugin, the trade-offs between the big options are covered in WP Rocket vs W3 Total Cache.

Fix 3: Clear the Hosting Server Cache

Many WordPress hosts cache pages at the server level, completely separate from any plugin. If you purge your caching plugin and the old page still shows to logged-out visitors, the host’s own cache is the next layer to clear.

Managed WordPress hosts usually put a “Purge cache” or “Clear cache” button in the WordPress admin bar or in the hosting dashboard. On cPanel hosting running LiteSpeed, the LiteSpeed Cache plugin controls the server cache directly. If you can’t find the option, the host’s support team can clear it for you, and it’s worth asking them exactly what caching runs on your plan so you know for next time.

Object caching (Redis or Memcached) can also hold old data such as menus, widget settings, or theme options. If a menu or Customizer change won’t appear, flush the object cache from the host panel or the object cache plugin.

Fix 4: Purge the CDN Cache (Cloudflare)

If the site runs through Cloudflare or another CDN, purge the CDN cache after clearing the WordPress cache. In Cloudflare, go to Caching > Configuration > Purge Cache, and use “Custom Purge” for a single URL or stylesheet, or “Purge Everything” for site-wide changes.

Order matters here. Clear the WordPress plugin and server caches first, then the CDN, then your browser. If the CDN is purged first, it can immediately re-fetch and re-cache the old page from a WordPress cache that hasn’t been cleared yet.

Cloudflare’s “Development Mode” bypasses the Cloudflare cache temporarily, which is handy during a design session with lots of small CSS tweaks. The full Cloudflare setup for WordPress, including cache rules, is in how to set up Cloudflare for WordPress.

Fix 5: Regenerate Page Builder CSS

Page builders like Elementor save each page’s styles into separate CSS files, and those files can go stale after a theme update, a migration, or a global style change. When Elementor design changes don’t show on the live site, regenerating those CSS files usually fixes it.

In Elementor, go to Elementor > Tools > General and click “Regenerate Files & Data” (labelled “Regenerate CSS & Data” in some versions), then purge your caching plugin. Other builders and some themes have similar options; look for “regenerate CSS,” “clear CSS cache,” or “rebuild assets” in the builder or theme settings.

What If It’s Not a Cache Problem at All?

If WordPress changes don’t show even while logged in, in a private window, with every cache cleared, the change probably never reached the live page. The usual causes are editing the wrong site or page, editing a file the theme doesn’t load, or the change never saving.

• Wrong site. It’s surprisingly easy to edit a staging copy in one tab while checking the live site in another. Check the URL in the admin bar. Staging sites are the right place to test, as covered in the WordPress staging site guide, but changes there don’t appear live until you push them.
• Wrong page or template. A page set as the homepage under Settings > Reading, a reusable block, or a block theme template may control what you’re looking at, not the page you edited.
• Wrong file. CSS added to a parent theme file, while a child theme is active, may be overridden. Custom CSS added in Appearance > Customize > Additional CSS is safer for small tweaks.
• The save failed. If the editor showed an error when you clicked Update, the change was never saved. The common “updating failed, the response is not a valid JSON response” error is one example.

How to Stop This From Happening Every Time

The cleanest long-term fix for WordPress changes not showing is a caching setup that clears itself when content changes. Most modern caching plugins already purge a page automatically when that page is updated, so the real problems usually come from layers that don’t talk to each other.

• Use one page caching layer, not three. Running a caching plugin on top of a host’s server cache on top of a CDN HTML cache multiplies the places where an old copy can hide.
• If Cloudflare caches HTML on your site, connect it to WordPress with the official Cloudflare plugin or your caching plugin’s Cloudflare integration so purges happen automatically.
• Load custom CSS through a properly enqueued stylesheet with a version number, so browsers and CDNs see a new file URL whenever the version changes.
• During heavy design work, enable Cloudflare Development Mode or pause minification until you’re done.

Here’s what a versioned stylesheet looks like in a child theme’s functions.php. Changing the version string forces every cache to treat it as a new file:

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style(
        'custom-style',
        get_stylesheet_directory_uri() . '/custom.css',
        array(),
        '1.0.3' // bump this after every CSS change
    );
} );

The takeaway: when WordPress changes aren’t showing, don’t panic and don’t purge blindly. Test in a private window, compare logged in vs logged out, check whether it’s content or styling, and clear the caches in order from the server outward: plugin, host, CDN, then browser.

Frequently Asked Questions