Why do customers still see the old version of our website?

Keeping a copy is the design, not a fault

The first thing to let go of is the idea that something broke. Nothing did.

A copy can be held in more than one place. MDN describes the instruction that governs it: "The HTTP Cache-Control header holds directives (instructions) in both requests and responses that control caching in browsers and shared caches (e.g., Proxies, CDNs)."

Two kinds matter to you. "A private cache is a cache tied to a specific client", which in practice means one person's browser. A shared cache sits in front of many people at once.

That difference explains a pattern owners find maddening. One customer sees the new page and another sees the old one, and both are behaving correctly. They are reading different copies with different ages.

It also explains why your own browser is the worst place to test. You have been on the site all week, so you hold the freshest copy of anyone.

The clock is one your server started

Here is the mechanism, and the word to learn is freshness.

A stored copy is reusable until it expires. The expiry is a length of time between when the page was generated and when it stops being usable without checking back. If your server sent an expiry, that is the clock. Everything else follows from it.

The consequence people miss is that the clock started when the copy was taken, not when you published. A visitor who loaded the page an hour before your change is an hour into a countdown you cannot reach.

There is no way to reach into a copy already sitting on somebody's device and remove it. You can only affect what happens the next time they ask.

If you set no expiry, the cache is allowed to guess

This is the part that turns a support question into a decision, and the standard is candid about it.

RFC 9111 permits a cache to make one up: "Since origin servers do not always provide explicit expiration times, a cache MAY assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other field values (such as the Last-Modified time) to estimate a plausible expiration time."

So when nobody chose a lifetime, something else chose one, using clues like how long ago the page last changed.

Then comes the sentence worth quoting to anybody who promises you a fix: "This specification does not provide specific algorithms, but it does impose worst-case constraints on their results."

The standard declines to say how long. It sets outer limits and leaves the rest to whoever built the cache. That is an unusual thing for a specification to admit, and it means the honest answer to how long it takes before everyone sees the change is that nobody can tell you, unless you set the expiry yourself.

Setting one takes the guessing away, and the standard says so directly: "A cache MUST NOT use heuristics to determine freshness when an explicit expiration time is present in the stored response."

There is also a way to refuse storage outright, which matters for anything personal: "The no-store response directive indicates that any caches of any kind (private or shared) should not store this response."

That one is worth treating as a safety setting rather than a speed setting. MDN warns what happens when personalized content lands in a cache shared by many people: "if personalized contents are stored in a cache other than a private cache, then other users may be able to retrieve those contents". An invoice or an account page reaching the wrong reader is a different order of problem from a stale headline.

An expired copy is not always a new download

When the countdown ends, the browser does not always fetch the page again. It asks a question first.

MDN describes the exchange. The browser sends a header "to ask the server if there have been any changes made since the specified time". If nothing has changed, then "The server will respond with 304 Not Modified if the content has not changed since the specified time."

That reply carries no page at all. It is a status and nothing more. Then "the client reverts the stored stale response back to being fresh", so the same copy gets reused under a new countdown.

This explains two things owners find contradictory.

The first is that a visitor can refresh, watch something happen, and still get the old page. The request did happen. The answer was keep what you have.

The second is that a page can be genuinely updated and still fail to arrive, if the server concludes nothing has changed. That judgement usually rests on a modification time read from the file system. For a file somebody edited, that is reliable. For a page assembled on the fly from a database, it is a guess about a file that may never have changed.

So a report of an old page is really two questions. Is their copy still fresh, and if it is not, is the server telling them nothing has changed?

Those have different fixes. Guessing between them is how an afternoon disappears.

What to check, in order

Five checks, and the first four are free.

• Open the page in a private window before reporting anything. If it looks new there and old in your normal window, you have a copy, not a bug.
• Ask the customer what they see and when they last visited. Somebody who has never been to the site cannot be holding an old copy of it.
• Find out whether anything sits in front of your site, such as a content delivery network or a caching plugin. Those hold copies for many people at once.
• Ask whoever runs the site what expiry it sends. If the answer is that nothing is set, that is the finding: the duration is being chosen for you.
• Only then change the page again. Publishing a second time does not shorten a countdown already running.

Now the arithmetic, because the number is the part that settles arguments. Suppose your server says a page may be reused for 24 hours, and you publish a correction at 9am on Tuesday.

A visitor who loaded the page at 10am on Monday is 23 hours into that countdown, so they can keep the old copy until 10am Tuesday, an hour after your fix. A visitor who first arrives at 9:05am Tuesday gets the new page immediately. Same site, same moment, two correct answers.

Change the setting to 5 minutes and the worst case falls from 24 hours to 5 minutes, at the cost of more requests reaching your server. That is the actual trade, and it is a decision rather than a bug report.

Working out which copy a customer is holding, and what your site tells caches to do, is part of what we do on websites.

Sources

• RFC 9111, HTTP Caching (RFC Editor, Internet Standards Track)
• HTTP caching (MDN Web Docs, Mozilla)
• Cache-Control header (MDN Web Docs, Mozilla)

Last reviewed 2026-09-12.