Why changes to your website are not showing up

You updated your website, but when you load it, the old version is still there. Or you see the change, and a customer does not. This is almost never a failed update. It is caching: copies of your pages stored in several places between your server and a visitor’s screen, each of which may hold on to the old version for a while. This guide walks through those layers so you can find the one responsible.

Why caching exists

Fetching a fresh copy of every file for every visitor would be slow and expensive. So copies are kept: in the browser, on a content network, in the server’s software, and sometimes inside the site itself. Caching is the reason big sites are fast. The price is that a change can take time to appear everywhere.

The layers, from nearest the visitor to nearest the server

  1. The browser. Browsers store images, styles and scripts, and sometimes whole pages, for hours or days. Try a hard refresh (Ctrl+F5, or Cmd+Shift+R on a Mac), or open the page in a private window. If the new version appears there, your normal browser is holding an old copy. See how to clear cache and cookies.
  2. A device or network. Phones, some work networks and mobile carriers also keep copies. Testing on mobile data, away from your usual network, helps rule this in or out.
  3. A content delivery network. If your site uses one, copies live at locations around the world and are refreshed according to rules you set. Most have a “purge” or “clear cache” button, and some let you purge a single page. See what is a CDN.
  4. Your site’s caching plugin or server cache. Many platforms save finished pages so they do not rebuild them for each visit. Clear it after any significant change, and check whether more than one layer is configured, since a plugin and the host may each keep their own.
  5. Your own files. Check that you changed the file that is actually live. Editing a copy, a staging site or the wrong folder is a surprisingly common reason a change “does not work”.

When it is DNS, not caching

If you changed hosting, moved a domain or edited address records, some visitors may still be sent to the old server for a while, because DNS answers are also cached, for as long as the record’s time-to-live allows. This is why some people see the new site and others the old one for a day or so. Read DNS propagation and use our DNS lookup to see what address the name returns now. To make future moves smoother, lower the time-to-live a day or two before the change.

How to find the layer holding the old version

  • Private window, same computer: new version means a browser cache.
  • Different device on mobile data: new version means your own network or device was the cause.
  • The server’s address directly, or a staging address: new version there but not on the live address points to the CDN or the page cache.
  • Response headers. Look at the cache-related headers a page returns. Our HTTP header checker shows them, including how long a copy may be kept and whether a CDN served it.

Stopping it happening again

  • Version your files. Adding a changing number to style and script file names, such as style.css?v=12, makes browsers fetch the new file immediately. Many build tools do this automatically.
  • Choose sensible cache lifetimes. Long lifetimes for files that rarely change, such as images, and short ones for pages that change often.
  • Purge as part of publishing. Make clearing the caches a routine step of every release, not an afterthought.
  • Test after each change from a clean browser and, for important changes, from another network. A monitor with a keyword check can confirm that the new text is live.

Remember that your visitors may not do a hard refresh. If you change something urgent, such as a price or a notice, purge the layers you control and test it rather than assuming everyone sees what you see.

Check a website now

Is it down for everyone, or just you? Paste an address and we test it from fifteen places.

Open the checker

Related guides

Last updated 2 November 2026. Written by the siteupdown.com team. Spotted a mistake?

← All help guides