You update a service page, replace a product photograph or correct a telephone number. The editor shows the change, but a customer still sees the old version. Refreshing your own screen seems to fix it, until somebody else reports the same problem.
Start by confirming that the right change reached the public website. Then establish which saved copy is outdated: the visitor’s browser, a website or hosting cache, or a content delivery network. Clearing one does not necessarily clear the others.
The aim is to make ordinary visitors receive the correct content without needing special instructions. Asking every customer to clear their cache is a workaround, not a dependable publishing process.
Confirm that the change is actually published
Copy the exact public address that the customer opened. Compare it with the address you edited, including the hostname, page path and any language or market variation. A preview link or staging copy can look convincing while showing a different website.
Reopen the saved item in your content management system. Check whether the revision is published, still a draft or scheduled for later. For a shared header, footer or reusable section, confirm that you saved the element which controls that public page.
WordPress’s guidance on changes not appearing includes checking the address and template as well as browser, server and plugin caching. That is a useful reminder to verify the source before repeatedly purging caches.
Choose one unmistakable part of the intended update to follow through your checks, such as the replacement photograph. Record the public URL, what should appear and when you published it. Avoid adding conspicuous test text to a live sales page.
If you discover that you have been editing a separate test website, resolve the deployment first. Our guide to keeping staging websites out of Google covers a related problem: test copies remaining publicly accessible.
Compare what different visitors receive
Before changing settings, compare the same public URL in your usual browser, a fresh private browsing session and another device. Keep the devices signed out of the website’s administration area.
These comparisons narrow the investigation; they do not identify a cache conclusively. A private session also changes cookies and login state. A different network may follow another delivery route.
| What you observe | What to investigate next |
|---|---|
| Your usual browser shows the old version; a fresh session shows the update. | Browser storage and differences in cookies or login state. |
| The editor looks correct, but signed-out visitors see the old page. | The published page, template and public caching route. |
| The wording updates, but a photograph or layout remains old. | The specific image, stylesheet or generated asset being requested. |
| Different devices or networks receive different versions. | URL variations, content personalisation and cache variants. |
For a more controlled browser test, a developer can open Chrome DevTools, select Network and enable Disable cache while DevTools remains open. Chrome’s Network reference documents this facility. It bypasses the browser’s HTTP cache for testing; it does not prove that the hosting server or CDN supplied a fresh response.
Afterwards, repeat the check with normal browser behaviour restored. A repair that only works during a developer’s diagnostic session is not ready for handover.
Identify the layers before clearing them
Ask whoever maintains the website for a short map of its caching setup. Name the actual systems in use and who controls each one. There may be a WordPress optimisation plugin, hosting-level page caching and a separate CDN, alongside the visitor’s browser.
For each layer, ask what it stores, what triggers an update and how to refresh the affected content. Also establish whether the outdated item is the page itself or a file that the page loads.
Cloudflare distinguishes edge caching from browser caching. Its documentation explicitly says that purging Cloudflare’s cache does not affect assets already stored in a visitor’s browser. A successful CDN purge therefore cannot, by itself, demonstrate that returning customers will see a replacement image.
Do not assume a CDN caches every part of the site. Under Cloudflare’s default behaviour, HTML and JSON are not cached. Additional rules or integrations may change that. Confirm the live configuration rather than blaming Cloudflare merely because the domain uses it.
Refresh the source before the downstream copy
A sensible investigation starts by confirming that the publishing system can serve the correct version. If a website or hosting cache still contains the old page, refreshing a downstream CDN first may simply allow it to fetch that old page again.
Have the maintainer refresh the relevant source-side cache, verify the response, then refresh any affected CDN copies. Check after each step so the eventual handover explains which layer caused the problem.
Purge the affected URLs, including their dependencies
For a single changed page, start with the smallest purge that covers the update. Include related locations where the changed material appears, such as a homepage feature, category listing or shared navigation component.
Cloudflare’s single-file purge documentation explains how to target a URL. It also highlights two easily missed boundaries: purging a redirect does not purge the content at its destination, and custom cache keys can require a different purge method.
Give the maintainer the final public destination and the precise asset URL where possible. If only one visitor group remains affected, ask whether device, country, language or cookie variations influence the cache key. Repeating the same purge without checking its scope may miss the same copy each time.
For a site-wide redesign, a broader purge may be justified. Agree its scope and timing with the host rather than repeatedly using “purge everything” while trying to discover the cause.
If text updates but images or styling remain old
Treat the page and its supporting files as separate requests. A newly published page can still ask the browser for an image or stylesheet at an unchanged address.
For example, replacing a photograph’s contents while keeping its filename may leave returning visitors using a previously stored copy. Equally, an image component may still point to an older resized version rather than the replacement you checked in the media library.
Ask the developer to inspect the actual file requested by the affected browser. Confirm its full URL, its contents and whether the public page references the intended version. For styling problems, include any generated or combined stylesheet used by the affected template.
MDN’s HTTP caching guide describes cache busting: give an updated static resource a new URL, commonly through a version or content hash. The page must then reference that new URL. An old cached page pointing to the previous file can otherwise keep the problem alive.
Use the site’s supported publishing or build process to manage this. Keep the customer-facing page address stable unless there is a separate reason to change it; renaming service pages is an unnecessary response to a stale stylesheet.
Ask for evidence of the cause and repair
A useful developer handover should connect the symptom to a specific response. Request the affected page or asset URL, the outdated content received, the responsible layer and the result after the repair.
Where relevant, include the response’s cache headers and the file version now referenced by the page. A screenshot of a saved cache setting is less useful than evidence of what a signed-out browser actually received.
Review the ongoing policy too. MDN’s Cache-Control reference distinguishes no-cache, which allows storage but requires validation before reuse, from no-store, which prevents storage. The names are not interchangeable. Neither should be applied across the whole website without considering the content and delivery setup.
Agree which material can remain cached for longer and which needs prompt validation or a reliable purge when published. A correction to contact details deserves an explicit freshness check.
Verify the next ordinary visit
Use a short acceptance check after the fix:
- Open the exact public URL while signed out, with normal browser caching enabled.
- Check both a fresh visitor and a browser that previously loaded the old content.
- Confirm the change on desktop and mobile, including the actual image or stylesheet involved.
- Follow the relevant enquiry, booking or purchase route to check the change in context.
- Return to the page again and confirm the correct version persists.
If the problem occurs specifically when using the browser’s Back button, record that separately. MDN notes that history navigation can restore a page without the usual revalidation; testing a normal navigation alone does not cover that symptom.
For the next update, make the process repeatable: publish, refresh the relevant caches through the supported integration, then check the public result. Assign responsibility for failures so routine content edits do not depend on somebody remembering several unrelated dashboard buttons.
If customers still see outdated pages or images, talk to BuzzBoost about tracing the publishing and caching route, repairing the cause and verifying the customer journey.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
