Update pressed, nothing changed
Someone changes the opening hours, presses Update and opens the website. The old hours are still there. They refresh. Still there. They ask a colleague, who sees the new version on their phone but the old one on their laptop. Somebody says to clear the cache, but nobody knows which cache, and there seem to be several buttons for it in different places.
After a few rounds of this, staff stop trusting that anything they change will appear, and start emailing the developer for every edit.
Why there are so many caches
Caching makes sites fast by keeping a ready-made copy of each page. That is good, until several layers each keep their own copy and do not know when to throw it away.
| Cache layer | Where it lives |
|---|---|
| Caching plugin | Inside WordPress, such as WP Rocket or W3 Total Cache |
| Host server cache | On the hosting platform, often switched on by default |
| Content delivery network | Cloudflare or similar, serving copies from servers worldwide |
| Object cache | Redis or Memcached, holding database results |
| Browser cache | On each visitor's own device |
| Minified CSS and JavaScript | Combined files that are regenerated separately |
Problems start when two layers overlap, such as a caching plugin and a host cache both active, or when the CDN is told to cache pages for a long time and nothing tells it to clear when content changes.
What stale pages cost
Customers see wrong prices, old opening hours or expired offers, and act on them. Staff lose confidence in the site and route everything through a developer. And time goes on clearing caches by hand, often including ones that did not need clearing, which slows the site for everyone.
It also muddies every other diagnosis. When a page shows the wrong thing, people cannot tell whether the edit failed, the site is broken or it is a cache, so small problems get escalated to a developer who spends the first part of every job working out which copy of the page they are looking at.
How we sort out the caching
- Map every cache in front of the site, from the browser back to the database, and how each one is currently set.
- Remove overlapping layers. One page cache is usually enough; we keep the one that suits the hosting best.
- Set each layer to clear the right pages automatically when content is published or updated, including the homepage, category pages and listings that show the changed content.
- Connect WordPress to the CDN, such as Cloudflare, so publishing a change clears the CDN's copy too.
- Exclude pages that must always be live, such as basket, checkout and account pages, from page caching.
- Version CSS and JavaScript files properly, so design changes reach visitors without anyone clearing their browser.
- Give editors a single, clear "clear this page" option for the rare case where they need it, and a short note on how to check.
After the clean-up
Editors press Update and see the change on the live site straight away. The site stays fast because the caches still work, they just clear when they should. Staff stop sending small changes to a developer, and customers stop seeing yesterday's information.
Is this what happens on your site?
- Changes appear for some people and not others
- Staff have been told to clear the cache but do not know which
- Both a caching plugin and a host cache are switched on
- The site uses Cloudflare or another CDN
- Design changes need a hard refresh to appear
- Checkout or basket sometimes shows another visitor's details or wrong totals