WordPress Changes Not Showing? Why Edits Disappear and How to Force a Refresh

When a WordPress edit does not show up after you save, the change almost always did save. What you are looking at is a cached copy from a layer between your database and your browser. There are usually five layers stacked on a modern WordPress site: browser cache, caching plugin, server-level page cache, CDN edge cache, and sometimes a service worker from a PWA plugin. Clearing them in the wrong order means you keep seeing old content even after you 'cleared everything'.

Editing a page in WordPress should feel instant. You hit Update, reload the front end, and the change is there. When it is not, the first reaction is usually to hit Update again, then again, then start questioning whether the editor is broken. The editor is fine. The save worked. Something between your database and your screen is showing you yesterday's copy.

This guide is the cache map I wish I had when I started doing WordPress maintenance. It covers every layer that can hide your edits, in the order they sit in the request path, and the right way to clear each one. By the end you should be able to push a change to a live site and see it within seconds, every time.

The Five Layers Between You and the Database

When a visitor loads a WordPress page, the response can be served from any of five places. From the database outward they are: object cache (Redis or Memcached), WordPress page cache (WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache), host-level page cache (Kinsta cache, WP Engine cache, SiteGround SuperCacher), CDN edge cache (Cloudflare, BunnyCDN, Fastly), and finally the browser cache or service worker on the visitor's device.

An edit you save in the WordPress admin updates the database. Every cache layer above it is still holding the old version until something invalidates it. Most caching plugins do invalidate on save, but only for the specific post URL, and only inside their own layer. They do not reach out and purge Cloudflare for you unless you explicitly connect the API.

Understanding this stack is the difference between guessing and fixing. If you know which layer is serving stale content, the fix is one click. If you do not, you end up clearing everything in random order and getting random results.

Step 1: Confirm the Edit Actually Saved

Before blaming caches, prove the database has the new content. Open the post in the editor, copy a unique phrase from the change, then open phpMyAdmin and run a SELECT on wp_posts WHERE post_content LIKE '%your phrase%'. If the row exists, the save worked. If it does not, you have an editor problem, not a cache problem, and that is a different ticket.

On classic editor sites, the autosave sometimes fights manual saves. Disable browser extensions like Grammarly and try again. On Gutenberg, a JavaScript error in a custom block can silently kill the save without showing an error. Open DevTools while clicking Update and watch the console.

SELECT ID, post_title, post_modified FROM wp_posts
WHERE post_content LIKE '%unique phrase from your edit%'
  AND post_status = 'publish';

Step 2: Inspect the Response Headers

Open the page in Chrome, open DevTools (F12), go to the Network tab, tick 'Disable cache', and reload. Click the first request (the HTML document) and look at the Response Headers section. The headers tell you which layer served the response.

Look for x-cache: HIT or MISS (generic CDN), cf-cache-status: HIT or MISS (Cloudflare), age: 3600 (how many seconds old the cached copy is), x-litespeed-cache: hit (LiteSpeed server cache), and x-cacheable: NON-CACHEABLE (WP Rocket excluding this page).

If you see HIT and an age over zero, the response came from a cache. The header name tells you which one. That is the layer you need to purge.

Step 3: Hard Reload the Browser

The fastest test is also the simplest. On Windows or Linux, press Ctrl+F5. On Mac, press Cmd+Shift+R. This forces the browser to ignore its own cache and re-fetch the page from the server. If the change appears, the browser cache was hiding it. If the change still does not appear, the cache is upstream.

Service workers from PWA plugins survive hard reloads. If you use a PWA plugin like SuperPWA or Progressive WP, open DevTools > Application > Service Workers and click Unregister. The next reload will fetch fresh content.

Step 4: Purge the Caching Plugin

Most WordPress caching plugins put a 'Clear Cache' button in the admin toolbar at the top of the screen. Click it. For WP Rocket, hover over the rocket icon and choose 'Clear and Preload Cache'. For W3 Total Cache, use Performance > Dashboard > empty all caches. For LiteSpeed Cache, use LiteSpeed Cache > Toolbox > Empty All Caches. For WP Super Cache, use Settings > WP Super Cache > Delete Cache.

If the plugin offers 'Purge URL' specifically, use that for the page you edited. Whole-site purges are slower and force every other page to rebuild from scratch, which can spike server load.

Step 5: Purge Host-Level Cache

Managed WordPress hosts run their own page cache outside WordPress. The caching plugin does not know about it. SiteGround uses SG Optimizer (which you can purge from the admin toolbar), Kinsta has a 'Clear Cache' button inside MyKinsta, WP Engine has 'Purge Cache' in the User Portal, and Cloudways uses Varnish with a 'Purge Cache' button in the application dashboard.

If you skip this step, the host cache re-serves the old page to the next visitor, and the cycle starts again. After purging the host cache, reload the page in a private window and check the response headers again. The age header should be near zero.

Step 6: Purge the CDN

Cloudflare and other CDNs cache HTML by default on many WordPress hosts. Purge the URL through the Cloudflare dashboard: Caching > Configuration > Purge Cache > Custom Purge > paste the URL. For BunnyCDN, use the Pull Zone > Purge Cache. For Fastly, use the API or the dashboard's Purge button.

If you edit content often, set a Cloudflare page rule that bypasses cache for the WordPress admin and for any URL pattern you edit frequently. The rule 'URL matches yoursite.com/blog/*' with 'Cache Level: Bypass' means blog edits show instantly without a manual purge.

Step 7: Flush the Object Cache

Object cache (Redis or Memcached) stores database query results, menu structures, widget output, and option values. Page-cache purges do not touch it. If your menu, sidebar, or a custom field is not updating even after every page cache is cleared, object cache is the culprit.

From WP-CLI, run wp cache flush. From the host control panel, look for a 'Flush Redis' or 'Restart Memcached' button. After flushing, the next page load rebuilds the cache from the current database, and your changes appear.

# From your site root over SSH
wp cache flush

# Or restart Redis directly
sudo systemctl restart redis

Step 8: Bust Static Asset Caches

CSS and JavaScript files are cached by filename. If you edit style.css and the filename did not change, the browser uses the old copy from disk and never asks the server for a new one. The standard fix is to append a version query string: wp_enqueue_style('child-style', get_stylesheet_uri(), [], '1.2.3'). The version 1.2.3 changes the URL just enough to force a fresh download.

Modern build tools (Vite, Webpack, Laravel Mix) handle this automatically by fingerprinting filenames. Each build produces a new filename like main.a8f3c2d1.css. The previous filename is still on disk but no page links to it, so the browser is forced to download the new file.

Step 9: Check for Stale Service Workers

If the site ever ran a PWA plugin, even one that has since been deactivated, a service worker can still be registered in visitors' browsers. The service worker intercepts every request and can serve cached responses from months ago. Open DevTools > Application > Service Workers. If a worker is listed, click Unregister, then reload.

On a public site you cannot reach every visitor's browser. If you removed a PWA plugin and people report stale content for days afterward, add a small JavaScript snippet to the page that explicitly unregisters any service worker on load. After a week or two the problem clears across your audience.

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.getRegistrations().then(rs => rs.forEach(r => r.unregister()));
}

A Real Example From a Client Site

A publisher I work with redesigned their footer. They updated the widget, saved, hard-reloaded, and saw the new footer. Two hours later readers were emailing in screenshots of the old footer. The cache layers had each picked up the new copy at different times, and the CDN was still holding the version from before the change.

The fix was four clicks in order. WP Rocket purge, SiteGround SuperCacher purge, Cloudflare purge everything, then a hard reload. Two minutes total. The lesson was less about the fix and more about the order. Doing it the other way (CDN first, then plugin) meant the CDN re-cached from the SiteGround cache, which still had the old version, and the cycle repeated.

Stop the Problem Recurring

After fixing the immediate stale content, take ten minutes to set up the site so it does not happen again. Connect your caching plugin to the Cloudflare API so saves automatically purge the CDN. Add the WordPress admin and the homepage to your cache exclude list. Schedule a nightly cron that purges page cache for any URLs modified in the last twenty-four hours.

Most caching plugins have an auto-purge feature buried in their settings. WP Rocket calls it 'Cache Lifespan'. LiteSpeed has 'Auto Purge Rules For Publish/Update'. Turn them on. The plugin then handles ninety percent of these tickets before they reach you.

• Connect caching plugin to Cloudflare API for auto-purge
• Exclude /wp-admin and /cart from every cache layer
• Set a short TTL (15 minutes) on the homepage if it changes often
• Bookmark a one-click 'purge current URL' tool in your browser
• Document the purge order in your team's runbook

Final Sanity Check

After every change, do a three-step test. Hard-reload in a private window. Open the URL on your phone over mobile data (not Wi-Fi, so the response comes from a different CDN node). Check the response headers in DevTools one more time. If all three show the new content, the change is live everywhere. If any of them disagree, you have one more cache layer to find, and now you know exactly which tools to use to find it.

1. 1Hard-reload the page with Ctrl+F5 on Windows or Cmd+Shift+R on Mac to bypass the browser cache.
2. 2Open the page in a private window, if it looks correct there the issue is local browser cache, not the server.
3. 3Clear your caching plugin (WP Rocket, W3 Total Cache, LiteSpeed, WP Super Cache) from the WordPress admin toolbar.
4. 4If your host has a server-level cache (SiteGround SuperCacher, Kinsta cache, WP Engine cache), purge it from the host control panel.
5. 5Purge the Cloudflare or other CDN cache for the specific URL, not the whole site.
6. 6If you use a PWA plugin, unregister the service worker by opening DevTools > Application > Service Workers > Unregister.