WordPress changes not showing on the live site is nearly always a delivery problem rather than a lost edit. Your text saved. What has gone wrong is everything that happens after the save: between the database where that text now sits and the screen where your visitor is looking, there can be six separate caches, and any one of them can still be handing out yesterday’s copy.
Most advice on this stops at “clear your cache”, which is why so many people clear the one cache they know about, see no change, and conclude the site is broken. This is the full chain, in the order it runs, with a way to work out which layer is holding you up.
First, confirm the edit actually saved
Two minutes here saves an hour of cache hunting.
Open the page in the WordPress editor again, from a fresh browser tab. If your text is there, it saved. If it is not, the problem is not caching at all and the rest of this article does not apply to you.
Three things commonly stop a save from landing:
- Your session expired mid-editWordPress logs you out after a period of inactivity. The editor stays open and looks normal, and the save silently fails. Look for a login prompt behind the editor window.
- You edited a different pageDuplicate drafts, a staging copy, or a page with a near-identical name. Check the URL in the address bar against the URL you are testing.
- You edited the wrong elementA template part, a reusable block, or a global widget that appears on some pages and not others. The change is live, just not where you are looking.
Open the live page in a private or incognito window. This is the single most useful test in this article. A private window carries no cookies, no browser cache and no login, so what you see there is very close to what a real visitor sees.
The two tests that narrow it down in a minute
Rather than clearing everything and hoping, these two checks tell you roughly where the stale copy is coming from.
The second test works because caches key their stored copies by the full URL. Adding ?v=123 to the end makes the address unfamiliar, so most caches treat it as a page they have never seen and fetch a fresh copy from WordPress.
If the new content appears with the query string but not without it, something between WordPress and the visitor is storing the old page. If the old content appears even with the query string, the problem sits deeper: an object cache, an OPcache holding compiled PHP, or a save that did not land.
Layer 1: your browser
The most common cause and the easiest to rule out. Browsers hold on to HTML, CSS, images and JavaScript so pages load faster on a second visit.
A normal refresh often reuses the cached files. A hard refresh forces a fresh request:
| Browser | Windows | Mac |
|---|---|---|
| Chrome, Edge, Brave | Ctrl + Shift + R | Cmd + Shift + R |
| Firefox | Ctrl + F5 | Cmd + Shift + R |
| Safari | — | Cmd + Option + E, then reload |
Mobile browsers are the usual culprit when a site looks updated on a laptop and old on a phone. Nobody clears their phone cache. On Chrome for Android, open Settings, then Privacy and security, then Delete browsing data, and pick cached images and files.
Layer 2: your login session
This one causes more confusion than any other, because the site appears correct to the person who made the change and wrong to everyone else.
Caching plugins usually bypass the cache for logged-in users on purpose, so editors always see live content. Your visitors are served the stored copy. If the page looks right when you are logged in and wrong in a private window, you have found the problem, and the fix is further down the chain rather than in your browser.
Layer 3: the page cache plugin
This is the layer most people mean when they say “the cache”. It stores a finished HTML copy of each page so WordPress does not have to rebuild it for every visitor.
Most plugins clear the relevant page automatically when you update a post. That automatic purge fails often enough to be worth checking by hand.
| Plugin | Where to purge | Worth knowing |
|---|---|---|
| LiteSpeed Cache | Admin bar, then LiteSpeed Cache, then Purge All | Common on Indian hosting. Also has a separate CSS and JS cache under Page Optimization that needs its own purge. |
| WP Rocket | Admin bar, then Clear cache | Also has Used CSS and preload caches. Use Clear and preload cache after a design change. |
| W3 Total Cache | Performance, then Purge All Caches | Has several sub-caches. The single Purge All is safer than clearing them one at a time. |
| WP Super Cache | Settings, then WP Super Cache, then Delete Cache | Simple, with fewer places for a stale copy to hide. |
| Autoptimize | Admin bar, then Autoptimize, then Delete Cache | Not a page cache. It combines CSS and JS, so it holds stale styling rather than stale content. |
Two page caching plugins installed at once. It usually happens when a host enables LiteSpeed by default and someone later installs WP Rocket. Each one caches the other’s output, purging one leaves the other stale, and pages stop updating in ways that look random. Pick one and deactivate the other.
What to do when the purge button does nothing
Sometimes the purge appears to run and the page still does not change. Three causes account for most of it.
The plugin may lack write access to its own cache folder. Check wp-content/cache exists and is writable. If the folder is missing or set to read-only after a migration, the plugin cannot delete what it cannot reach, and it will not tell you.
The purge may be running on a different site. If you manage several WordPress installs and have them open in separate tabs, it is easy to clear the cache on one while testing another. Check the site name in the admin bar before clicking.
A cache preload may be rebuilding the page immediately from a stale source. WP Rocket and LiteSpeed both offer preloading, which crawls your site after a purge to warm the cache back up. If the preload starts before your change has propagated, it stores the old version again within seconds. Turn preloading off while diagnosing.
Layer 4: your host’s server cache
Many Indian hosting plans run caching at the server level, above anything installed in WordPress. Your plugin has no ability to clear it and often no awareness it exists.
You will find it under names such as Object Cache, LiteSpeed Cache, Varnish or NGINX FastCGI Cache in the hosting panel. Hostinger, SiteGround, Cloudways, Rocket.net and most managed WordPress hosts include some form of it.
If clearing every plugin cache changes nothing and a query string does show the new page, this is very likely where the old copy lives. Open a support ticket and ask them to purge the server cache for your domain. Most will do it within minutes.
Layer 5: your CDN
A content delivery network keeps copies of your pages in data centres around the world. Cloudflare is the one most small businesses use, often without remembering it was ever set up.
- Purge everythingCloudflare dashboard, pick the domain, Caching, then Configuration, then Purge Everything. Fine for a small site.
- Purge a single URLSame screen, Custom Purge, paste the full address including https. Kinder to your load times than purging the lot.
- Turn on Development ModeUnder Caching, this bypasses the CDN cache for three hours. Switch it on while you work, and remember it expires on its own.
- Check APO if you use itAutomatic Platform Optimization caches full HTML at the edge. It needs the Cloudflare WordPress plugin installed and connected for purges to reach it.
Open your browser developer tools, go to the Network tab, reload the page and click the first request. Look at the response headers. A cf-cache-status of HIT means Cloudflare served a stored copy. A value of MISS or DYNAMIC means the request reached your server, so the stale page is coming from somewhere else.
Layer 6: builder and theme generated files
Elementor, Divi, Beaver Builder and most modern themes do not put your styling inside the page. They write it into generated CSS files and link to them. Clearing a page cache does not rebuild those files, so your layout change stays invisible while your text change appears correctly.
In Elementor, go to Elementor, then Tools, then Regenerate CSS and Data. Do that first, then clear the page cache, in that order. Reversing the order caches the old CSS again.
The same applies to Divi’s static CSS file generation and to theme customiser changes, which are often written to a cached stylesheet rather than applied live.
Reading the response headers, which settles most arguments
Developer tools tell you in seconds what an hour of guessing will not. Press F12, open the Network tab, reload the page, and click the very first request in the list. The Response Headers panel names the culprit.
| Header you see | What it means | Where to purge |
|---|---|---|
cf-cache-status: HIT | Cloudflare served a stored copy. Your server was never asked. | Cloudflare |
cf-cache-status: DYNAMIC | Cloudflare passed the request through. The stale copy is elsewhere. | Keep looking |
x-litespeed-cache: hit | LiteSpeed served it from cache, at server or plugin level. | LiteSpeed Cache |
x-cache: HIT | Varnish or a host proxy served a stored copy. | Ask your host |
age: 84000 | The stored copy is that many seconds old. A large number means nothing has purged in a long time. | Whichever cache set it |
| No cache headers at all | The request reached WordPress. The problem is the object cache, OPcache, or the edit itself. | Host panel |
Two minutes with this table will usually end a debate that has been running for a day.
The order to clear them in
Working from the visitor backwards means you stop as soon as the page is correct, rather than clearing everything and learning nothing.
- Regenerate builder CSSOnly if a layout or styling change is missing. Skip it for text edits.
- Purge the page cache pluginPurge All rather than a single page, at least while diagnosing.
- Purge the CDNCloudflare or whatever sits in front of the site.
- Ask the host to clear the server cacheOnly if the three above did not do it.
- Hard refresh your own browserThen check again in a private window, which is the only view that matters.
Plugins that help, and one that helps you diagnose
You do not need more plugins to fix this. One is genuinely useful while you are working out what is happening.
- Query Monitor, freeAdds a menu to the admin bar showing which caches are active, whether an object cache is running, how long the page took to build and which hooks fired. When a site will not update, this is the fastest way to see what is actually in play.
- Your host’s own cache pluginIf you are on LiteSpeed hosting, use LiteSpeed Cache rather than a third-party plugin. It can clear the server cache, which an unrelated plugin cannot.
- Cloudflare’s official pluginOnly if you use Cloudflare. It lets WordPress purge the edge cache automatically when you update a post, which removes this whole problem for most edits.
Caching is not the enemy. It is the reason your site loads quickly for real customers. The goal is not to switch it off, it is to know which layers exist on your site so you can clear the right one in ten seconds instead of guessing for an hour.
When the page still will not update
If you have worked through all six layers and the old content is still showing, the remaining causes are less common but easy to check.
- An object cache such as Redis or Memcached is running and holding the database query result. Flush it from your hosting panel, or from Query Monitor if it exposes the option.
- OPcache is holding compiled PHP. This affects code changes rather than content, and usually needs a PHP restart from the hosting panel.
- You are editing a staging site and viewing the live one, or the reverse. Compare the two domains carefully.
- A security or optimisation service such as Sucuri or a reverse proxy sits in front of the site with its own cache.
- DNS still points at old hosting after a migration, so you are editing one server and viewing another. This one is rare and deeply confusing when it happens.
That last case is worth ruling out early after any hosting change. If two people in the same office see different versions of the page, DNS is a likely explanation.
Stopping it becoming a weekly annoyance
Once you know your own stack, this stops being a mystery. Write down the answers to three questions and keep them with your site notes:
- Which page cache plugin is active, and does the host also cache at server level
- Is Cloudflare or another CDN in front of the site, and is its WordPress plugin connected
- Does the site use a page builder that generates its own CSS files
Three lines of documentation turn a recurring hour of frustration into a thirty second fix. Keeping that record current for every site we look after is part of ongoing website maintenance, and it is the reason a cache question rarely takes more than a few minutes to answer. If your site is new or was built by someone who has since moved on, our development team can map the stack and document it once, properly.
Parshant Hadala
Tarun Singla