Why is my website still showing the old version?

Your site is fine. The copy in front of it is old.

Publishing writes a new version of the page at your origin — the server or storage bucket your host actually reads from. Nothing in that step promises your visitors are talking to your origin. Between the two sit your browser, usually a content delivery network, sometimes a service worker your framework installed, and occasionally a proxy on the visitor's own network. Each of them keeps a copy and a rule about how long to trust it, and each of them will answer a request without asking anyone.

The signature of this problem is inconsistency. You see the new page and your customer does not. Two people get different versions of the same address. It fixes itself an hour later with no deploy. That pattern is worth learning, because a genuinely broken release is broken for everybody at once — so if some people are fine, stop reading your build log and work out who is answering the request instead. The rule underneath the first one is what surprises people: many caches are configured not just to hold a copy until it expires, but to keep serving the expired copy while they fetch a fresh one in the background. Expired does not mean out of use, which is how a page outlives its own lifetime by a wide margin.

Find the layer before you fix anything

Each step below rules out one cache, in the order that costs you the least. Work down the list and stop at the first one that shows the new page: that is your answer, and the fix is a purge at that layer rather than another deploy.

1. Open it in a private window. If the new version appears there, the stale copy was only ever in your own browser and no visitor was ever affected. Hard-refresh your normal window and you are finished. This is the most common outcome and the most commonly skipped step, which is why the panic usually outlasts the bug.
2. Add a meaningless query string. Load the same address with something like ?x=1 on the end. Most shared caches treat that as a different URL and go to the origin for it, so a fresh page here means your origin is correct and something between you and it is still serving the old copy under the clean address.
3. Open it on a different network. A phone on mobile data rather than the office Wi-Fi. A content delivery network keeps separate copies in separate locations, so this separates one stale edge from something every visitor is getting, and it is the only version of the test that reflects what a stranger actually sees.
4. Ask the origin directly. Fetch the page through your host's dashboard, a server-side preview, or a request aimed at the origin rather than at the public address. If the origin is right and the public URL is wrong, the problem lives entirely in delivery, and nothing in your code or your build is going to move it.

Once you know the layer, purge or invalidate it there, then repeat the third step from a network you do not control. Confirming a fix from your own machine is how people end up certain a purge worked when it did not.

The version of this that cost us an hour

We host pages for our own customers, so this is our problem and not only our readers'. On 11 September 2026 we found a page we had taken down still being served to anyone who opened it, fifty-two minutes after the takedown. Everything we could see on our side was correct: the file was gone from storage and our own records said the page was unpublished. The content delivery network in front of it had been left to keep answering with its last good copy for up to a day while it revalidated in the background, so deleted described our storage and said nothing about what a visitor received. We fixed it in two places deliberately — once in the network's configuration, to refuse to serve stale copies at all, and once in the page's own cache instructions, so that the bound no longer depends on a setting a rebuilt backend would quietly restore to its default.

The rule we took from it is the transferable part: published, updated and deleted are claims about your origin. What a visitor receives is a separate fact, and the only honest way to learn it is to fetch the page the way a stranger would. The same layer also changed what we could measure. Views on the pages we host are recorded as a floor rather than a total, because a request answered at the edge never reaches the origin that does the counting — and while stale serving was live, our own network's cache-refresh requests were most of what that counter contained, until we excluded them by name. A cache does not only change what people see. It changes what you can prove about what they saw.

It changed how we write the two operations, too. Publishing uploads the file first and records it second, because the reverse order records a live page while nothing is being served. Unpublishing deletes the file first and marks the record second, because the reverse records a page as gone while it is still up. When the second half fails, the state we report is then wrong in the direction that is safe to be wrong in. Asking which failure you would rather have is most of what running a website carefully consists of, and it is the same discipline we build into AgentCeres — the AI Growth Officer at agentceres.com: a roster of specialists drafts the pages, posts and outreach, and outbound work waits for a person's approval by default. If you have just published a site for the first time, the checks in should I use AI to build my website are the other half of this one.