How to Clear WordPress Cache: Every Method That Works

You just updated your homepage. You reload the page — and nothing changed. You reload again. Still the old version. You check on your phone — same old page. Meanwhile, your colleague says the new version shows fine for them. Welcome to the most confusing five minutes in WordPress site ownership.

What you are experiencing is stale cache: somewhere between your server and your screen, an old copy of your page is being served instead of the fresh one. The fix is to clear the cache — but which cache? A WordPress site can have five or more caching layers, and clearing the wrong one changes nothing.

This guide maps every cache layer on a typical WordPress site, explains when clearing is actually needed (and when it is not), and walks you through every method that works: your caching plugin, your hosting control panel, WP-CLI commands, browser cache clearing in Chrome, Firefox, Safari, and Edge, CDN purging, and object cache flushing. You will also learn how to clear a single page instead of the whole site, what to do when clearing does not fix the problem, and the safe habits that keep you from breaking a live site.

The Six Cache Layers on a WordPress Site

Before clearing anything, you need to know where the stale copy is hiding. Here are the layers, from closest to the visitor to closest to the server:

1. Browser cache. The visitor’s own browser keeps copies of files and sometimes whole pages. If only one person sees old content while everyone else sees the new version, the problem is almost certainly their browser cache.

2. CDN cache. If you use a content delivery network, copies of your pages and files live on edge servers around the world. A stale CDN copy affects every visitor in a region at once, which makes it look like “the whole site” is outdated.

3. Page cache. Your caching plugin (or your host’s built-in caching) stores the finished HTML of each page on the server. This is the layer most people mean when they say “clear the cache,” and it is the most common source of stale content after updates.

4. Object cache. Database query results are stored in memory using systems like Redis or Memcached. A stale object cache shows up as outdated dynamic data — old menu items, wrong widget content, settings that refuse to change — even though the page itself looks current.

5. Host/server cache. Many managed hosts run their own caching layer (sometimes a reverse proxy like Varnish, sometimes a proprietary system) that sits in front of WordPress. It behaves like a page cache but is controlled from the hosting panel, not from a plugin.

6. DNS cache. Not a content cache at all, but worth knowing: after you change DNS records (moving hosts, adding a CDN), old DNS answers can send visitors to the old server for hours. If a site move “is not showing,” DNS caching is usually the reason.

The troubleshooting rule is simple: work from the visitor inward. Check the browser first, then the CDN, then the page cache, then deeper layers.

When Clearing Is Actually Needed (and When It Is Not)

Clearing cache is a tool, not a ritual. Clear it when:

• You published or updated content and visitors still see the old version.


• You changed your theme, CSS, or layout and the design looks broken or outdated.


• You installed, updated, or removed a plugin and something behaves strangely.


• You changed menus, widgets, or site settings and they do not appear.


• You are troubleshooting and need to rule out stale copies as the cause.

Do not clear cache when:

• Nothing has changed on the site. Clearing a healthy cache just forces your server to rebuild everything, slowing the site down temporarily for no benefit.


• You are seeing an actual error (a white screen, a PHP error message). That is a code problem, not a cache problem — clearing the cache will not fix broken code.


• You just want the site to “feel faster.” A warm cache is the fast state; clearing it makes things slower until it rebuilds.


• You cleared it five minutes ago and the problem persists. Repeatedly clearing the same layer is a sign you are clearing the wrong layer — move on to the next one.

Method 1: Clear Cache via Your Caching Plugin

This is the first method to try, because the page cache is the most common culprit and the plugin usually clears it intelligently.

1. Log in to your WordPress admin dashboard.


2. Look at the top admin bar — most caching plugins add a menu item there, often labeled “Cache,” “Performance,” or the plugin’s name. Hover over it.


3. Choose the “Purge All Caches” or “Clear All Cache” option. The exact wording varies, but every caching plugin has a full-purge option.


4. Alternatively, open the plugin’s settings page and look for a “Purge Cache,” “Clear Cache,” or “Empty Cache” button — usually on the main dashboard tab of the plugin.


5. Wait for the confirmation message, then check your site in a private/incognito window.

Most caching plugins also clear the cache automatically when you publish or update content. If you find yourself clearing manually all the time, check the plugin’s settings: the automatic purge on content updates may be disabled, or certain content types may be excluded.

Clearing a single page: many caching plugins let you purge just one URL. When viewing the page in the admin bar, look for a “Purge this page” or “Clear cache for this URL” option. In the plugin settings, there is often a field where you can paste a URL to purge individually. Use this instead of a full purge whenever only one page is stale — it leaves the rest of your warm cache intact.

Method 2: Clear Cache via Your Hosting Control Panel

If your host provides built-in caching (common on managed WordPress hosting), the plugin purge may not touch the host’s layer. You need to clear it from the hosting panel:

1. Log in to your hosting account’s control panel.


2. Find the caching section — it may be labeled “Cache,” “Performance,” “Speed,” or appear under your site’s management page.


3. Look for a “Purge Cache,” “Clear Cache,” or “Flush Cache” button and click it.


4. Some hosts offer separate options for different layers (page cache, CDN, object cache). If the problem persists after a basic purge, clear each layer the panel offers.


5. Confirm in an incognito window.

If your host uses a reverse proxy cache, there may also be a “development mode” or “bypass cache” toggle. Turning that on temporarily is useful when you are making many changes in a row — it stops the cache from being rebuilt with half-finished work, and you can turn it off when you are done.

Method 3: Clear Cache via WP-CLI

If you have SSH access to your server, WP-CLI (the WordPress command-line interface) clears caches quickly and precisely — handy when the admin dashboard itself is misbehaving.

Flush the object cache:

wp cache flush

This empties the persistent object cache (Redis, Memcached, or the database-backed fallback). It is safe to run: WordPress rebuilds object-cache entries on demand.

Delete all transients:

wp transient delete --all

Transients are temporary cached values stored in the database. Stale transients cause exactly the “settings will not update” symptoms described earlier. This command clears them all at once.

Clear a specific page or post cache depends on your caching plugin, since WP-CLI has no universal page-cache command. Many caching plugins register their own WP-CLI commands (check the plugin’s documentation). If yours does not, the plugin’s admin-bar purge from Method 1 is the way.

Run these commands from your WordPress installation’s root directory (where wp-config.php lives). After running them, verify the fix in an incognito window — command-line purges give no visual confirmation beyond their own success message.

Method 4: Clear Your Browser Cache

When the stale content appears for you but not for others, the problem is in your browser. You have two options: a hard refresh (quick, keeps everything else) or a full cache clear (thorough).

Hard refresh first — it forces the browser to re-download the current page while leaving the rest of the cache alone:

• Chrome / Edge (Windows): Ctrl + Shift + R, or Ctrl + F5


• Chrome / Edge (Mac): Cmd + Shift + R


• Firefox (Windows): Ctrl + Shift + R, or Ctrl + F5


• Firefox (Mac): Cmd + Shift + R


• Safari (Mac): Cmd + Option + R (first enable the Develop menu via Safari Settings → Advanced → “Show Develop menu in menu bar”; you can also use Develop → Empty Caches)

Full browser cache clear — use this when a hard refresh does not help, or when old stylesheets and scripts are stuck across many pages:

• Chrome: Settings → Privacy and security → Delete browsing data → check “Cached images and files” → choose a time range → Delete data. (Keyboard shortcut: Ctrl+Shift+Del on Windows, Cmd+Shift+Del on Mac.)


• Edge: Settings → Privacy, search, and services → under “Delete browsing data,” click “Choose what to clear” → check “Cached images and files” → Clear now.


• Firefox: Settings → Privacy & Security → under “Cookies and Site Data,” click “Clear Data” → check “Cached Web Content” → Clear.


• Safari: with the Develop menu enabled, choose Develop → Empty Caches. (Safari’s regular “Clear History” also clears the cache but wipes history and cookies too — Empty Caches is the surgical option.)

One more browser-level check: open the page in a private/incognito window. Incognito mode starts with a completely empty cache, so if the fresh content appears there, you have confirmed the issue is your normal browser cache and nothing deeper.

Method 5: Purge the CDN Cache

If your site sits behind a CDN, the edge servers may be holding old copies even after you cleared everything on your origin server. Symptoms of a stale CDN cache: the whole site looks outdated for many visitors at once, across different browsers and devices.

1. Log in to your CDN provider’s dashboard.


2. Find the caching section — usually labeled “Caching,” “Purge Cache,” or similar.


3. You will typically see two options: purge a single file/URL and purge everything. Start with the single URL if only specific pages or files are stale — paste the full URL of each affected page.


4. If the problem is site-wide, use “Purge Everything.” Be aware this forces the CDN to re-fetch your entire site from the origin, which temporarily increases load on your server.


5. Wait a minute or two for the purge to propagate to all edge locations, then verify in an incognito window.

Many CDN providers also offer an API or a WordPress integration that purges automatically when you update content. If you are purging manually more than occasionally, setting up that automation is worth the effort.

Method 6: Clear the Object Cache

Object-cache staleness is sneaky because the pages look fine while the data is old: navigation menus showing removed items, widgets displaying deleted content, options pages ignoring your saves. Two sub-methods:

Via a plugin or code: some caching plugins include an object-cache flush button alongside the page-cache purge. If yours does, use it — it is the same operation as the WP-CLI command, just with a button.

Via WP-CLI: wp cache flush, as shown in Method 3. This is the definitive way to empty Redis or Memcached-backed object caches.

PHP OPcache is a separate beast: it caches compiled PHP code, not content. If you edited theme or plugin PHP files directly on the server (via SFTP or a file manager) and the changes are not taking effect, the OPcache may be serving the old compiled version. Most hosts reset OPcache automatically within a minute or two. If yours does not, look for an “OPcache reset” option in the hosting panel, or ask your host. You cannot fix OPcache staleness by purging the page cache — it is a different layer entirely.

How to Clear Cache for a Single Page vs. the Whole Site

Default to the smallest purge that solves the problem:

• Single page stale: use the plugin’s per-URL purge, or the CDN’s single-file purge. Paste the exact URL, including https:// and any trailing slash exactly as it appears.


• A section stale (a category, a group of products): purge each affected URL individually, or check whether your caching plugin supports purging by content type.


• Whole site stale (theme change, site-wide settings, migration): purge everything — plugin cache, host cache, and CDN cache, in that order.


• Only you see the problem: it is your browser cache. Hard refresh; do not purge the server at all.

Purging the entire site on every small edit is like repainting a whole house because one wall got scuffed. It works, but it wastes the warm cache your visitors were benefiting from.

When “Clear Cache” Does Not Fix It: Troubleshooting Order

If you have cleared every layer and the old content is still there, stop clearing and start diagnosing. Work through this order:

1. Verify in incognito, on another device, on another network. If the new content appears anywhere, a cache somewhere is still stale — figure out which environment shows the old version and target that layer.


2. Check whether you are looking at the right URL. Redirects, trailing slashes, and www vs. non-www versions are separate cache entries. Make sure the URL in your address bar is exactly the one you purged.


3. Look at the response headers. In developer tools, check whether the page is actually being served from cache (x-cache: HIT, cf-cache-status: HIT, or an age header with a large value). If the headers say the response is fresh from the server, the problem is not caching at all.


4. Rule out the DNS layer. If you recently moved hosts or changed DNS, check that the domain resolves to the new server. Until DNS propagates, some visitors literally load the old server — no cache purge on the new server can fix that.


5. Check for a second caching plugin or a host cache you missed. Two page-caching systems active at once is surprisingly common (a plugin plus the host’s built-in cache). Each needs its own purge.


6. Look for hardcoded or aggressively cached fragments. Some themes and custom code cache parts of pages (menus, sidebars) with their own long lifetimes. A full page-cache purge does not always clear these; check the theme’s settings or custom code.


7. Temporarily bypass the cache entirely. Most caching plugins and hosts offer a bypass or development mode. If the correct content appears with caching bypassed, you have confirmed it is a cache problem — re-enable caching and purge once more, carefully, layer by layer.


8. Consider that it was never a cache problem. Broken updates, failed deployments, file-permission issues, and database problems can all mimic stale-cache symptoms. If bypassing every cache still shows old content, investigate the actual files and database.

Safe Habits So You Never Break a Live Site

Clearing cache is safe when done thoughtfully. These habits keep it that way:

• Clear during low-traffic hours when you need a full purge. Rebuilding the cache consumes server resources; doing it at 3 a.m. instead of peak time keeps the site fast for visitors.


• Exclude what should never be cached. Cart, checkout, account, and login pages must bypass the page cache, or customers will see each other’s data. Set these exclusions once in your caching plugin and your host panel, and verify them after every major change.


• Purge single URLs by default. Reserve full purges for genuinely site-wide changes. Your warm cache is an asset — do not throw it away casually.


• Make one change, then purge, then verify. When updating a live site, work in small steps and check the result in incognito after each purge. If something breaks, you know exactly which change caused it.


• Keep a change log. A simple note of what you changed and when (“updated homepage hero, purged CDN, 14:30”) turns mysterious problems into obvious ones when something looks wrong hours later.


• Do not purge the CDN repeatedly in a short time. Each full purge forces edge servers to hammer your origin. A few purges are fine; dozens in an hour can overload a small server.


• Test on staging first for big changes. Theme overhauls, plugin swaps, and redesigns belong on a staging copy. Purge and verify there, then deploy to live with a single planned purge.


• Know your host’s cache behavior before you need it. Read your host’s caching documentation now, while nothing is broken. When something goes stale at midnight, you want to already know where the purge button is.

Conclusion

Clearing WordPress cache is not a single action — it is a skill of identifying which of the six layers is holding the stale copy and clearing exactly that one. Start with the browser, move through the CDN and page cache, and dig into the object cache and host layers only when the symptoms point there. Purge surgically, verify in incognito, and keep the safe habits above, and cache clearing becomes a boring, reliable routine instead of a frantic guessing game.

And here is the perspective worth keeping: caching exists to make your site fast, and a well-built product handles most of this gracefully on its own. The themes, plugins, templates, and SaaS tools built by HyperDAF’s world-class (#1) expert developers are engineered with sane caching behavior from the start — automatic purges on content updates, proper cache headers, and no stale-content surprises. Understand the layers, use the right method for each one, and your site stays both fast and fresh.