When WordPress says your edit is saved but the public site still shows last week’s content, you are usually looking at a cache layer (or at the wrong site/page). Work the layers in order. A private-window comparison and a query-string check can give useful clues before you purge caches one layer at a time.
Work this checklist in order. Prefer staging when you can reproduce the stale view there. Take a backup before changing cache plugins or host CDN rules on production. This article is about content that does not update after a successful save. If stylesheets fail to load (broken layout, missing CSS file), use CSS not loading. For Admin security-check errors, follow our “Are you sure you want to do this?” checklist. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix. We confirm the scope before work begins.
Define what failed
- Confirm the editor or builder shows the new content saved, and note the public URL you expect to change.
- Compare a private/incognito window (logged out) with your normal browser (may still be logged in). Logged-in and logged-out views often hit different caches.
- If the whole site is offline or returns errors, use site down first.
- If only CSS/layout is broken while the HTML text looks current, start with CSS not loading.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| Both views logged out; private window current, normal browser stale | Browser cache or browser-specific state | Hard refresh or clear site data for this domain; retest logged out |
Both browsers stale; adding ?v=test1 shows the update | A cached response may differ by URL | Purge that URL at the page-cache plugin or CDN; retest without the query |
| Query string still stale everywhere | Wrong site, wrong page, or deeper cache | Confirm the live URL; continue page, host, and CDN checks before object cache |
| Logged-in sees new; logged-out sees old (or the reverse) | Separate caches by auth | Purge logged-out (and logged-in if your stack caches it); retest both |
| HTML text updates; CSS/layout still old or broken | Asset / CSS path | CSS not loading checklist |
Safe diagnostic order
- Confirm you edited the live site and the right page. Open the public URL from Admin’s View link. Check you are not on staging, a preview domain, or a duplicate page. Builders and the Customizer can edit a different template or a child-theme file than the one the front end uses. Fix the wrong-target case before chasing cache.
- Compare the same logged-out view. Open the public URL in a private window without signing in. Compare it with the same URL while signed out in your normal browser. If only the normal browser is stale, hard-refresh it and clear this site’s browser cache if needed. A difference between signed-in and signed-out views can come from separate server caches or personalized content, so it does not prove browser cache is the cause.
- Try a query-string check. Add a unique query such as
?v=test1 to the public URL. If the URL already contains a question mark, add &v=test1 instead. If the test URL is current while the normal URL is stale, a cached response is worth investigating, but this test does not identify the exact cache layer. Some caches ignore query strings, so unchanged content does not rule out page or CDN caching. Continue the same purge checklist.
- Purge the page-cache plugin. In your caching plugin, purge the single URL or “purge all” on staging first when you can. Retest the clean URL logged out. Restore any temporary settings after the test.
- Ask the host about server or managed cache. LiteSpeed, nginx FastCGI, Varnish, and managed WordPress hosts often cache HTML outside the plugin. Ask them to purge the URL (or confirm how you should) and whether logged-out pages are cached. Retest the clean URL after their purge.
- Purge the CDN if you use one. In Cloudflare or another CDN, purge that URL or the cache for the hostname using their documented control. Retest logged out on the clean URL. Keep durable CDN rules that correctly bypass or short-cache HTML if the host already set them; only change rules with host or CDN guidance.
- Check object cache when HTML still lags after HTML purges. Persistent object cache (Redis/Memcached) can keep old post or option data. Ask your host whether object cache is on and how to flush it safely. Retest the page after a flush they approve.
- Retest logged-in and logged-out. Confirm the public URL shows the update in a private window and, if you care about the logged-in view, while signed in. Keep the purge or exclusion that fixed the problem. Restore any security or cache plugins changed only for testing.
Common causes
- Browser cache still holding the old page.
- Page-cache plugin or host/CDN HTML cache serving a stored copy to logged-out visitors.
- Editing staging, a duplicate page, or a builder/Customizer surface that is not what the public URL renders.
- Logged-in and logged-out caches out of sync.
- Object cache retaining old post content after HTML was purged.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help on one WordPress site where saved edits do not appear on a specific public URL: confirming the live page, running private-window and query-string checks, coordinating host or CDN purges, and verifying logged-out (and logged-in if needed) views update. Paste the public URL, what you changed, and whether a private window differs. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full redesigns, new CDN architectures, multi-site fleets, and stylesheet-failure diagnosis are outside this offer. Use CSS not loading when assets fail, and are you sure you want to do this for Admin security-check failures.
Related checks
If private-window, query-string, plugin, host, CDN, and object-cache checks still leave the old content, send your host the public URL, the time of the edit, whether ?v= differed from the clean URL, and logged-in versus logged-out results. Suspected compromise needs a security investigation as well as clearing stale caches.