Why Customers See an Old Version of Your Website After You Update It
You update a price, photograph or headline, publish the website and confirm the change on your own screen. Minutes later a customer sends a screenshot of the old version. That does not automatically mean the publish failed. Modern websites can be cached in several places, and clearing the wrong one only hides the evidence.
This guide uses a layer-by-layer test to identify where the stale version lives, fix it without creating unnecessary downtime, and prevent the same problem during the next release.
Start with a controlled four-view comparison
Open the exact affected URL—not merely the homepage—in these four conditions:
your normal browser;
a private or incognito window;
a second device using a different network, such as mobile data;
a browser with developer tools open and the network cache disabled.
Add a small, unmistakable marker to the update before testing, such as a revised sentence or a release code in an unobtrusive footer. Do not rely on memory or a tiny spacing change.
The result narrows the cause quickly. If only the normal browser is old, suspect its private cache or stored application data. If every device in one region or network is old, investigate a CDN, proxy or DNS path. If everyone sees the old HTML, verify publishing and the origin server before touching browser settings.
1. Confirm that the correct version was actually published
Website editors commonly separate saving, previewing and publishing. A change can exist in an editor session without becoming the live production version. Confirm the live domain, page URL and published environment. Also check whether you edited a duplicate page, language variant, product template, staging site or theme preview.
On Wix, test the published custom domain rather than an editor preview. On Shopify, confirm that the edited theme is the published theme. On WordPress, verify that the updated page is public and that a page builder did not save a revision or template separately from the page itself.
If a deployment pipeline is involved, compare its release identifier with the live response. A successful build does not prove a successful production deployment.
2. Determine whether the browser cache is serving the old response
Browsers store HTML, CSS, JavaScript, images and fonts to avoid downloading unchanged resources. This makes sites faster, but a long freshness lifetime or failed revalidation can keep an old file in use.
In Chrome DevTools, open Network, enable “Disable cache,” keep DevTools open and reload. Inspect the affected request. Look at the status, response headers, response body and whether the Size column says memory cache or disk cache. A hard reload is useful for diagnosis, but asking every customer to hard-refresh is not a release strategy.
MDN’s HTTP caching guide distinguishes private browser caches from shared and managed caches. It also clarifies a frequently misunderstood detail: no-cache allows storage but requires revalidation, whereas no-store prevents storage and does not delete an old response that already exists.
3. Check CDN and edge-cache behavior
A CDN can serve the current page from one edge location and an older copy from another. Compare response headers across networks and locations. Useful clues include Age, Cache-Control, ETag, Last-Modified and vendor-specific cache-status headers.
Purge only the affected URL or asset when your provider supports targeted invalidation. A site-wide purge can create a sudden origin-traffic spike and is rarely the best first action. After purging, test with a clean request and confirm the response content—not just a successful status code.
If HTML changes frequently, give it a revalidation-friendly policy. Static versioned assets can safely receive a long lifetime when their filenames change with their contents.
4. Look for a service worker or installed web app
A service worker can intercept requests and return files from its own Cache Storage, independently of the normal HTTP cache. That explains a frustrating pattern: the public website looks current in a private window, while an installed progressive web app or returning browser keeps the old interface.
In Chrome DevTools, inspect Application → Service Workers and Cache Storage. Confirm which worker controls the page, its script version and the cached responses it returns. Unregistering it on your device can confirm the diagnosis, but the real fix is a safe update strategy for all users.
Chrome’s service-worker lifecycle documentation explains that a new worker normally installs and waits until the old worker no longer controls clients. Design the update flow deliberately; forcing immediate activation without handling compatibility can break open sessions.
5. Purge WordPress and server-side caches in the right order
WordPress sites may have several caches at once: a page-cache plugin, host cache, object cache, reverse proxy and CDN. Purging one does not clear the others.
Use this order:
confirm the page content is updated in WordPress;
clear the relevant page-builder or page-cache entry;
purge the host or reverse-proxy cache for that URL;
purge the CDN edge copy if it remains stale;
test from a clean browser and a second network.
Avoid disabling every optimization plugin at once on a live site. That destroys the evidence and may introduce a new performance problem. Our website maintenance guide and WordPress recovery checklist cover safer change and rollback habits.
6. Distinguish stale HTML from stale CSS, JavaScript or images
If the new text appears but the layout or photograph remains old, the page document may be current while a referenced asset is stale. Open the asset URL directly and compare its response, dimensions or checksum.
The durable fix is cache busting: change an asset URL when its content changes. Build systems usually add a content hash such as app.a81c2f.js. For manually managed images, upload the new file with a distinct filename rather than repeatedly overwriting a file whose URL has a long cache lifetime.
Do not add random query parameters permanently to every asset. Versioning should be systematic so caches remain useful.
7. Investigate DNS only when the symptoms fit
DNS does not cache the page body, but it can send different visitors to different hosts. Suspect DNS when the domain, hosting provider, CDN or nameservers recently changed—or when some users reach a completely different site or certificate.
Compare DNS answers from multiple resolvers and confirm that every returned address points to an updated server. During migrations, keep the old origin serving compatible content until the previous DNS time-to-live has passed. If the correct HTML is served but one image is old, DNS is unlikely to be the cause.
A practical evidence table
Only one browser is old: browser cache, stored site data or service worker.
Incognito is current but the installed app is old: service worker or Cache Storage.
One network or region is old: CDN edge, proxy or DNS routing.
HTML is current but styling is old: cached CSS or JavaScript asset.
Everyone sees the old page: publish, origin, server cache or deployment issue.
Search results show old wording but the page is current: search recrawl/snippet timing, not necessarily visitor caching.
Prevent stale versions during future updates
Maintain a short release checklist: publish, verify the live domain, inspect response headers, test one clean browser, test one external network, submit a real form and record the release time. Use versioned asset filenames, targeted cache invalidation and sensible policies for frequently changing HTML.
Performance and freshness should work together. Disabling all caching makes repeat visits slower and increases server load. The goal is to cache stable assets aggressively while ensuring pages and changing data revalidate correctly. For related diagnostics, see Webcurry’s real-user performance guide and post-redesign recovery guide.
Fix the layer, not the screenshot
“Clear your cache” is useful only when evidence shows the customer’s browser owns the stale copy. A professional fix identifies the exact response, the cache that served it and the rule that allowed it to remain fresh.
If customers continue to receive inconsistent versions, ask Webcurry for a release and caching diagnosis. A short header and network trace usually tells a better story than repeated blind purges.
Comments