If your WordPress edits aren’t visible after publishing, an older stored copy is usually being served. However, the edit might also be unpublished, saved to another page, or hidden by a template.
Check your published changes on the live website. Start with low-risk checks, then work through WordPress, hosting and CDN cache layers separately. This helps you find the cause without disrupting a small business website or your clients’ enquiries.
Key takeaways
- Test the public URL in a private window before changing settings.
- Clear WordPress, hosting and CDN caches separately, reloading after each step.
- Confirm the correct page is published before investigating plugins or theme files.
- Back up files and the database before deactivating tools or changing code.
1. Start with your browser
Test a private window and hard reload
Open the live page in an incognito window or private window, rather than using the editor’s preview. This starts a separate browsing session and helps isolate the browser cache.
If the update appears there, your usual browser session is probably responsible. However, private browsing doesn’t bypass a cache on your server or CDN.
Next, try a hard reload. In Chrome on Windows, use Ctrl+F5 or Ctrl+Shift+R. On a Mac, use Cmd+Shift+R. Cmd+R performs a normal reload, so it isn’t the equivalent hard-refresh shortcut.
Clear cached images and files
In Chrome, open Settings, then Privacy and security, then Delete browsing data. To clear browsing data for this test, select Cached images and files, choose a suitable time range, and clear them.
You don’t need to delete browsing history, saved passwords or cookies for this test. Leaving cookies untouched also avoids unnecessary sign-outs.
Reload the public page afterwards. If another browser still shows the old version, continue to WordPress caching.
2. Clear the WordPress cache plugin
A WordPress caching plugin creates a page cache of ready-made pages, so WordPress doesn’t rebuild them for every visitor. Your edit can save correctly whilst visitors receive yesterday’s copy.
In the WordPress dashboard, open Plugins > Installed Plugins to identify your cache plugin.
With WP Rocket, use the top-toolbar option to clear cache, then preload the pages. You can also do this through Settings > WP Rocket, as described in WP Rocket’s cache-clearing instructions. Preloading rebuilds cached pages after removal.
Other cache plugins provide similar controls. For example, WP Super Cache has a Delete Cache option in its settings.
After purging, reload the exact public URL in a private window. Also inspect the homepage or blog listing if it displays the edited content.
Logged-in administrators often bypass page caching, so the dashboard view alone doesn’t prove that visitors see the update.
3. Clear hosting and CDN caches separately
Purge the hosting cache
Web hosting can add a separate server cache outside your WordPress plugin. SiteGround, for example, provides caching controls through its hosting tools and WordPress integration.
Open the hosting dashboard and find its purge control. Clear the affected page where supported, then test again.
A plugin’s purge button doesn’t necessarily reach the hosting layer unless the systems are integrated. Our managed WordPress hosting comparison explains the wider division between hosting features and support responsibilities.
Purge Cloudflare when relevant
Its cache is separate, but Cloudflare doesn’t cache HTML by default. HTML caching can apply when features such as Automatic Platform Optimization or custom cache rules are enabled.
If your setup stores pages, purge the affected URL through its controls. If only an image or stylesheet remains outdated, purge that asset instead.
Clear the WordPress and hosting layers first. Otherwise, Cloudflare can fetch another stale copy from the server.
4. Confirm the correct page was published
Check status, address and environment
If cache clearing changes nothing, return to the editor. Make sure the page says Published, rather than Draft, Pending or Scheduled. Then save the latest edit using the editor’s publish or update control.
Compare its permalink with the address you’re visiting. Similar page titles can hide different URLs.
Also confirm you’re editing the production website, not a staging copy or another site in a multisite network. After a recent migration, an old hosting account may still contain a working dashboard.
For campaign pages, follow the actual links used in email marketing and social media. They might point to an older landing page.
Check homepage and template settings
Under Settings > Reading, inspect the selected homepage and posts page. WordPress’s Reading settings documentation also explains the Blog pages show at most setting.
A new article may fall outside the displayed posts, especially where sticky posts or custom queries affect ordering. A builder’s post grid can have its own limit.
If page text changes but the header doesn’t, inspect the template or template part. Global elements often live outside the page editor.
5. Isolate plugin, builder and theme problems safely
Back up before testing conflicts
Before deactivating plugins or editing files, back up both the database and WordPress files. Keep a copy outside the live hosting account.
Use a private WordPress staging site for disruptive tests. Block customer emails, live payments and outgoing automation on the clone.
If purging doesn’t help, temporarily deactivate the cache plugin there and retest. Clear any remaining hosting or CDN cache so it doesn’t mask the result.
Then isolate other likely plugins individually. Change one thing at a time and record whether the missing update appears.
Investigate generated files and theme code
If content updates but the web design remains unchanged, regenerate the page builder’s CSS or generated assets. Then purge the relevant caches again. This can resolve old colours, fonts and other digital branding elements.
For custom web development, confirm the active theme, template path and local file before deploying changes.
Don’t delete the live theme as a general troubleshooting step. Back up affected files and deploy replacements through a controlled process. Remove obsolete files only where the deployment requires it.
Persistent object caches, such as Redis, may also need investigation when database-backed content stays outdated.
6. Read response headers to find the stale layer
For a more precise diagnosis, open Chrome’s Developer Tools, select Network, then reload the public page. Select the main document request and inspect its response headers.
These headers provide useful clues.
| Header or value | What it tells you |
|---|---|
Age | The cached response’s age in seconds. |
cf-cache-status: HIT | The CDN served its cached copy. |
cf-cache-status: DYNAMIC | The CDN didn’t serve the HTML from its cache. |
If the Age value exceeds the seconds since you saved, the response likely predates your edit. An absent Age header doesn’t prove the response is uncached.
Cloudflare’s cache response documentation explains its status values. DYNAMIC still allows an upstream hosting cache to serve stale HTML.
Varnish usually retains a page until its configured lifetime expires or an invalidation, such as an authorised PURGE request, removes it. With grace mode, it can serve an expired page whilst fetching a replacement. The first visitor after expiry may therefore receive older content.
Send support the URL, save time, headers and purge steps you’ve already tried.
7. Prevent stale pages after future edits
Configure cache invalidation when content is saved, including related homepages and archives. Purging only after plugin or WordPress core updates leaves everyday edits uncovered.
Automatic purging needs to reach every layer that stores the page. A successful plugin purge doesn’t prove the hosting cache was cleared.
Choose one primary page-cache system and define how it works with the host and CDN. Browser caching stores reusable assets; object caching stores database results. Avoid stacking overlapping tools without a clear purpose.
Exclude personalised areas, baskets, checkout and dynamic booking screens from inappropriate page caching. Then test as a logged-out visitor on desktop and mobile, including forms and confirmation emails. Confirm that mobile-responsive layouts still work.
Make this part of routine website care and maintenance. Reliable publishing supports SEO and conversion optimisation because visitors need current information.
Agencies also need clear ownership of deployment and cache purging. See how we collaborate with creative agencies when you need technical delivery and hosting support.
Frequently asked questions
Why is WordPress not saving my changes?
Reopen the editor and inspect the saved content. If your edit has disappeared there too, caching is less likely to explain it.
Look for a failed-update message, an expired login or insufficient editing permissions. Copy unsaved text somewhere safe before refreshing. A plugin conflict or server error can also interrupt saving, which requires separate investigation.
Does adding ?nocache=1 bypass caching?
It can, but only when the cache configuration treats that query string as a bypass or separate request. Append ?nocache=1 to a URL without an existing query string; use &nocache=1 when one already exists.
Some systems ignore query strings, so this test doesn’t guarantee fresh content. If it shows your edit, the normal URL may still serve an outdated copy. Purge that copy rather than sharing the diagnostic URL.
Make the live page the final check
Work through the browser, WordPress, hosting and CDN storage layers in order. If the update still doesn’t appear, inspect publishing settings, templates and server responses before changing code.
The final test is the public visitor experience. Confirm the edit, test the enquiry route, and make content-save purging part of your publishing process.
