I Fixed the Website Three Times. The Customer Kept Seeing the Old Version.

There is a conversation that happens on nearly every website project and it goes like this. You change something. You check it. It is right. You tell the client. The client looks and says it has not changed. You look again. It has definitely changed. Everyone begins to doubt everyone.

Almost every time, the change was made correctly and the person looking at it was being served a copy from earlier. That is caching, and it is the single most common cause of a fix that appears not to have worked.

There is not one cache, there are four

This is the part that makes it so persistent. When a page reaches somebody’s screen, it may have been held in any of these:

1. Their browser. Told by your server how long to keep each file. On images and stylesheets that instruction is often a full year, which is correct and desirable, right up until you change one. Google’s own guide to caching puts it bluntly: once a browser holds a file cached for a year, you cannot make it fetch a new one, “at least not without changing the URL of the resource”.
2. A content delivery network, if you use one. A copy sitting on a server geographically near your visitor.
3. The host’s page cache. Most decent WordPress hosting stores a finished copy of each page so it does not have to rebuild it on every visit.
4. A caching plugin, doing broadly the same job again, one layer further in.

Clearing one does nothing to the other three. That is why “I cleared the cache” and “it is still wrong” are both true statements at the same time.

The bug I chased for a whole day

Worth telling because I got it wrong repeatedly before I got it right.

I had rebuilt the colour scheme and typography on one of our own sites completely. On the screen that mattered, it looked unchanged, and the words used about it were not polite. I checked the source files. Correct. I checked the server. Correct. I concluded the screen was showing a stale copy, which was partly true and entirely unhelpful.

The actual cause was one line. WordPress appends a version number to the stylesheet address “as a query string for cache busting purposes”, like style.css?ver=121.0. That version number is set in the theme, by hand, and it had not been changed. So although the file’s contents were completely different, its address was identical to the one every browser and every cache layer already held a copy of, with an instruction to keep it for a year.

Nobody was ever going to see the new design. Not the owner, not a returning customer, not anybody who had visited the site once in the previous twelve months. The work had shipped and simultaneously not shipped.

The rule that came out of it is now absolute here: every change to a stylesheet or script is accompanied by a version bump in the same pass. Not later. Not when somebody complains.

The second trap, which is worse

Bumping the stylesheet version does not cascade to the things the stylesheet references.

If your CSS points at a font file or a background image, those have their own addresses and their own cache lifetimes. Change the font, bump the stylesheet, and the stylesheet is refetched perfectly, still pointing at the same font address, and the browser reuses the old font it already has.

Which means a fix can reach every new visitor and never reach a single returning one. Those are your existing customers. They are precisely the people whose opinion of your business is being formed by a version of the site you thought you had replaced.

Every cacheable asset needs its own busting token. Not one at the top.

How to find out what people actually see

Stop looking at your own browser. You have visited the site forty times today and it is the least representative device in the world.

• Private window on a device that has never been there. The quickest honest test.
• Add a nonsense query string. Visit yoursite.co.uk/?x=1. Many page caches treat that as a different address and rebuild it, so you see the true underlying content. If that looks right and the plain address looks wrong, you have proved it is caching and not a content fault.
• Check the served file, not the file on the server. Open the stylesheet address directly in a browser and look for something you know you changed. This distinguishes “not uploaded” from “uploaded but not being served”.
• Ask somebody else on a different network. Genuinely, this is not primitive. It is the only way to check the CDN layer without tooling.

Why hosts do not just turn caching off

Because it is the reason your site is quick. A cached page is a file handed straight over. An uncached page means the server building it from a database on every single visit. Turning caching off to make editing easier would cost you the performance discussed in our speed health check and gain you nothing your visitors would notice.

The answer is not less caching. It is correct versioning, so the cache knows when something has genuinely changed. Get that right and you can cache aggressively and still ship changes instantly, which is what a properly built site does.

What to take from this

If your web developer tells you a change is live and you cannot see it, both of you are probably right, and the question to ask is not “did you actually do it” but “did the version get bumped, and does that cover the fonts and images too”.

And if you have ever quietly concluded that your website simply does not update properly any more, it is worth having somebody look, because a site nobody can reliably change is a site that stops being changed.

That kind of thing is the day to day of our website design and maintenance work.

Questions people ask about caching

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

Because you have been looking at the site all day and your browser has fetched the newest version, while their browser is still holding a copy it was told to keep, sometimes for a year.

How do I check what a visitor actually sees?

Open the site in a private window on a device that has never visited it, or add a meaningless query string to the address, which forces a fresh fetch past many caches.

What is cache busting?

Changing the address of a file whenever its contents change, usually by appending a version number, so browsers treat it as a new file and fetch it rather than reusing the copy they already hold.

Do fonts and images cache separately from the stylesheet?

Yes, and this catches people out. Bumping the version on a stylesheet does not cascade to the font and image files it references. Each one needs its own cache busting token.

Sources

• WordPress Developer Resources, wp_enqueue_style(): the version number “is added to the URL as a query string for cache busting purposes”.
• Google, web.dev, Prevent unnecessary network requests with the HTTP Cache: a file cached with max-age=31536000 (one year) cannot be refreshed “without changing the URL of the resource”.
• Weightman Digital build records, August 2026: a theme version constant left unchanged across a full redesign, with static assets served under a one year max-age, producing a shipped change no returning visitor could see.
• Follow up finding on the same project: a stylesheet version bump does not propagate to the font and image files that stylesheet references.