How to Clear WordPress Cache: The Complete Guide!

You fix a typo, swap an image, update a button color, and hit Update. WordPress says everything is saved. Then you open the live page and it looks like you did absolutely nothing.

That moment is usually why people search for how to clear WordPress cache. The maddening part is not that cache exists. The maddening part is that the old version may be sitting in your browser, your caching plugin, your host, your CDN, or a database cache you never knew was there.

The best cache fix is usually the smallest one that matches the symptom. Clearing everything can work, but it also makes the site rebuild more cached files than necessary. Start where the stale copy is most likely hiding.

Start Here

Use the symptom to decide where to begin. This saves you from turning a small stale-browser problem into a full-site purge.

The important thing this table hides is that “cache” is not one place. It is a stack of temporary copies. Your job is to find the copy that is lying to you. If only you see the old version, do not touch the server yet. If everyone sees it, your browser is probably not the whole story.

What Cache Does

Cache is a saved copy of something WordPress would otherwise have to rebuild: a page, image, stylesheet, script, menu, or database result.

Clearing, purging, emptying, deleting, and flushing cache all mean roughly the same thing in this context: remove the saved copy so a fresh one can be created.

Normal cache clearing does not delete your posts, pages, media, users, settings, orders, plugins, or theme. It removes temporary output. The first visit after a purge may feel slower because WordPress, your host, or your CDN has to rebuild the cache. That slowdown is expected. It is not proof that something broke.

Before Clearing

Some “cache problems” are really publishing problems wearing a fake mustache. Check these first:

• Confirm the change was saved or published, not left in draft or preview.
• View the page while logged out, because admins may bypass cache.
• Check the exact thing that changed: text, image, menu, CSS, price, or form.
• Ask whether a plugin, host cache, CDN, page builder, WooCommerce, or object cache is involved.
• Use a WordPress staging site for big theme, plugin, or store changes instead of testing cache fixes on live traffic.

This is also the point to separate safe dashboard buttons from risky work.

Clicking Clear Cache in a plugin is routine. Deleting server files, changing config, deactivating plugins on a live store, or running WP-CLI commands deserves a backup you can actually restore. BlogVault is useful here because it gives you an offsite recovery point before you start touching the parts of the site that are harder to undo.

Hard Refresh

A hard refresh tells your browser to reload the page instead of reusing the files saved on your device. Use:

• Windows or Linux: Ctrl + F5 or Ctrl + Shift + R
• Mac: Cmd + Shift + R
• Any device: open the page in a private or incognito window

If the private window shows the new version, WordPress did its job. Your regular browser was holding onto an old file.

This happens a lot after styling changes. A single stale CSS file can make a fixed page look broken, which is deeply unfair but very normal. If styles are missing in the dashboard itself, treat it as a separate WordPress admin CSS not loading problem rather than only a frontend cache issue.

Browser Cache

Clear your browser cache when the problem appears only for you, or when a hard refresh fixes it for a moment and then the old version comes back.

Look for Clear browsing data, Clear history, or Clear cached files in your browser settings. Choose cached images and files if you do not want to remove cookies, saved logins, or browsing history. Common paths:

• Chrome: Settings > Privacy and security > Clear browsing data
• Firefox: Settings > Privacy & Security > Cookies and Site Data
• Edge: Settings > Privacy, search, and services > Clear browsing data
• Safari: Develop > Empty Caches

Browser cache is local. Clearing your browser will not clear a visitor’s browser. If customers, clients, or teammates still see the old page, move to site-level cache.

Plugin Cache

Clear the WordPress caching plugin when logged-out visitors still see stale content.

Most caching plugins put the button in the admin bar or inside their settings page. The label may say Clear Cache, Purge All, Delete Cache, Empty All Caches, or Delete Cached Pages.

Look in these places first:

• Airlift: Airlift dashboard or WordPress admin cache controls
• WP Rocket: Settings > WP Rocket > Dashboard
• W3 Total Cache: Performance > Dashboard
• WP Super Cache: Settings > WP Super Cache
• LiteSpeed Cache: LiteSpeed Cache > Toolbox > Purge
• WP Fastest Cache: WP Fastest Cache > Delete Cache
• SG Optimizer: Speed Optimizer or SG Optimizer settings
• Cache Enabler: Settings > Cache Enabler

Plugin settings pages often group cache status and cache-clearing controls in the same area.

If the page content is fresh but the design still looks wrong, clear minified CSS/JS too. Minified files are combined, smaller style or script files. They help performance, but an old minified file can keep a broken layout alive after the normal page cache is gone.

Do not run two full-page caching plugins unless a developer deliberately set it up that way. Two cache plugins can turn a simple stale page into a guessing game.

Host Cache

Managed WordPress hosts often cache pages before WordPress fully loads. That is why clearing the plugin cache can feel like pressing the right button and getting no reward.

Open your hosting dashboard and look for Performance, Caching, Speed, Site Tools, Cache Manager, or LiteSpeed Web Cache Manager. Some hosts also add a cache button inside the WordPress admin bar through a must-use plugin, which is a host-managed plugin that loads automatically. You may see host cache controls in places like:

• MyKinsta
• WP Engine User Portal
• SiteGround Site Tools
• Hostinger hPanel
• WordPress.com plugin-enabled plan settings

The exact dashboard path changes by host, so do not waste half an afternoon hunting through menus. If you cannot find it quickly, ask support to purge server cache for the site. Do not delete random server folders because the dashboard button is hard to find.

CDN Cache

A CDN stores copies of pages and files in different locations so visitors load them faster. Cloudflare is the common example, but the same idea applies to other CDN or proxy layers.

Use CDN cache clearing when images, CSS, JavaScript, or whole pages stay stale for visitors even after the WordPress plugin and host cache have been cleared.

For Cloudflare:

• Open Cloudflare and choose your domain.
• Go to Caching > Configuration.
• Select Purge Cache.
• Purge a specific URL when one page or file changed.
• Use Purge Everything only when the issue is broad or hard to isolate.

Specific purges are cleaner. A full purge is not dangerous, but it makes the CDN rebuild more files at once. On a busy site, that can create a short performance dip.

Object Cache

Object cache is different from page cache. It stores database results, often through Redis or Memcached, so WordPress can reuse them quickly.

Use object-cache clearing when the stale thing comes from database-backed data: product stock, dynamic listings, membership states, complex filters, or plugin-generated results. Your host or caching plugin may have an object-cache flush button. Technical users may use:

wp cache flush

That command is one of many WP-CLI commands, which means command-line WordPress. Use it only if you are comfortable with the server environment or a developer/host has told you to.

The plain rule: page cache fixes old pages. Object cache can fix old answers from the database.

WooCommerce Cache

WooCommerce adds a few places where stale data can get expensive fast. A stale blog paragraph is annoying. A stale price, stock number, shipping rate, or cart state can cost money.

• Go to WooCommerce > Status > Tools and read each tool label carefully. You may see options for clearing transients or other cached store data.
• Be careful with customer sessions. Sessions keep customer-specific activity, such as logged-in state and cart data. Clearing active sessions during a sale can log people out or empty carts.
• If the store is busy, pause before clicking anything that affects sessions. This is one of those times where “just purge everything” is not good advice.
• For larger stores, cache troubleshooting often overlaps with WooCommerce performance work because carts, sessions, product queries, and background jobs all affect what visitors see.

For stores, a current WooCommerce backup matters more than a generic safety net because orders, carts, customer data, and product changes are moving while you troubleshoot.

Builder Files

Page builders and optimization plugins can generate their own CSS or asset files. If the text is correct but the layout looks wrong, this is a strong suspect.

Elementor and similar builders often include tools to regenerate CSS or synced files. Optimization plugins may have separate controls for minified CSS and JavaScript. Use this path when:

• buttons look unstyled
• fonts changed back
• spacing looks wrong
• mobile layout is stale
• a page builder edit saved but the frontend design did not update

The visible problem is “WordPress ignored my design.” The hidden problem may be one stale generated file. For major builder, theme, or plugin changes, make the change in a test site first and push it live only after the frontend looks right.

Manual Clearing

Manual cache clearing is the last-resort path, not the heroic first move.

Use it only when dashboard controls are unavailable, host support recommends it, or a file-based cache is stuck. Before you do it, back up your WordPress site. BlogVault fits this moment because you can restore the site if a manual cleanup removes the wrong file or exposes a deeper issue.

For file-based cache, connect through FTP, SFTP, SSH, or your hosting file manager. Look for:

wp-content/cache/

Delete the contents inside that folder, not the folder itself.

This will not clear every cache type. It may not touch Redis, Memcached, Varnish, Nginx FastCGI cache, host-managed cache, or CDN cache. Those layers live elsewhere.

Also, do not create a public PHP script to flush cache and leave it on the server. That turns a troubleshooting shortcut into a security problem.

Check Results

Stop clearing cache once you can prove the stale item is gone. Check in this order:

• Open a private or incognito window.
• View the page while logged out.
• Try another browser if browser cache was likely.
• Try another device or network if host or CDN cache was likely.
• Check the exact changed item: text, image, layout, menu, price, form, or timestamp.
• Use the browser Network tab if you are technical.

If the new page appears while logged in but not logged out, suspect plugin, host, or CDN cache. If the page is fresh but store data is wrong, check WooCommerce transients, sessions, or object cache.

Verification matters because repeated purging can become a ritual. You want a diagnosis, not a button you keep pressing because it feels productive.

Still Stale

If the old version keeps coming back, stop and check whether cache is really the problem. Work through these:

• Confirm you edited the right page, template, product, menu, widget, reusable block, or builder layout.
• Check whether the change is published, not only saved as a draft.
• Clear plugin, host, and CDN cache in sequence.
• Clear generated CSS/JS if the content is fresh but the design is wrong.
• Look for multiple caching or optimization plugins.
• Ask your host about Varnish, Redis, Memcached, Nginx FastCGI, LiteSpeed, file permissions, and relevant WordPress log files.
• Review recent migrations, restores, or cleanup work.

Cache is often guilty. It is not always guilty.

If a site was recently migrated or restored, old generated files and permissions issues can survive a normal plugin purge. If a theme template is overriding the page, no amount of cache clearing will make the wrong template show the right thing.

Avoid Full Purges

Purge everything only when the stale issue is broad or you cannot identify the file or page. Avoid a full purge when:

• only one page, image, CSS file, or script changed
• your CDN supports a specific URL purge
• the site is under heavy traffic
• WooCommerce customers are actively shopping
• cache preloading is running
• the problem may be an unsaved edit, wrong template, or plugin conflict

FAQs

Final Advice

The fastest way to clear WordPress cache is not to clear every cache you can find. It is to follow the stale copy.

Start with your browser. Move to the WordPress caching plugin. Then check host cache and CDN cache. Use object cache, WooCommerce tools, builder regeneration, or manual file cleanup only when the symptom points there.

Most cache clearing is routine and safe from normal dashboards. The risky part starts when you touch server files, command-line tools, customer sessions, or configuration. Back up first, change the smallest thing that makes sense, and verify before you keep purging.

Written by

Shivani M

Shivani enjoys crafting guides that make every aspect of using WordPress simple and easy to follow. When she's not glued to her laptop, you can find her buried in a good book or occasionally, painting.