WordPress Changes Not Showing on the Live Website? How to Fix It

You edit a page. You click save. You open the live site. The old version is still there.

Don't re-edit the page yet. The edit is probably correct. The problem is that WordPress content passes through several layers before it reaches a visitor: the editor, the database, generated builder files, page cache, server cache, CDN, and browser cache. One of those layers is still serving the old copy.

The goal is to find which layer. Work through them in order. Don't clear everything at once and hope.

First Five Minutes: Triage the Stale Page

Don't read all ten sections first. Do this instead:

1. Open the page in a private window while logged out. If the new version appears, it's a browser cache problem.
2. If not, open the page source and check response headers for X-Cache, cf-cache-status, age, or x-litespeed-cache.
3. Clear the WordPress page cache. Test again.
4. Purge the hosting cache. Test again.
5. Purge the CDN. Test again.
6. Regenerate builder assets. Test again.
7. If the old version still shows, check whether you edited the right template and server.

That order solves most stale-content problems faster than clearing every cache at once.

1. Confirm the Change Was Published

Check the page status in the editor. Draft, Pending Review, Scheduled, and Private pages don't replace the live version. Look at the last-updated timestamp in the editor. If it doesn't match the moment you clicked save, the save didn't go through.

Open the public URL while logged out. The WordPress admin bar preview can show unsaved or private content that visitors can't see. If the logged-out version is old but the logged-in preview is new, the edit saved but isn't published.

2. Make Sure You Edited the Correct Content

The homepage might be a static page, a posts index, a block-theme template, or a builder template. Headers, footers, archives, and product pages can be controlled somewhere other than the page editor.

Check Settings → Reading to see whether the homepage is set to a static page or your latest posts. If it's a static page, edit that page directly. If it's a template, open Appearance → Editor → Templates and find the right one. For builder sites, check the template conditions in Elementor, Divi, or Bricks.

A client once spent an hour editing the homepage content block, only to find the header was coming from an Elementor Theme Builder template set to Entire Site. The page edit was fine. The header was controlled somewhere else.

3. Test the Browser Cache

Open the page in a private window or a different browser. A hard reload (Ctrl+Shift+R or Cmd+Shift+R) works too, but private browsing is a clearer test because it has no cache at all.

If the new version appears in the private window, the edit is live. Your normal browser is just holding an old copy. Clear the browser cache for the site.

Don't ask every visitor to clear their browser. If stale assets are a wider problem, fix the site's cache headers. Static assets like images, CSS, and JS should have long cache lifetimes with versioned filenames. HTML should have short lifetimes or no cache at all.

4. Clear the WordPress Page Cache

Use the purge function in your caching plugin. Purge the affected URL first if selective purging is available. Then purge the full page cache if the single URL doesn't fix it.

Here's how to purge in the common plugins:

• WP Rocket: Click Clear and preload cache in the admin bar, or go to Settings → WP Rocket → Cache and click Clear cache.
• LiteSpeed Cache: Go to LiteSpeed Cache → Toolbox and click Purge All. Or use the admin bar menu.
• W3 Total Cache: Go to Performance → Dashboard and click Empty All Caches.
• SiteGround Optimizer: Go to SG Optimizer → Caching and click Flush Cache.

From WP-CLI:

wp cache flush
wp rocket clean --confirm
wp litespeed-purge all

WordPress's caching documentation explains that page, browser, object, and server caches are different systems. Clearing one doesn't automatically clear the others.

5. Purge Hosting and CDN Caches

Many managed hosts cache pages outside WordPress. A CDN may keep another copy at the network edge. Purge those layers from the hosting dashboard and CDN account.

Check response headers to see which layer is serving the old version:

X-Cache: HIT
cf-cache-status: HIT
age: 3600
x-litespeed-cache: hit
x-rocket-cache: hit

If X-Cache or cf-cache-status says HIT, the CDN is serving a cached copy. Purge it:

• Cloudflare: Go to Caching → Configuration and click Purge Everything. For a single URL, use Custom Purge.
• Kinsta: Click Clear Cache in the MyKinsta dashboard.
• WP Engine: Click Purge Cache in the portal.
• SiteGround: Go to Site Tools → Speed → Caching and click Flush Cache.

If the problem returns often, review cache duration and automatic purge rules. Frequently updated pages need shorter lifetimes. Carts, accounts, and previews should generally avoid full-page caching.

6. Regenerate Page-Builder Files

Page builders create CSS and data files separately from the main page content. If the page content updates but the styling or layout doesn't, the builder's generated files are stale.

Use the builder's official tool:

• Elementor: Go to Elementor → Tools → Regenerate CSS & Data. Or run wp elementor flush-css from WP-CLI.
• Divi: Go to Divi → Theme Options → Builder → Advanced and click Clear next to Static CSS File Generation.
• Bricks: Go to Bricks → Settings → General and click Regenerate CSS files.

If one widget still shows old information, check whether it reads from a global template, custom field, query, or dynamic source rather than the text you edited.

7. Temporarily Disable CSS and JavaScript Optimization

Minification, file combination, delay, and unused-CSS tools can serve an older stylesheet or generate a broken file. On staging, disable these features individually and retest.

When you find the responsible setting, exclude the specific asset or adjust its configuration. Leaving every optimization disabled is rarely necessary. Fix the one conflict and move on.

8. Check Object Cache and PHP OPcache

Persistent object caches retain database results. PHP OPcache stores compiled PHP code. If a template change or plugin update isn't showing up, one of these layers may be holding the old version.

Purge the object cache from the WordPress admin or the hosting dashboard. From WP-CLI:

wp cache flush

For OPcache, ask the host to reset it if a PHP template change remains stale. Don't manually delete unknown cache files on a production server. That's a good way to break something else.

9. Confirm the Domain Reaches the Server You Edited

After a migration, staging launch, or DNS change, the domain may still reach an old server from some networks. Add a unique temporary change (like a visible text string) and compare the server or CDN response headers with the hosting details.

Verify DNS before editing both copies of the site. Otherwise, it becomes difficult to know which installation contains the correct version.

10. Investigate Permissions or Save Failures

If changes disappear immediately after saving, the save didn't go through. Check the browser console and look for REST API errors:

POST https://example.com/wp-json/wp/v2/pages/123 403 (Forbidden)
POST https://example.com/wp-json/wp/v2/pages/123 500 (Internal Server Error)

Check PHP logs, security rules, and file permissions. Database or API failures can prevent the update even when the editor briefly reports success.

Test with recent plugins disabled on staging. Check Tools → Site Health for blocked REST API requests.

What Actually Fixes Stale Content

When WordPress changes aren't showing, the edit is often correct but an older copy is being delivered. Clear caches in a deliberate order: browser, page cache, hosting, CDN, builder assets. Confirm that you edited the template and server responsible for the public URL.

Once the update appears, fix the purge rule or configuration that allowed the stale version to remain. Otherwise, the same problem comes back next week.