You changed a phone number, swapped a banner or fixed a typo, pressed Update, saw the “Page updated” notice, and opened the site. The old version is still there. You try again. Same result. Then a colleague says they can see the new version, while your customer in another city still sees the old one.
There is rarely an error message with this problem, which is part of what makes it maddening. In nearly every case your change has been saved correctly. Something between the database and the screen is still handing out an older copy. The skill is in working out which copy, because a typical WordPress site has four or five places that can hold one.
Why websites keep old copies at all
Building a WordPress page from scratch means running PHP, querying the database and assembling HTML, CSS and JavaScript. Doing that for every single visitor is slow, so almost every layer of a modern site keeps ready-made copies. That is a good thing; it is what keeps sites fast. The side effect is that when you change something, each layer needs to notice or be told, and some of them are not.
Think of it as a stack, from the visitor’s screen back to your server:
- The visitor’s browser cache
- A CDN such as Cloudflare, if you use one
- Your host’s server cache (Varnish, Nginx, LiteSpeed and similar)
- A caching plugin inside WordPress
- Generated CSS and JavaScript files from your theme, page builder or optimisation plugin
- An object cache such as Redis, which stores database results
Work through them in that order and you will usually find the culprit without guessing. If what you are seeing is a real error rather than old content, start with our WordPress error fix guide instead.
First, two non-cache checks that save time
Before clearing anything, rule out the two mistakes that look exactly like a cache problem.
- Are you editing the page you are looking at? Sites often have near-duplicates: an old “Contact” page and a newer “Contact Us”, a draft copy, or a staging site with the same design. Open the live page, and from the admin bar at the top click Edit. That way you know for certain you are editing the page being shown, not a lookalike.
- Did the change actually publish? Look for a status of Scheduled or Draft, or a pending revision from a review plugin. In page builders, check you clicked Publish or Update in the builder itself, not just closed it.
Layer 1: your own browser
Browsers store images, stylesheets and scripts so they do not download them again. Text changes often show at once, while CSS changes, logos and images lag behind.
- Do a hard refresh: Ctrl+F5 or Ctrl+Shift+R on Windows and Linux, Cmd+Shift+R on a Mac.
- Open the page in a private or incognito window, which starts with an empty cache.
- Check the page on a phone with Wi-Fi switched off, so the request takes a different route to the site.
If the change appears in a private window but not your normal one, the site is fine and only your browser was out of date. Your visitors will mostly pick up the new version on their own as their copies expire, and returning customers can be told to refresh if the change is urgent, such as a new phone number or opening hours.
Layer 2: the CDN
A CDN keeps copies of your files on servers around the world. That is why a visitor abroad may see something different from you: they are being served by a different location’s copy.
In Cloudflare, you can purge everything or purge specific addresses from the Caching section, and Development Mode temporarily bypasses the cache while you work. Other CDNs have similar purge options. Many caching plugins can also purge the CDN for you when you update a page, but only if that connection has been set up.
Layer 3: the host’s server cache
Many hosts run their own page cache in front of WordPress. It is often invisible from inside the dashboard, apart from a “Purge cache” button in the admin bar or a section in the hosting control panel. If you have cleared your plugin cache and still see old content in a private window, this is the most likely layer.
A tell-tale sign is logged-in versus logged-out behaviour. Most caches skip logged-in users, so you see your change while signed in and visitors do not. If that matches what you see, a page cache (layer 3 or 4) is holding the old copy.
Layer 4: the caching plugin
WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache and similar plugins usually clear a page’s cache when it is updated. They do not always clear every page that shows the changed content. Edit your footer, a menu or a widget, and every page on the site displays it, but only the edited item’s cache may be cleared.
Use the plugin’s “clear all” or “purge all” option after site-wide changes. If you have more than one caching plugin active, which happens more than you would think, deactivate all but one. Two caching systems fighting each other is a common reason changes appear and disappear at random.
Layer 5: generated CSS and JavaScript
This is the one people miss. Page builders such as Elementor write your design settings into separate CSS files. Optimisation plugins combine and minify files into new bundles. Some themes generate a stylesheet from Customizer settings. If those files are not regenerated, your new colours, spacing or fonts do not appear, even though the HTML is new.
- In Elementor, Elementor > Tools lets you regenerate CSS and data files.
- In optimisation plugins, look for an option to clear minified or combined files.
- If you edit theme files directly, a browser may keep the old stylesheet until its version number changes.
If design changes stubbornly refuse to show in the Elementor editor too, our Elementor troubleshooting page covers the wider set of builder faults.
Layer 6: the object cache
Sites with Redis or Memcached keep database results in memory. Usually WordPress keeps that cache in step, but plugins that write to the database in unusual ways can leave stale values behind, for example a settings change that does not apply. Most object cache plugins have a “flush” button. If your host manages Redis, they may need to flush it.
Changes that are saved but overridden
Sometimes there is no cache involved at all; the change is live but something else wins.
- CSS specificity. A rule you added in Appearance > Customize > Additional CSS can be overridden by a more specific rule in the theme or a plugin.
- Parent theme vs child theme. Edits made to the parent theme’s files are lost when the theme updates, and edits to the wrong theme do nothing at all. Our guide to customising a WordPress theme explains why a child theme matters.
- Per-device settings. Page builders let you hide sections or change styles on mobile, tablet or desktop separately. A change made in desktop view may not reach phones.
- Translations and multilingual plugins. On a multilingual site, each language has its own copy of the page.
- Template parts. On block themes, headers and footers are template parts edited in the Site Editor, not in the page itself.
A routine that finds it quickly
- Confirm in the editor that the change is saved and published.
- Open the page in a private window. If it is correct, it was your browser.
- Clear the caching plugin, then check the private window again.
- Purge the host’s cache, then check.
- Purge the CDN, then check from another device on another network.
- Regenerate builder CSS and clear optimised files.
- If the new content is in the page source (right-click, View Page Source, search for your new text) but does not show, it is a CSS or override problem, not a cache.
One caution on shops: clearing caches is harmless, but do not respond to this problem by turning caching off on a store and leaving it off. Fix the layer that is misbehaving. On WooCommerce, if the problem is shoppers seeing stale carts rather than stale content, see our post on carts that empty themselves.
Preventing it
- Keep one page caching system, not several, and know where its purge button is.
- Connect your caching plugin to your CDN and host cache if it supports that, so updates purge every layer.
- After site-wide edits to menus, footers or global styles, purge everything once.
- Make design changes in one place, a child theme or the builder’s global settings, rather than scattering CSS across several.
Caching set up well is a large part of a fast site; our guide to speeding up WordPress explains how the layers fit together.
If the site still will not show your changes
When every cache is cleared and the old content persists, or the layout breaks after a purge, something in the configuration needs a closer look. Send us the page address and what you changed. We will check each layer, back up before changing settings, and tell you which one was holding the old copy. If the purge has left styles missing, our layout repair page explains how we handle that.
To understand which of those caches you actually have, read the types of website cache, explained.
Next in this series: WordPress Page Content Not Showing? Causes and Fixes
