WordPress Caching Explained: What to Clear and When

If your WordPress changes are not showing up, the problem is usually not “the cache” in general — it is one specific layer holding onto an old version. The fastest fix is to identify whether you need to clear page cache, object cache, browser cache, or CDN cache, then clear only that layer and retest.

That matters because clearing the wrong cache can waste time and sometimes make a site seem “fixed” when the real issue is elsewhere. In this guide, I’ll show you what each cache does, the symptoms each one causes, and the safest way to diagnose stale content without breaking your site.

What WordPress caching actually means

Caching is just temporary storage. Instead of building a page, query result, or asset from scratch every time, WordPress or a layer in front of it serves a saved copy.

The tricky part is that WordPress often uses more than one cache at once:

• Page cache stores a full HTML page.
• Object cache stores repeated database results, such as options, menus, or query results.
• Browser cache stores files on the visitor’s device, such as CSS, JavaScript, and images.
• CDN cache stores copies of files or pages at edge servers around the world.

Those layers solve different performance problems, but they can also hide changes at different times. A post update might be blocked by page cache, while a CSS edit might be blocked by browser or CDN cache.

The symptoms that point to the wrong cache

When someone says “my site is not updating,” the cause usually shows up in the pattern of what is stale and where.

• Only you can see the old version: often browser cache, a logged-in optimization plugin setting, or a local proxy.
• Visitors see an old homepage or post: often page cache or CDN cache.
• Dynamic parts are stale — like menus, counts, related posts, or widgets: often object cache or a plugin-level cache.
• CSS changed, but the design looks old: often browser cache, CDN cache, or a stylesheet filename that did not change.
• A change appears on desktop but not mobile: sometimes separate cache rules, device-specific optimization, or a page builder cache.

One useful clue: if WordPress admin shows the updated content but the public site does not, the issue is usually in a cache layer above WordPress, not in the editor itself.

Page cache: the one most people mean

Page cache stores the final HTML of a page so WordPress does not have to rebuild it for every visitor. This is common in caching plugins, hosts, and some CDNs.

It is excellent for performance, but it can serve a stale version after you edit content, change a template, or update menus. Depending on your setup, page cache may be cleared automatically when you save content — but not always.

How to safely test page cache

1. Open the page in an incognito/private window.
2. Check it from a second device or a mobile connection if possible.
3. Use the site’s cache purge button if your host or plugin provides one.
4. Wait for a minute or two, then refresh the page hard.
5. If the site supports it, purge only the affected URL instead of the whole cache.

If the page updates after a purge, the cache was the issue. If it comes back stale again quickly, your cache rules may be too aggressive or not clearing on content updates.

Object cache: fast database results, sometimes stale data

Object cache stores repeated database queries. On busy sites, this can make a big difference, especially with persistent object caching via Redis or Memcached. But if it is misconfigured or not cleared when it should be, it can hold onto old query results.

Object cache problems often show up as:

• Menus or navigation not updating right away
• Changes to user roles or settings not appearing
• Dashboard values looking inconsistent
• Parts of a page staying stale while the rest updates normally

Object cache is more technical than page cache, and the right action depends on your setup. Some hosts manage it for you; some plugins expose a simple clear button; some sites use it without the owner realizing it.

When object cache is the likely culprit

If a page refresh does not help, browser cache is unlikely to be the main issue. If the public page and admin area disagree, or if one specific widget or query looks “stuck,” object cache is worth checking next.

Be careful here: flushing object cache is usually safe, but changing persistent cache settings without knowing how the host configured them can create temporary load spikes or break an optimized setup.

Browser cache: the easiest one to overlook

Browser cache lives on the visitor’s device. It stores static files so the browser can load them faster next time.

This is why a design change can look correct in WordPress but still appear old in your browser. The browser may still be using an older CSS or JavaScript file, especially if the filename did not change.

How to tell browser cache from WordPress cache

• Check the page in an incognito/private window.
• Try another browser.
• Clear the browser cache for just your site, not necessarily the whole browser history.
• Do a hard refresh: on many browsers that means forcing fresh files instead of cached ones.

If a private window shows the correct version while your normal window does not, browser cache is probably the issue. That is especially common after CSS edits, theme changes, or script updates.

CDN cache: fast delivery, global stale content

A CDN stores copies of your site’s assets, and sometimes full pages, at servers closer to your visitors. That is great for speed and reliability, but it can also keep serving an older version after you update content or files.

CDN issues usually show up as:

• Content changing in one region but not another
• Old images or styles still loading after a change
• A page updating locally but not for remote visitors
• Some pages refreshing while others remain stale

The fix depends on the CDN. Some let you purge everything, some let you purge individual URLs, and some cache only static assets while your host handles page cache separately.

When a CDN is in play, remember that you may need to clear more than one layer. A fresh file on the server can still be hidden by the CDN, and a purged CDN file can still be hidden by browser cache.

The safest order to clear caches

If you are trying to fix a stale site, use a methodical order instead of clearing everything at random.

1. Back up first, especially if you are about to change cache settings, plugins, or server options.
2. Check the page in a private window and a second browser.
3. Clear browser cache for the affected site.
4. Purge page cache from your caching plugin or host.
5. Purge CDN cache if you use one.
6. Flush object cache only if the issue points to dynamic data or query results.
7. Retest in a private window and from a second device or network.

Do not install another caching plugin just to “force” a refresh. Multiple caching layers from different plugins or hosts can conflict and make the site harder to diagnose.

Common mistakes that make cache problems worse

Most cache trouble comes from confusion, not from caching itself. The biggest mistakes are:

• Using two page caching plugins at the same time
• Clearing every cache layer when only one is stale
• Changing CSS or JS without versioning the file
• Assuming the issue is caching when it is actually a broken update or script error
• Editing a template on the server but forgetting the CDN also caches that file

If clearing cache does not fix the issue, stop there and investigate the real cause. Caching can hide a broken plugin, theme conflict, or JavaScript error, but it does not create those problems.

How to prevent stale cache issues

The easiest prevention is to make your site’s cache strategy predictable.

• Use one primary page caching system, not several overlapping ones.
• Make sure content updates trigger cache purges where appropriate.
• Version CSS and JavaScript files so browsers fetch the new copy.
• Know whether your host already provides page cache or object cache.
• Document which layers your site uses so you are not guessing later.
• Test important changes in an incognito window and on a second device.

If you run WooCommerce, membership, or other dynamic features, be especially careful with page caching rules. A page cache that is perfect for a blog can cause real trouble on a checkout or account page.

When cache is not the real problem

Sometimes people blame cache because it is the easiest thing to try first. But if the site is still broken after a proper purge, the real issue may be elsewhere:

• A plugin conflict after an update
• A theme template override
• A JavaScript or CSS error
• Server-side misconfiguration
• A CDN rule that rewrites or blocks files

That is where a structured diagnosis saves time. If your site is slow, stale, or inconsistent and you have already checked the obvious cache layers, start with free diagnosis so an engineer can tell you what is actually happening before more changes are made.

When to call a professional

Bring in help if you cannot tell which cache layer is causing the issue, if purges do nothing, or if your site uses a host-managed cache/CDN setup you do not want to disturb blindly. Also get help if the site is dynamic and cache changes are affecting checkout, forms, or logged-in users.

Mend’s engineers fix these problems on a backup-first workflow, usually the same day, and you get a plain-English report of the root cause and exactly what changed. If you want that handled for you, use Quick Fix for a smaller caching problem or Emergency Rescue if the site is broken and you need it handled fast.

If you are not sure whether the issue is caching or something deeper, a free diagnosis is the safest next step. And if you want ongoing updates, backups, and monitoring instead of recurring surprises, see Care Plan.

Related reading

If your caching issue started after an update or looks like a broader stability problem, these guides can help:

• What to Do When a WordPress Update Breaks the Site
• Fix “This Site Is Experiencing Technical Difficulties”
• WordPress 500 Errors: A Step-by-Step Diagnosis Guide
• Speed Up WordPress: Why Your Site Is Slow and How to Fix It

Quick rule of thumb: if the change is visible in WordPress but not on the front end, start with page cache and CDN cache. If the data itself looks stale, check object cache. If only your browser shows the old version, it is probably browser cache.