Why Your Website Changes Are Not Showing Up

Your website is not one website. It is several copies of the same pages, sitting on machines you mostly do not own, and when you edit a page you change exactly one of them. Every other copy carries on handing out the old version until something tells it to stop.

That is not a fault. It is how the web is built to be quick. But nobody explains it to the person who has just changed their prices, so the first time it happens it feels like the site is broken.

A pattern we see often enough to describe it: a dog grooming studio in Monaghan puts new prices live on a Tuesday morning, refreshes the page, sees the new figures, gets on with the day. The calls that week keep coming in at the old rate. One customer is reading a page their phone stored a fortnight ago. Another is quoting what Google still shows. A third is working off a link somebody dropped into a family WhatsApp group in the spring. The owner did nothing wrong. The change had not travelled.

So before you ring anyone about a website that "did not save", work out which copy you are actually looking at.

The copy on your own machine is the least trustworthy one

Your browser keeps a private copy of pages you have already visited. Mozilla's HTTP caching documentation is blunt about what that means: as long as a stored response is still fresh, "it will be used to fulfil client requests" ^[1]. The browser does not ring the server to check first. It serves what it already has, for as long as the instructions it was given say that copy is good.

Now consider who has visited your website more than any other person alive. You have. Which makes you the worst-placed person in the country to verify it.

There is a second trap sitting on top of that one. When you are logged into WordPress, most caching set-ups deliberately bypass the cache for you, because someone editing a page needs live data. The version you admire after hitting Update is a version almost none of your visitors will be handed. You are not looking at your website. You are looking at a private preview of it.

Two habits close this off for good: verify in a private window while signed out, then verify again on a phone using mobile data rather than the office wifi, because that is much closer to how a customer actually arrives.

The copy your server hands out

Behind the browser sits the page cache. On a properly built WordPress stack, Nginx stores the finished HTML of a page and hands that stored file to the next visitor instead of rebuilding it from the database. Nginx's own documentation lays out the mechanics plainly: fastcgi_cache_valid sets how long a response is kept, and fastcgi_cache_purge is what removes an entry on demand ^[2].

Why put up with the complication? Because rebuilding every page from scratch for every visitor is what makes a site stall when fifteen people arrive at the same minute. The stored copy is the reason a page appears before a customer decides they cannot be bothered waiting. Caching is the single biggest lever most business sites have on load time, which is why it sits at the centre of our full performance guide for business owners.

The catch is the purge. Update a page and a well-configured stack clears that page. What it does not always clear is everything else that quoted the page: the panel on the home page listing your services, the archive page, the block in the footer showing your hours. Those are separate stored objects with their own timers. They can sit there being accurate as of last Thursday, telling people something you no longer do.

This is the layer where managed and unmanaged hosting genuinely part company. If your page cache is a plugin somebody configured once and nobody has looked at since, the purge is your problem to diagnose. Web60 runs WordPress on Nginx with FastCGI page caching and Redis object caching as part of the platform rather than as something you assemble yourself, with an Irish support team you can ring when a page will not shift.

Each layer keeps its own copy of the same page, with its own timer.

The copy Google is showing

Google's copy of your page was taken whenever it last crawled you, and it does not refresh because you pressed Update. Search Console says this out loud. The default URL Inspection report "is not a live test", and the results shown "are from most recently indexed version of a page, not the live version on the web" ^[3]. Beside it sits a Test live URL button, and the difference between those two results is the honest answer to whether your change is out in the world yet.

How long is the wait? Google's documentation on asking for a recrawl puts it at "anywhere from a few days to a few weeks", notes that requesting a crawl "does not guarantee that inclusion in search results will happen instantly or even at all", and adds that there is a quota on submissions, so pushing the button repeatedly on the same URL achieves nothing ^[4].

For a business, that means your search result can advertise last year's price to somebody who has not clicked through yet. You cannot make Google hurry. What you can do is know it is happening, so the mismatch is something you manage at the counter rather than something that ambushes you. If you have never looked, Search Console is the free tool that shows you where you actually stand on Google, including which version of the page it holds.

The copy that turns up in group chats

Share your website link into WhatsApp, Facebook or LinkedIn and the platform builds a preview card: image, headline, description. It then keeps that card. Meta's own guidance for webmasters is specific on the point, stating that images "are cached based on the URL and won't be updated unless the URL changes" ^[5]. Meta publishes no promise about how long the rest of it lasts either, which is your answer about waiting it out: do not.

The tool that fixes it is Meta's Sharing Debugger, which triggers a fresh scrape of the page when you run the URL through it. LinkedIn has an equivalent. Run the page through both after any change to your headline or main image, and do it before you share the link anywhere, not after. The mechanics of those preview cards, and why they sometimes come back blank, are covered in more depth in our piece on broken link previews.

The practical stake here is quiet but real. A recommendation in a local WhatsApp group is one of the highest-trust arrivals a small business gets. It is worth the ninety seconds to make sure the card that lands there is showing this year's work.

The copy that is not on your website at all

Then there is the one that catches most local firms out completely, because it is not a copy of your website. It is a copy of your business.

Your opening hours in the Google Maps panel, your phone number in the local results, the "temporarily closed" flag: none of that comes from your site. It comes from your Google Business Profile, edited in a different place entirely. Google's help documentation states that edits "usually take up to 10 minutes to review, but sometimes it can take up to 30 days", and that pending changes are displayed on your profile while the review runs ^[6].

Update your website's contact page and your profile keeps whatever it had. A customer checking their phone on the way to you sees the profile, not the page. They drive over, find the door shut, and the review they leave is about you, not about a caching layer.

Verification is the step most content changes skip.

The honest part

Caching is not the villain in this story. It is the reason your site holds up when a post does well and forty people land on the same page at once. Strip it out and you would trade one confusing afternoon for a permanently slower website, which is a bad trade in any month.

There is also a real limit on what any of this buys you. You can purge a page cache in seconds. You cannot purge Google's index, you cannot reach into a customer's phone, and you cannot make a WhatsApp thread from March forget what it stored. Some copies you clear. Some copies you can only ask, and then wait. Knowing which is which is most of the skill.

And to be fair about the alternatives: the closed platforms do handle one part of this better. On Wix or Squarespace you press publish and the change is live, because one company owns the entire chain from editor to server and does not have to coordinate anything. If your site is five pages that change twice a year and you never want to think about a purge, that simplicity is a genuine benefit and it would be dishonest to pretend otherwise. The cost is everything else you give up to get it, which is a longer conversation and a different article.

How to verify a change actually landed

The fix for all of this is not technical. It is a two-minute habit at the end of any change that touches money, hours or contact details.

Open the page in a private window while signed out of WordPress. This is the version a stranger gets.
Open it again on a phone using mobile data, not your own wifi. Different device, different network, different stored copy.
If the change matters to search, run the URL through Search Console and compare the indexed version against Test live URL.
If you changed a headline or the main image, run the URL through Meta's Sharing Debugger before you share it anywhere.
If you changed hours, phone number or address, edit your Google Business Profile as a separate job. It will not inherit anything from the site.

I will admit where I learned to insist on step one. We pushed a customer-facing change during a maintenance window a good while back, purged the page cache, verified it on my own machine and signed the job off. My machine had the new page because I was logged in. Everyone else was served the old one for another hour. We verify signed out, on a second device, every time now.

Conclusion

Published is not the same as delivered. A price change is a deployment, and every deployment deserves the thirty seconds of verification that tells you it reached the people it was meant for.

If you would rather the caching layer was somebody else's job to worry about, a Web60 site is built and running in about a minute, on a stack where that part is managed for you. Either way, the next time a customer quotes a figure you retired last week, you will know exactly which copy they were reading and what to do about it.

Frequently Asked Questions

Why can I see my website changes but my customers cannot?

Two reasons, usually at once. Your browser holds a private copy of pages you have already visited and keeps serving it until that copy expires. On top of that, most WordPress caching set-ups deliberately bypass the cache for logged-in editors so you always see live data. The version you are looking at after hitting Update is therefore a version most visitors are not being served. Verify in a private window while signed out, and again on a phone using mobile data.

How long does it take for Google to show my updated page?

Google's documentation on requesting a recrawl says crawling can take anywhere from a few days to a few weeks, and that requesting a crawl does not guarantee inclusion at all. You can submit a URL through the URL Inspection tool in Search Console, but there is a quota on submissions and requesting the same URL repeatedly will not make it happen faster. Until Google recrawls, your search result can still show the old information.

Why does my link preview still show the old image when I share it?

Social platforms store their own copy of your page's preview data. Meta's sharing documentation states that images are cached based on the URL and will not be updated unless the URL changes. Running the page through Meta's Sharing Debugger triggers a fresh scrape, which is the practical way to force the preview to catch up. LinkedIn offers an equivalent inspector tool.

Does clearing my browser cache fix it for everyone?

No. Clearing your browser cache only affects the copy on your own device. It does nothing to the copy stored on the server, the copy held by a social platform, the copy in Google's index, or the copy on a customer's phone. Clearing your own cache is a diagnostic step rather than a fix. It tells you whether the problem is local to you or further up the chain.

Why do my new opening hours still show wrong on Google Maps?

Because that information does not come from your website. It comes from your Google Business Profile, which is edited separately. Google's help documentation says edits usually take up to 10 minutes to review but can take up to 30 days, and pending changes are shown on your profile while the review runs. Updating your website does not update your profile, so both need changing whenever your hours, phone number or address change.

If caching causes all this, should I turn it off?

For almost every business site, no. Caching is the reason a page loads quickly when several people arrive at once, and turning it off trades a rare hour of confusion for permanently slower pages. The better answer is to keep the caching and add the verification habit: after any change that affects money, hours or contact details, check the page signed out on a second device before you call the job done.