Why your site still shows the old version

You made a change, saved it, refreshed the page — and the old version is still there. Before assuming the save itself failed, it's worth knowing that this is, by a wide margin, almost always a caching problem rather than a lost edit. Something between the server and your screen made a copy of the page before your change, and is still handing that copy out instead of fetching a fresh one.

The fix is finding which of several possible caches is holding the stale copy, since there can genuinely be more than one layer involved at once.

The layers, in the order data actually travels through them

1. Your own browser

The first and most common culprit. Browsers cache pages, images and stylesheets specifically so they don't have to re-download them on every visit — which is exactly the behaviour that makes an old version linger. Try a hard refresh first:

• Windows — Ctrl + F5 or Ctrl + Shift + R.
• Mac — Cmd + Shift + R.

If that doesn't help, load the page in a private or incognito window instead, which starts with no cache at all. If the new version appears there, the fault was sitting entirely in your normal browser's cache, and our full guide on clearing your browser cache properly covers doing it thoroughly rather than relying on one hard refresh.

2. A page caching plugin or your control panel's caching feature

If a private window still shows the old version, the site itself is likely serving a cached copy to every visitor, not just you. Page caching stores a pre-built copy of a page so the server doesn't have to regenerate it on every single visit — which is good for speed, but means a change won't appear until that stored copy is cleared or expires naturally. Look for a caching plugin's settings and use its "clear cache" or "purge" option, or check for an equivalent caching feature in your hosting control panel. Our guide on what page caching actually does explains why this trade-off exists.

3. A CDN sitting in front of the site

A content delivery network keeps its own copies of your pages at locations around the world, entirely separate from both your browser's cache and any caching on the server itself. Clearing the site's own cache does nothing to a CDN's stored copies — they need to be purged separately, usually from within the CDN's own dashboard or control panel. If your site uses one, check there next; our guide on what a CDN is and how it works covers the basic mechanics if you're not sure whether one is involved.

4. Object or opcode caching on the server

Less commonly, a server-level caching layer designed to speed up database queries or PHP execution can hold onto stale data slightly longer than expected, particularly right after a bulk update. This is usually the last thing to check, once browser, page, and CDN caching have all been ruled out and the change still isn't appearing.

Working through it in order

1. Confirm the change actually saved

   Check it was published rather than left as a draft, and that you were editing the live site rather than a staging or development copy.

2. Test in a private window

   This isolates your own browser's cache from everything else in one step.

3. Clear any page caching plugin or control panel caching feature

   If the private window still shows the old version, this is very likely where the stale copy is sitting.

4. Purge the CDN, if one is in use

   A separate step from clearing the site's own cache, and easy to forget precisely because it lives in a different dashboard entirely.

If a visitor sees the old version but you don't

This is usually not a contradiction — it typically means your own device already picked up the new version somewhere along the way, while theirs is still working through its own cache, or through a CDN edge location that hasn't refreshed yet. Ask them to try a hard refresh or a private window before assuming the fix hasn't taken effect at all.

If none of that clears it

Tell support what change you made, roughly when, and which of the steps above you've already tried. That's usually enough to identify whether a caching layer on the account needs clearing from the server side, which isn't always something a customer can trigger directly.