How to Clear Cloudways Cache Properly: Complete Guide

You updated your website, yet the old version still appears. Learning how to clear Cloudways cache properly can fix this issue within minutes.

The safest option is usually Purge Site Cache. It clears the cache for one selected application. If that fails, you may also need to clear Breeze, Varnish, Cloudflare, or your browser cache.

Interested in trying the platform? Try Cloudways here.

Quick Answer: The Safest Way to Clear Cloudways Cache

For most websites, start with the application-level purge tool.

Follow these steps:

Sign in to your Cloudways account.
Open Servers from the top menu.
Select the server that hosts your website.
Click the globe icon to view its applications.
Choose the website you want to refresh.
Open Application Settings.
Select the General tab.
Find Purge Site Cache.
Click Purge.
Open your website in a private browser window.

This method targets the selected application. It is safer than clearing Varnish for the whole server.

Your first visit may feel slower after the purge. That is normal. Cloudways must create and store fresh copies of each page.

At a glance comparison

Cache type	Where you clear it	Best time to use it	Possible reach
Purge Site Cache	Cloudways Application Settings	One website has stale content	Selected application
Breeze cache	WordPress dashboard	WordPress pages look outdated	Selected WordPress site
Varnish cache	Breeze or Cloudways	Server cache serves old pages	One site or entire server
Cloudflare cache	Breeze, Cloudways, or Cloudflare	Remote visitors see old files	Connected domain
Redis or Memcached	Server tools or WordPress	Dynamic data remains outdated	May affect several applications
Browser cache	Your browser	Only you see the old version	Your device

Start with the smallest purge that can fix the problem. A full server purge should not be your first move.

Understanding the Cloudways Cache Layers

Cloudways can use several cache layers at once. Each layer stores a different type of data.

This setup makes your site fast. It can also make stale content harder to track down.

Application or page cache

A page cache stores a ready-made copy of a page. The server can send that copy without building the page again.

For example, WordPress may need to:

Load the theme
Run plugin code
Read the database
Build the page layout
Return the final HTML

A cached copy skips much of that work. This can cut page load time and reduce server work.

Breeze often manages this layer on Cloudways WordPress sites. Other cache plugins can do the same job.

If you edit a post, the plugin should replace the old cached copy. However, a setting or plugin conflict may stop that process.

Varnish server cache

Varnish is a full-page cache at the server level. It can serve a page before WordPress starts working.

This is why clearing Breeze does not always fix stale content. Varnish may still hold an older page.

Think of Varnish as a receptionist. It answers common requests before they reach the main office.

Varnish works well for:

Blog posts
Landing pages
Category pages
Public product pages
Other pages shared by all visitors

It should not cache private or changing pages without care. Examples include carts, checkout pages, and user accounts.

Redis or Memcached object cache

Redis and Memcached store data that your site uses often. This data may include database results, settings, or generated objects.

An object cache is not the same as a page cache. It stores pieces of data rather than full web pages.

For example, it may store:

Navigation menu data
Product details
WordPress settings
Database query results
Plugin-generated data

Object caching can reduce database work. However, stale objects may sometimes show old dynamic data.

Do not restart Redis or Memcached first. Clear the page and server caches before touching these services.

Cloudflare or CDN cache

A content delivery network stores files near your visitors. It is often called a CDN.

It may cache:

Images
CSS files
JavaScript files
Fonts
Downloadable files
Full pages, based on its rules

Cloudflare may still serve an old file after you clear Cloudways. That happens because its cache sits outside your main server.

Cloudways Cloudflare Enterprise can connect with the platform and Breeze. An external Cloudflare account may need its own purge.

Browser cache

Your browser also saves files on your device. It may keep an old image, style file, or script.

This can make a successful Cloudways purge look like a failure.

A quick test is simple:

Open a private or incognito window.
Visit the edited page.
Check whether the new version appears.
Test another browser if needed.
Try a phone using mobile data.

If other devices show the update, your browser cache is the likely cause.

Before You Clear the Cache

Cache clearing is usually safe. Still, a few checks can prevent confusion.

Use this checklist first:

Save any page or post you are editing.
Complete theme and plugin updates.
Confirm that you selected the right server.
Confirm that you selected the right application.
Check whether the site is live or staging.
Take a backup before major code changes.
Note which websites share the server.
Avoid a full purge during peak traffic.
Record any current cache exclusions.

Do not restart random server services. Restarting PHP or your database is not a normal cache-clearing step.

Application purge versus server Varnish purge

These two options can have a different reach.

Application purge

Targets one selected website
Clears its connected cache layers
Is the safest starting point
Has less effect on other sites

Server Varnish purge

Clears the server-level Varnish cache
May affect every application on that server
Causes more pages to rebuild
Is better for server-wide problems

If you manage several websites, this difference matters. One careless click may slow every site for a short time.

Method 1: Purge All Cache Layers for One Cloudways Application

This is the best first method for most users. It keeps the purge focused on the affected website.

When to use this method

Use Purge Site Cache when:

An edited page still shows old text
A new logo does not appear
Your menu still shows an old link
A product page displays old content
A theme update changed the design
A plugin update changed the front end
You replaced an image with the same filename
You want to avoid purging other websites

This method is also useful after moving changes from staging to production.

Step-by-step instructions

Use this path in the newer Cloudways interface:

Servers > Select Server > Select Application >

Application Settings > General > Purge Site Cache

Here is the full process:

Log in to the Cloudways Platform.
Click Servers in the main menu.
Choose the server that hosts your site.
Click the globe icon beside that server.
Select the correct application.
Open Application Settings.
Stay on the General tab.
Scroll to Purge Site Cache.
Click Purge.
Wait for the process to finish.
Check your site in a private window.

Cloudways may ask you to approve the action. Read the message before you continue.

What this button clears

Purge Site Cache is built to clear the relevant cache layers for one application. The exact layers depend on your setup.

These may include:

Application-level cache
Varnish cache for the application
Redis-related cache
Connected Cloudflare cache

A simple WordPress site may not use every layer. The purge tool deals with the layers linked to that application.

That makes it easier than opening several control panels. It also lowers the risk of missing one cache layer.

What to expect afterward

Your site may respond more slowly for a short time. This is called a cold cache.

The first visitor asks WordPress to build the page again. Cloudways then stores the fresh result for later visits.

You may notice:

A slower first page view
A brief rise in server work
Faster repeat visits
Fresh pages appearing at different times

Large sites take longer to rebuild. They have more posts, products, and archive pages.

Avoid clicking Purge again and again. Repeated purges stop the cache from rebuilding.

If speed remains poor, cache may not be the main problem. Use this guide to reduce initial server response time in WordPress.

Method 2: Clear Breeze Cache from WordPress

Breeze is Cloudways’ WordPress cache plugin. It can manage page cache, file changes, and Varnish integration.

This method is handy when you can access WordPress but not Cloudways.

When to use Breeze

Clear Breeze cache after:

Editing a post or page
Changing a widget
Updating a menu
Adjusting theme settings
Editing a page-builder layout
Changing a plugin’s display settings
Replacing an image or file
Testing a cache rule

You can also use it when one WordPress site has a problem. It avoids a server-wide purge.

Suggested steps

The menu names can vary by Breeze version. In most cases, use this path:

WordPress Dashboard > Settings > Breeze > Purge Cache

You may also see a Breeze menu in the top WordPress toolbar.

Follow these steps:

Sign in to your WordPress dashboard.
Open Settings.
Click Breeze.
Find the cache purge option.
Select Purge All Cache or the closest matching choice.
Wait for the success message.
Check the edited page while logged out.

The toolbar is often faster. Hover over the Breeze option and select the available purge command.

Purge Varnish through Breeze

Breeze can also send a purge request to Varnish.

Use this path:

WordPress Dashboard > Settings > Breeze >

Varnish > Purge Varnish Cache

To clear Varnish:

Open the Breeze settings.
Select the Varnish tab.
Check that the Varnish server field is already set.
Click Purge Varnish Cache.
Save your settings if you changed anything.
Test the page in a private window.

Keep Auto Purge Varnish enabled in most cases. It clears old cached pages after common WordPress actions.

These actions may include:

Publishing a post
Updating a page
Posting a comment
Editing public content

Automatic purging saves time. It also reduces stale-page problems.

Do you need Breeze if Cloudways already uses Varnish?

Breeze and Varnish have different jobs. They can work together.

Breeze works inside WordPress. It can handle:

WordPress page cache
Browser cache rules
File compression
CSS and JavaScript settings
Cache exclusions
Database cleanup
Varnish purge requests
CDN settings

Varnish works in front of WordPress. It serves ready-made pages from the server.

You do not need two WordPress full-page cache plugins. Running Breeze beside another page-cache plugin may cause conflicts.

If you prefer another plugin, check its Cloudways setup. Disable overlapping features where needed.

Method 3: Purge Varnish for the Entire Server

A server-wide Varnish purge is a wider action. Use it with care.

It can help when several applications have stale pages. It can also help after a server-level change.

When to use it

Consider a full Varnish purge when:

Several websites show stale content
An application purge did not work
You changed a server-level setting
A Varnish rule changed
You fixed a server configuration issue
You need every Varnish page rebuilt

Do not use it for one small text edit. The application purge is better for that task.

Steps

Use this Cloudways path:

Servers > Select Server > Manage Services >

Varnish > Purge

Then complete these steps:

Open your Cloudways account.
Select Servers.
Choose the correct server.
Open Manage Services.
Find Varnish.
Click Purge.
Approve the action if asked.
Check the affected applications.

Make sure you click Purge, not Stop or Disable.

Critical warning

A server may host several websites. A Varnish purge can remove cached pages for all of them.

This can cause a short rise in:

CPU use
PHP work
Database requests
Page generation time
First-visit load time

Busy stores and membership sites need extra care. Run broad purges during a quieter period when possible.

Before changing your server setup, it helps to know the platform type. See this Cloudways Flexible versus Autonomous comparison.

Purge versus restart

A purge empties stored Varnish pages. The Varnish service keeps running.

A restart stops and starts the service. That is a much broader action.

Use Purge when:

Pages are outdated
Files changed
A cache rule was fixed
You need fresh page copies

Consider Restart only when:

Varnish is not responding
The service reports an error
Support tells you to restart it
A known service fault needs a reset

Do not disable Varnish as a long-term fix. Find the bad rule or missing exclusion instead.

Method 4: Clear Cloudflare or CDN Cache

Cloudflare sits between your visitors and Cloudways. It may keep serving an old file after your server cache is fresh.

This often affects images, style sheets, and scripts. Full-page cache rules can also store old HTML.

Signs the CDN is serving stale content

Look for these clues:

The Cloudways application URL looks correct.
The live domain still shows old content.
Some visitors see the update.
Other visitors still see the old page.
An old image remains after several purges.
Layout changes appear only when logged in.
Bypassing Cloudflare shows the new version.
An old CSS or JavaScript file still loads.

Location-based differences are another clue. CDN files are stored at many remote locations.

One location may update before another.

Cloudways Cloudflare Enterprise

Cloudways Cloudflare Enterprise links Cloudflare tools with your application. Your purge options may appear inside Cloudways or Breeze.

Start with Purge Site Cache for the application. It may clear the connected Cloudflare cache as part of the process.

You can also check the Cloudflare section in Breeze. Some setups support an automatic purge when WordPress content changes.

Use automatic purge only with a proper setup. Poor rules can clear too much cache after each small edit.

If you are comparing plans and add-ons, read this guide to Cloudways pricing.

External Cloudflare account

If you connected Cloudflare yourself, sign in to that Cloudflare account.

The labels may change over time. The usual process is:

Open your Cloudflare dashboard.
Select the correct domain.
Open its caching controls.
Choose a selective purge if available.
Enter the affected page or file URL.
Run a full purge only when needed.
Test the site in a private window.

A selective purge removes one page or file. It keeps the rest of your cache warm.

A full purge removes everything. That creates more server work and slower first visits.

For a changed image, purge the exact image URL. If possible, use a new filename instead.

For example:

old-logo.webp

new-logo-2026.webp

A new filename avoids the old cached copy. This method is often more reliable than repeated purges.

Method 5: Flush Redis or Memcached Cache

Redis and Memcached store reusable data in memory. They can make database-driven parts of your site faster.

They are not the usual cause of an old public page. Treat them as a later troubleshooting step.

When object cache may be involved

Object cache may be involved when:

A dynamic block shows old data
Product stock looks outdated
A menu keeps an old item
User account data appears wrong
A plugin stores lasting values
Database-driven filters show old results
Page and CDN purges did not help
The HTML is fresh but its data is not

First, check whether the wrong data exists in WordPress. A cache purge cannot fix an incorrect saved value.

Safer troubleshooting order

Follow this order:

Test the page while logged out.
Clear your browser cache.
Purge the WordPress page cache.
Use Cloudways Purge Site Cache.
Purge the CDN cache.
Clear page-builder files.
Test the dynamic feature again.
Flush object cache if signs still point there.
Restart the service only if it has failed.

This order starts with low-risk steps. It saves wider actions for later.

Warning

Redis and Memcached may serve several applications. Restarting either service can affect more than one site.

A restart also removes stored data. Each application must rebuild that data through normal use.

Do not permanently turn off object cache to hide a fault. The true cause may be:

A plugin conflict
A bad cache key
A missing cache clear event
Custom code
A database update that skipped WordPress
A stale scheduled task

If you are not sure, ask Cloudways support to check the service. Give them the exact page, time, and change you made.

Clear Cache Using WP-CLI

WP-CLI is a command tool for WordPress. You run it through an SSH connection.

This method suits developers and site managers. It is also useful for scripts and planned maintenance.

To clear the WordPress object cache, run:

wp cache flush

Run the command from the correct WordPress folder. Check the current path before you start.

The command clears the WordPress object cache. It does not always clear:

Varnish
Cloudflare
Browser cache
Another plugin’s file cache
Generated page-builder files

You may need separate commands for those layers.

Breeze may also add its own WP-CLI commands. Check commands available on your installed version:

wp help

You can also search the command list:

wp cli cmd-dump | grep -i breeze

Do not paste unknown commands into a live server. Read the command help first.

A safe workflow looks like this:

Connect through SSH.
Move to the application’s public folder.
Confirm that WordPress loads.
Run the needed cache command.
Check for errors.
Test the site while logged out.
Purge Varnish or CDN cache if needed.

The Correct Cache-Clearing Order

Clearing every cache at once makes testing harder. You will not know which layer caused the problem.

Use this order instead:

Test in a private window.
This rules out many browser cache issues.
Clear the WordPress page cache.
Use Breeze or your active cache plugin.
Purge the selected Cloudways application.
Use Purge Site Cache under Application Settings.
Purge Cloudflare or your CDN.
Do this if remote files remain stale.
Regenerate page-builder files.
Builders may create their own CSS files.
Check dynamic data.
Confirm that WordPress stores the correct value.
Flush object cache.
Do this only if Redis or Memcached seems involved.
Purge Varnish for the whole server.
Use this for wider server issues.
Contact support.
Share the affected URL and steps you tried.

This order protects other websites. It also makes the root cause easier to find.

How to Confirm the Cache Was Cleared

A success message only confirms that a purge request ran. You should still check the result.

Start with these tests:

Open the page in a private window.
Test another browser.
Test a phone on mobile data.
View the page while logged out.
Compare the application URL and live domain.
Check the visible edit.
View the page source.
Test from another location if possible.

You can also add a harmless query string:

https://example.com/page/?cache-test=1

Some cache systems treat that as a new request. However, the result depends on your cache rules.

Optional advanced checks

Open your browser’s developer tools. Select Network, reload the page, and inspect the main request.

Useful headers may include:

Age

Cache-Control

CF-Cache-Status

X-Cache

Here is what they can tell you:

Age: How long a stored response has existed
Cache-Control: Rules for storing the response
CF-Cache-Status: Cloudflare’s cache result
X-Cache: A general cache hit or miss result

Header names vary by setup. A missing header does not prove that caching is off.

Also compare the HTML source. Search for a sentence or class name that changed.

If the fresh text exists in the source but not on the page, the issue may involve CSS or JavaScript.

Cloudways Cache Cleared but Changes Still Do Not Show

Sometimes cache is not the only issue. Generated files and wrong environments can cause the same symptom.

Work through the checks below.

Clear page-builder files

Page builders often create separate style files. Those files may remain old after a normal cache purge.

For Elementor, try:

Open the WordPress dashboard.
Go to Elementor’s tools.
Find the option to regenerate files or CSS.
Run the tool.
Clear Breeze.
Purge the Cloudways application.
Test the page while logged out.

Other builders use similar tools:

Divi can create static CSS files.
Bricks can generate CSS files.
Performance plugins may combine builder styles.
Themes may build their own asset files.

Do not keep regenerating files without testing. One clean cycle should be enough.

Check CSS and JavaScript optimization

File optimization can create new cached assets. These may contain old code.

Common features include:

CSS minification
JavaScript minification
File combination
Delayed scripts
Removed unused CSS
Critical CSS generation

Turn off one feature at a time for testing. Then clear all related caches.

If the problem goes away, adjust that feature’s exclusions. Do not disable every speed setting forever.

Rename static files

Browsers and CDNs may hold files for a long time. A new filename forces a new request.

Instead of replacing this file:

hero-image.webp

Use:

hero-image-v2.webp

Developers can add a version to a file URL:

style.css?ver=2.1

WordPress can also add a file’s edit time as the version. This makes changed assets easier to refresh.

Check the correct environment

You may be editing one site and viewing another.

Check for:

A staging site
A live site
A temporary Cloudways URL
A mapped domain
A development subdomain
A second application on the server
A local WordPress copy

Look at the browser address bar. Then check the site address inside WordPress.

Also confirm the application name in Cloudways. Similar names can be easy to mix up.

Check cache exclusions

Dynamic pages often need cache exclusions.

Common examples include:

Cart
Checkout
My Account
Login
Search results
Personalized dashboards
Form confirmation pages
Member-only pages

An exclusion tells the cache not to store a shared copy.

Check exclusions in Breeze, Varnish rules, and Cloudflare. One layer may still cache the page.

Do not exclude your entire site as a quick fix. That removes much of the speed benefit.

Check other caching plugins

Two page-cache plugins may compete with each other. One plugin may clear its files while the other keeps serving old pages.

Check your plugins for:

Breeze
WP Rocket
W3 Total Cache
LiteSpeed Cache
WP Super Cache
Cache Enabler
Hosting cache plugins

You should normally use one main WordPress page-cache plugin.

Optimization plugins can work together in some cases. Yet overlapping cache and file features need careful setup.

When Should You Clear Cloudways Cache?

Clear cache after a change that affects what visitors should see.

Good reasons include:

Major page edits
Theme changes
Menu updates
CSS changes
JavaScript changes
Plugin updates that affect output
New product prices
Changed stock rules
Replaced images
Domain changes
Site migration
Cache rule changes
Stale-content troubleshooting

You may not need a manual purge after every post update. Automatic cache clearing often handles normal publishing tasks.

When not to clear it

Do not clear Cloudways cache:

Every few minutes
On a fixed daily plan without need
After each small admin task
To fix poor code
To hide a plugin conflict
During peak traffic without a good reason
Each time you check website speed

Cache clearing does not make a site faster by itself. It removes the fast, ready-made copies.

Your server must then build those copies again.

If your current host struggles with normal traffic, caching may hide a larger limit. This shared hosting versus cloud hosting guide explains the key differences.

Does Clearing Cache Affect Website Performance?

Clearing cache does not remove your website data.

It does not delete:

Posts
Pages
Products
Orders
Users
Media files
Theme settings
Plugin settings

It only removes temporary stored copies.

Still, performance may dip for a short time. WordPress must rebuild each missing page or object.

The effect depends on:

Website size
Visitor count
Plugin load
Theme weight
Database speed
Number of products
Number of cache layers
Server resources

A small blog may recover at once. A large store may take longer.

For busy sites, purge only changed URLs when your tools support it. You can also warm key pages after a full purge.

Cache warming means visiting key pages to create fresh copies.

Start with:

Home page
Main category pages
Popular posts
Top landing pages
Key product pages

Do not run a large crawler without limits. It may create a sudden load spike.

Best Practices for Cloudways Cache Management

Good cache management means clearing less, not more.

Use these practices:

Start with application-level purging.
Avoid server-wide purges for one page.
Keep Auto Purge Varnish on when suitable.
Exclude carts, checkout pages, and accounts.
Use one main WordPress page-cache plugin.
Give changed files a new version.
Purge exact URLs where possible.
Test while logged out.
Keep a list of active cache layers.
Schedule large purges during quiet periods.
Warm important pages after a full purge.
Check staging changes before publishing.
Track plugin conflicts after updates.

It also helps to document your cache setup.

Your notes might look like this:

WordPress page cache: Breeze

Server page cache: Varnish

Object cache: Redis

CDN cache: Cloudflare Enterprise

Browser cache: Set through Breeze

Dynamic exclusions: Cart, checkout, account

This short list can save hours during an urgent fix.

Frequently Asked Questions

Does Cloudways automatically clear the cache?

It can clear some cache layers after common WordPress actions. This depends on your plugins and settings.

Breeze can automatically purge Varnish after you update public content. Keep Auto Purge Varnish enabled unless it causes a known issue.

Cloudflare and other CDN rules may work separately. Check their purge setup as well.

What is the difference between Purge Site Cache and Varnish Purge?

Purge Site Cache focuses on one selected application. It may clear several linked cache layers.

A server-level Varnish Purge has a wider reach. It may clear Varnish for every application on that server.

Use Purge Site Cache first for a single website.

Will clearing Cloudways cache delete my website?

No. Cache clearing removes temporary copies, not your source content.

Your posts, pages, images, orders, and users remain in place.

A backup is still wise before major updates. Yet a normal purge does not erase website data.

Why is my website slow after clearing the cache?

Your site has a cold cache. The server must rebuild pages as visitors request them.

The slowdown should ease as new cached copies form.

If it stays slow, check PHP work, database time, plugins, and server size.

Do I need to clear both Breeze and Varnish?

Not always. Breeze can send a purge request to Varnish.

Cloudways’ Purge Site Cache can also clear linked layers for one application.

Clear both during troubleshooting if you are unsure. Then check your automatic purge settings.

How often should I clear Cloudways cache?

Clear it after changes that are not showing. You can also clear it during planned troubleshooting.

Do not purge it on a daily schedule without a reason. Frequent purges can increase server work.

Can I clear the cache for just one website?

Yes. Select the application and use Purge Site Cache.

Avoid the server-wide Varnish purge unless other applications also need it.

Can I clear the cache for one page only?

That depends on your cache plugin and CDN. Some tools support purging one URL.

A single-page purge is better for a small edit. It keeps the rest of your cache warm.

If a selective option is not available, use the application-level purge.

Why do logged-in users see a different version?

Many cache systems treat logged-in visitors in a different way. They may bypass the public page cache.

This protects private data and lets editors see recent changes.

Always test the public version while logged out. A private browser window works well.

Should I restart Varnish, Redis, or Memcached?

Not as your first step. Use a normal purge or flush first.

Restart a service only if it has failed or stopped responding. If unsure, ask support to review it.

A restart may affect every application that uses that service.

Final Takeaway

Knowing how to clear Cloudways cache properly starts with choosing the smallest useful purge.

Use this quick rule:

One website has stale pages: Use Purge Site Cache.
WordPress content looks old: Clear Breeze.
Several server applications are affected: Purge server Varnish.
Remote visitors see old files: Clear Cloudflare or your CDN.
Dynamic data remains stale: Check Redis or Memcached.
Only your device shows the old page: Clear browser cache.
Design changes remain missing: Regenerate page-builder files.

Start at the browser and work inward. Save server-wide actions for last.

This approach keeps your site fast. It also helps you find the cache layer that caused the issue.