You change a price, swap a photo, or fix a typo on your website. You hit save. Then you reload the page — and the old version is still staring back. It’s one of the most maddening moments a business owner has with their own site, because it feels like the edit simply didn’t work.
In almost every case, it did work. The new version is live; you just aren’t being shown it. Something between your edit and your screen is holding on to an old copy and serving that instead. That “something” is a cache, and there is usually more than one of them in the chain.
This guide from the ZenWeb web design and care team explains what a cache is, where each one hides, and exactly how to clear website cache in the right order so your changes finally show.
Tired of fighting your own website to see a simple change?
We build and look after fast, easy-to-edit business sites where updates just show. See how we build and maintain websites →
Most Malaysian SME sites run on WordPress, so the steps below are written for it. This short video walks through fixing a WordPress site that isn’t behaving the way you expect, before we get into the cache detail.
Source video: WordPress Website Not Working? Fix Your Site Now! on YouTube
Quick Answer: Your changes aren’t showing because a cache is serving a saved copy of the old page instead of building a fresh one. Caching exists to make sites load faster, but after an edit that same saved copy becomes stale. The fix is to clear website cache so the next visit rebuilds the page from your latest version.
A cache is a saved copy kept close to the visitor so a page loads faster. Instead of rebuilding your page on every visit, the system hands over a ready-made copy. That’s a good thing — it’s a big part of why a well-built site feels quick. The trouble starts the moment you change the original, because the saved copy doesn’t update itself instantly.
So the page you see is real, just out of date — and any one of the caches sitting between you and that page can make a fresh edit look like it “didn’t save”.
One quick sanity check: is the page showing an old version, or showing nothing? Stale content is a cache problem. A totally blank page is different — that’s usually the WordPress white screen of death, which needs a different fix.
Quick Answer: There are usually four cache layers between your edit and a visitor’s screen: the browser, a page-cache plugin, your server or host, and a CDN. Each stores its own copy and each is cleared its own way. Knowing which layer holds the old page tells you exactly where to clear website cache.
Think of it as four copies of your page sitting in a line. To see your change, the copy nearest the visitor has to be refreshed — and sometimes all four do. Here’s what each layer stores and who controls it.
| Cache layer | What it stores | Who controls it |
|---|---|---|
| Browser cache | Images, CSS, and scripts saved on the visitor’s own device | The visitor (each person’s own browser) |
| Page-cache plugin | A ready-made HTML copy of each page | You, the site owner |
| Server / host cache | A host-level copy served before WordPress even runs | Your web host |
| CDN cache | Copies held on edge servers around the world | Your CDN provider |
Source: ZenWeb website support and maintenance jobs, Malaysian SME sites, 2024–2026. Licence.
Not every site has all four — a small brochure site might have only a browser cache and a plugin, while a busy store often has all four. The same caching that traps your edit is what keeps pages quick, so the answer is to refresh it, not remove it — the same goal as keeping a site fast on mobile.
Quick Answer: Before you clear website cache anywhere, run three ten-second checks: hard-refresh the page, open it in an incognito window, and check it on your phone. If the change shows in any of those, the site is fine and only your own browser was stale — no deeper clearing needed.
Half the time, you never need to touch a plugin or a host panel. Rule out the simplest explanation first:
If every one of those still shows the old version, the stale copy is further down the chain — in your plugin, host, or CDN — and it’s time to clear those. If the page won’t load at all rather than showing old content, that’s not a cache issue; treat it like a website that is down and not loading instead.
Quick Answer: Clear website cache from the visitor’s side inward: hard-refresh, then purge your caching plugin, then your server or host cache, then your CDN, and finally your full browser cache if needed. Do it in order and stop the moment the change appears — the step that fixed it tells you which layer was holding the old page.
Work through these in order. After each step, reload the live page in a private window and check — the moment your change shows, you can stop.
One catch: purging the plugin or CDN needs access to your WordPress dashboard. If you can’t get in to purge, sort that first — our guide on being locked out of the WordPress admin covers the way back in.
Don’t want to hunt through four cache layers every time?
Our care plans keep caching set up so your changes just show. See our web design and care pricing →
Quick Answer: Across the “my changes won’t show” jobs ZenWeb handles, the browser is the culprit most often, followed by an un-purged caching plugin. Server and CDN caches account for fewer cases, and roughly one in twelve turns out not to be cache at all. That’s why clearing from the browser inward solves most cases fastest.
Here’s how the cause broke down across the stale-content jobs we’ve worked on for Malaysian SME sites.
| Root cause | Share of cases | Scale |
|---|---|---|
| Browser / local cache showing an old copy | 36% | |
| Caching plugin not purged after the edit | 28% | |
| Server / host cache still serving the old page | 17% | |
| CDN cache not refreshed | 11% | |
| Not cache at all (draft, staging, or wrong page) | 8% |
Source: ZenWeb website support jobs, Malaysian SME sites, 2024–2026. Licence.
The lesson is in the order. The two layers nearest the visitor, browser and plugin, cause almost two-thirds of cases. Start there and you clear website cache in under a minute, without ever calling your host.
Quick Answer: Clearing a browser or plugin cache takes under two minutes and almost no skill. Server and CDN caches take a little longer and a little more care. None of it is risky when done right — the main thing to watch is a CDN purge, which can briefly slow the site while it refills.
Here’s roughly what each layer costs you in time and effort, and the one thing to watch for on each.
| Cache layer | Time to clear | Difficulty | Watch out for |
|---|---|---|---|
| Browser | Under 1 minute | Very low | Only fixes your view, not visitors’ |
| Page-cache plugin | 1–2 minutes | Low | Purge all, not one page, after big edits |
| Server / host | 2–5 minutes | Low–medium | Location differs by host; support can help |
| CDN | 2–10 minutes | Medium | A full purge can briefly slow the site |
Source: ZenWeb website support jobs, Malaysian SME sites, 2024–2026. Ranges are typical, not guaranteed. Licence.
Clearing the cache makes your latest version show, but it can’t make a heavy page load quickly. If your page is slow because the images are oversized, no purge fixes that — that’s the job covered in our guide on heavy images slowing your site.
Quick Answer: A stale cache doesn’t just annoy you — it can show customers an old price, a sold-out offer, or last month’s hours, and even hand paid traffic an outdated landing page. The cost isn’t the clearing; it’s every visitor who acts on wrong information before you notice.
When a change won’t show for you, it often isn’t showing for customers either. That plays out in small, expensive ways:
A stale page isn’t a cosmetic issue to fix “whenever” — while it’s up, it’s actively giving people the wrong answer, the same way a website that’s down costs you every hour it’s offline.
Quick Answer: Recurring “changes won’t show” almost always traces to missing habits, not bad luck. Set your caching to auto-purge when you publish, keep a staging site to preview edits, and always check in an incognito window. Then you rarely need to clear website cache by hand again.
When we audit sites that fight this over and over, the same safeguards are missing again and again. Here’s how often each one simply wasn’t in place.
| Missing safeguard | Not in place on | Scale |
|---|---|---|
| No staging site to preview changes | 66% | |
| No “purge cache” step in the update routine | 54% | |
| Browser cache lifetime set too long | 41% | |
| CDN not set to auto-purge on publish | 37% | |
| Team never taught to hard-refresh | 29% |
Source: ZenWeb maintenance audits, Malaysian SME sites, 2024–2026. Licence.
None of these are costly or technical. A caching plugin set to auto-purge on publish, plus a staging site to preview edits, is exactly the quiet setup a proper web design and care plan puts in place — so the change you make simply shows, and the whole “did it save?” panic never starts.
A change that won’t show looks like a broken save, but it’s almost always just a cache. The fix is to clear website cache, not to redo the edit. Check your own browser first with a hard refresh and an incognito window, then work inward through plugin, server, and CDN until the new version appears. Your edit was live the whole time; you were only being shown an old copy.
If the same pages keep going stale, that’s the signal to fix the setup rather than clear it by hand every week. Getting caching set to auto-purge once is far cheaper than losing a sale to an old price.
Changes still not showing after all that?
Book a free 30-minute session — we’ll find which cache is holding the old page, get your latest version showing, and set up auto-purge so it stops happening.
Because a cache is serving a saved copy of the old page instead of building a fresh one. Your edit did save — you’re just being shown a stored version. Hard-refresh the page, then purge your caching plugin, server cache, and CDN until the new version appears.
It means telling each layer that stores a copy of your page — your browser, your caching plugin, your host’s server, and your CDN — to throw that copy away and rebuild it from your latest version. You often only need to clear the one layer that’s holding the old page.
Hard-refresh your browser with Ctrl + F5 or Cmd + Shift + R, then clear your browsing data. For the server layer, use your hosting panel’s purge button or ask your host. For a CDN, purge from its dashboard. None of these need a WordPress plugin.
No. Clearing a cache only removes temporary saved copies, never your actual pages, posts, images, or settings. The site simply rebuilds those copies on the next visit. The only side effect is that the first few loads afterwards can feel slightly slower while the cache refills.
Then it probably isn’t a cache. Check that you edited the live page and not a draft or a staging copy, and that you’re viewing the correct URL. If you changed your domain or host recently, DNS changes can also take time to update across the internet.
Complete the form and our team will contact you to discuss your goals. Let’s grow your business.

Online