Your website · Updated October 23, 2026
Why do customers still see the old version of our website?
Updated October 23, 2026
Customers still see the old version of a website when a stored copy is shown instead of the new page: in their browser, on the website's server, or on a network like Cloudflare. Check the live site in a private window. If it is old there too, clear the site's cache. If it is new, the copy is theirs.
Look at the live site in a private window on your phone before you change anything
If a customer says they still see the old page, open your website in a private or incognito window on your phone, with Wi-Fi turned off. A private window starts without your browser's stored copies, and the phone's data connection takes you around your office network. What you see there is close to what a new visitor sees.
The result tells you which of two problems you have. If the private window shows the old version too, the website itself is still serving it, and the fix is on your side: the change was never published, or the site is handing out a stored copy. If the private window shows the new version, the website is fine and the old copy is sitting in the customer's browser or on the network between you.
Every web page passes through a chain of copies on its way to a visitor. MDN, the reference most web developers use, calls the copy in the browser a private cache, one "tied to a specific client" and not shared with anyone else. Hosts, caching plugins and networks like Cloudflare keep shared copies further up the chain. Each copy saves time, and each one can be out of date.
If the private window shows the old version too
Check the change was published, not just saved
If the new page shows when you are logged in to your website builder but not in the private window, look for a Publish or Update button that was never pressed. Website builders such as Wix, Squarespace and WordPress keep a draft you can see while logged in, and visitors see only what was published. Many also have a staging or preview copy at a different address, which is easy to mistake for the live site.
Check the address bar in the private window. It should be your real domain, not a preview address from the builder or the host. If your developer made the change, ask them for the date it went live, not the date it was finished.
Clear the website's own cache after every change
If the change is published and the private window still shows the old page, clear the cache on the website itself. On WordPress this is often a caching plugin. WordPress's own documentation says these plugins "will cache your WordPress posts and pages as static files" and that "these static files are then served to users, reducing the processing load on the server." A page edited after its static file was made keeps serving the old file until the cache is cleared or expires.
Look for a button named Clear cache, Purge cache or Delete cache in the plugin's settings or in the top bar of the WordPress dashboard. Many hosts add a cache of their own in the hosting control panel, so if the plugin's button does not fix it, look there too.
For example
A plumbing company changed its phone number and updated the footer on its WordPress site. The contact page showed the new number, but the home page and three service pages still showed the old one, and calls kept coming to a line nobody answered. The caching plugin had cleared only the page that was edited. Clearing the plugin's whole cache, then purging Cloudflare, put the new number on every page within minutes.
Why does the cache not clear itself when I save?
Many caching tools do clear the edited page on save. They often miss the other pages that show the same content, such as the home page, a menu, a footer or a list of services, because those pages were not the one you edited. That is why a new phone number can show on one page and not on the others. Clearing the whole cache once after a change like that is the reliable fix.
If the site runs through Cloudflare, purge its cache as well
If your domain uses Cloudflare or a similar network, it keeps its own copies of your pages close to your visitors, and those copies can outlast the change. Cloudflare's instructions are short: "In the Cloudflare dashboard, go to the Configuration page." Then "Under Purge Cache, select Purge Everything," and confirm in the warning window.
Read the warning before you confirm. Cloudflare says that on high-traffic sites with many assets, purging everything "can cause a large spike in origin requests and may significantly slow down your site or overload your origin server." A small business site rarely has that problem, but if yours is large, purge only the pages you changed.
Clear the website's own cache first and Cloudflare's second. If you clear Cloudflare first, it can fetch the old page from the website's cache and store it all over again.
If the private window shows the new version
Ask the customer to reload, or open the page in a private window
If you see the new page and a customer does not, their browser is most likely showing the copy it stored on an earlier visit. Ask them to reload the page, or open it in a private window. If that works, nothing on your website is broken.
If reloading does not help, they can clear the stored copies. Google's steps for Chrome on a computer: at the top right, select More, then Delete browsing data, choose a time range such as All time, tick the items to delete, and select Delete data. Most customers will not do this for a business website, which is why the lasting fix is the next topic.
Have your developer set how long browsers may keep each page
If customers keep seeing old pages after every update, the website is not telling browsers how long to keep its pages, or it is telling them too long. MDN explains that even with no instructions at all, a browser can reuse a page on its own judgment, which it calls heuristic caching: for a page that had not changed in a year, "the specification recommends about 10% (in this case 0.1 year) of the time after storing." That is a little over a month of reusing an old page with no one asking for it.
The instruction is a response header called Cache-Control. The fix most developers use has two parts:
- Pages: send them with no-cache, which MDN says "does not prevent the storing of responses but instead prevents the reuse of responses without revalidation." The browser keeps the page but checks with the site before showing it, which is fast and always current.
- Images, styles and scripts: keep them for a long time and change their file names when they change, which MDN calls cache busting: "a technique to make a response cacheable over a long period by changing the URL when the content changes." A new logo gets a new file name, so no browser can show the old one.
This is a setting in the hosting, the caching plugin or the site's code, not something an owner can change in a page editor. Ask your developer which of the two parts your site has.
If you just moved the site to a new host, give the DNS change time
If the website moved to a new host or a new builder in the last day or two, some customers can still reach the old one. Your domain's DNS records point visitors to the server, and every network caches those records for a set time. Cloudflare's documentation says each record's time to live (TTL) "controls how long each record is cached," and that "a longer TTL also means that updates to your records take longer to go into effect."
Keep the old site running until the move has settled. Do not cancel the old hosting the day the domain is pointed at the new one. Ask whoever manages the domain what TTL the records have, and wait at least that long, with a day to spare, before switching the old site off.
Cloudflare's default record TTL
300 s
is the TTL Cloudflare gives proxied records by default.
If the old version is on Google, or you need to see it
Ask Google to recrawl the page, then give it a few days
If customers see your old page title, description or prices in Google's search results, that is Google's copy, not your website's. Clearing any cache on your side does not change it. Google updates it the next time it crawls the page, and its documentation says "crawling can take anywhere from a few days to a few weeks."
To ask for a sooner visit, open the page in Search Console's URL Inspection tool and select Request indexing. Google notes "there's a quota for submitting individual URLs" and that "requesting a recrawl multiple times for the same URL won't get it crawled any faster," so request each changed page once and then wait. If the page itself is not on Google at all, that is a different problem with its own page: Website not showing up on Google.
How do I get an old page off Google for good?
If the old page should not exist at all, take it down or redirect it, then tell Google. Search Console's Removals tool hides a page from results quickly, but Google says "a successful request lasts only about six months." To remove it for good, Google says to "make sure that your web server returns either a 404 (Not Found) or 410 (Gone) HTTP status code," or mark the page noindex. If the old page has a new equivalent, a 301 redirect to it is better than either, because it keeps the visitors and links the old address had.
To view an older version of a website, look it up in the Wayback Machine
If you need to know exactly what customers were seeing, such as the old phone number, the old prices or a page you have since deleted, look the address up in the Internet Archive's Wayback Machine at web.archive.org. Its help center says to "enter a domain or URL the way you have in the past" and press Browse History, then pick a date with a blue dot on the calendar, which marks a successful capture.
Do not count on it holding every page. The Internet Archive says "not every date for every site archived is 100% complete," and some sites are missing because its crawlers did not know they existed. For a record of your own site you can rely on, keep a backup or ask your developer for the site's version history before every major change.