WordPress Changes Not Showing: Cloudways Varnish and WP Rocket, Two Cache Layers

On 10 October 2026, Claude Code made changes to my Jason Career website and finished deploying them, yet visitors still saw the old version. Jason Career is a WordPress site on Cloudways with WP Rocket installed, and clearing the WP Rocket cache changed nothing: Varnish, at the Cloudways server level, was also holding a copy of the old page and had to be cleared separately.

The short version: Cloudways Varnish and WP Rocket are two different cache layers, and clearing only one is not enough. Since that day, Jason Career clears both layers on every deployment, and this rule has been written into Claude’s long-term memory. Cloudflare also sits in front of the site. It does not cache HTML by default, but if you turn on a cache rule, it becomes a third layer. Below, based on the official documentation, I go through what each layer stores, how to clear it and how to tell from the response headers which layer served a page, and I finish with the checklist I use now.

This is a record of how I run my own website, combined with notes from the official Cloudways, WP Rocket and Cloudflare documentation consulted on 17 October 2026. Each provider’s interface, defaults and commands may change, so check the official documentation before acting.

10 October 2026: WP Rocket cleared, visitors still saw the old version

Jason Career is run by Claude Code: it connects to the Cloudways server over SSH and changes the site with WP-CLI, the WordPress command-line tool (the full setup is in Running WordPress Without Knowing SSH). For the combination of hosting, plugins and theme, see How to Build a WordPress E-commerce and Course Site.

What happened that day was simple: the changes were done and the WP Rocket cache was cleared, but visitors still got the old page. Only after Varnish at the Cloudways server level was cleared separately did the changes appear. The fix had two parts:

1. From then on, clear both WP Rocket and Varnish on every deployment.
2. Write this rule into Claude’s long-term memory, so it is not missed in the next session either.

Why didn’t WP Rocket clear Varnish along the way? The notes from that day only recorded the fix, not the cause. WP Rocket’s official documentation lists two situations in which Varnish does not get cleared, covered in the “Cloudways’ Varnish” section below.

Which cache layers a page request passes through

When a visitor opens an article on Jason Career, the request passes through the layers below in order. If an outer layer has the page stored, it returns it directly and the inner layers are never asked.

That Cloudflare does not cache HTML by default comes from Cloudflare’s default cache behavior documentation. I have not yet gone through which cache rules Jason Career actually has turned on in Cloudflare, so this post does not assume whether it caches HTML or not; how to check comes later.

What WP Rocket caches and how to clear it

What WP Rocket stores

According to WP Rocket’s page caching documentation (updated 29 April 2025), page caching is on by default and saves each page as a static HTML file under /cache/wp-rocket/your-domain/, for example index-https.html. When a visitor arrives, the server returns this file directly without running PHP or querying the database.

Another document (updated 24 June 2026) lists WP Rocket’s other cache locations, for example minified CSS and JS in /cache/min/. The cache has a lifespan, and the official explanation gives a default of 10 hours.

When it clears automatically

WP Rocket’s documentation (updated 24 June 2026) says that when you publish or edit a post or page, it clears the cache for that post, the home page and related pages such as category archives.

The trigger here is “editing a post”. For changes that are not post edits, such as changing custom code in Code Snippets or site-wide CSS, the documentation does not say the cache is cleared automatically. All of Jason Career’s customizations live in plugins like this, so after deploying, the cache has to be cleared by hand.

Clearing by hand: the dashboard button or WP-CLI

• Dashboard: WP Rocket’s “Clear and preload cache”.
• WP-CLI: WP Rocket has a WP-CLI extension. The install and clear commands from the official documentation (updated 25 November 2025) are:

# Install WP Rocket's WP-CLI extension
wp package install wp-media/wp-rocket-cli:trunk

# Clear the whole site's cache without asking for confirmation
wp rocket clean --confirm

# Clear a single URL only
wp rocket clean --permalink=<url>

The same document makes a point of saying: this command does not clear the Varnish cache. If you deploy with WP-CLI, you still need to deal with Varnish separately after clearing WP Rocket.

What Cloudways’ Varnish is and how to clear it

On by default, and it does not notice content changes by itself

Varnish is a caching server that sits in front of the website. The official Cloudways blog (updated 26 September 2025) says Varnish is on by default on Cloudways, and in the usual setup every request goes through Varnish first.

The Breeze article in the Cloudways help center says that without Breeze or a similar plugin notifying it, Varnish does not notice by itself that the site’s content has changed. It keeps serving the old content until its lifespan (TTL, 4 hours by default) expires or someone clears it by hand. Breeze is Cloudways’ own caching plugin; Jason Career uses WP Rocket.

Clearing it in the Cloudways dashboard

The steps from the official Cloudways blog (updated 8 November 2023):

1. Log in to the Cloudways platform and open the server.
2. Open “Manage Services”.
3. Click “Purge” on the Varnish row.

The same post also covers clearing Varnish with the Cloudways API (POST /service/varnish, with action set to purge), which requires generating an API key on the platform first. The key is a secret: do not put it in Git or paste it into a chat.

When WP Rocket’s Varnish add-on fails to clear it

WP Rocket’s Varnish documentation (updated 14 January 2026) says that on Cloudways it detects the hosting environment and automatically enables its Varnish add-on, clearing Varnish whenever the WP Rocket cache is cleared. By that account, clearing once should be enough. In practice, the documentation lists two exceptions elsewhere:

Jason Career meets both conditions: Claude Code works through WP-CLI, and Cloudflare sits in front of the site. The notes do not say which one caused the problem on 10 October, and I won’t guess here. Whichever it was, clearing Varnish separately after deploying avoids it.

The Cloudflare layer: HTML is not cached by default

Cloudflare’s documentation states that its CDN does not cache HTML or JSON by default; what it caches by default are file extensions such as CSS, JS, images and fonts. So when you have only changed article content, the problem is usually not Cloudflare. If you changed a CSS or JS file, Cloudflare may still be holding the old file.

If you have turned on a rule to cache HTML in Cloudflare, or the change is to a static file, you need to clear Cloudflare. According to Cloudflare’s purge cache documentation, even the free plan can purge by URL, hostname, tag or prefix, or purge everything for the whole domain, and Cloudflare recommends purging by URL first. The steps for purging by URL:

1. In the Cloudflare dashboard, go to the domain’s “Configuration” page.
2. Under “Purge Cache”, choose “Custom Purge”.
3. For “Purge by”, choose “URL” and paste the URLs to clear (paths are case-sensitive).
4. Confirm and click “Purge”.

If you use WP Rocket’s Cloudflare add-on, WP Rocket’s documentation (updated 11 June 2026) says it usually clears Cloudflare in sync with WP Rocket’s cache. But if you use the Cloudflare Enterprise offered through Cloudways, Cloudways does not provide the API key and zone ID, so WP Rocket cannot sync and you have to clear Cloudflare yourself.

How to tell which layer served the page

After clearing the caches, the most direct way to confirm is to look at the response headers. The steps:

1. Open the page you want to check in a private window, so your login state and the browser’s own cache don’t interfere.
2. Open the developer tools, switch to the “Network” tab and reload.
3. Click the first request (the page itself) and look at “Response Headers”.

Check cf-cache-status first

Cloudflare’s cache status documentation lists what the cf-cache-status values mean:

A HIT means this page came from Cloudflare, Varnish and WP Rocket behind it were never asked, and Cloudflare is what you need to clear. With default settings, HTML pages usually show DYNAMIC, meaning the request did reach Cloudways. Also, Cloudflare’s documentation points out that a successful response to a purge request does not mean the content was actually removed: check that cf-cache-status is no longer HIT after purging.

Then check age

When cf-cache-status is not HIT, look at age. WP Rocket’s documentation says that in a Varnish environment, age is the number of seconds this page has been in the Varnish cache, and it resets to zero after Varnish is cleared. If age is still a large number when you reload after clearing, Varnish was not cleared.

I did not find any other header name for identifying Varnish in the official Cloudways documentation, so here I rely only on the age header described in WP Rocket’s documentation.

The WP Rocket layer

WP Rocket’s page cache is files on the server. The check in the official documentation is to look in the /cache/wp-rocket/your-domain/ folder: after clearing, the files for the affected pages disappear and are only regenerated when someone visits or the cache is preloaded.

Post-deploy cache clearing checklist

Jason Career now clears both WP Rocket and Varnish on every deployment. Adding what the official documentation says, the full order is to clear from the inside out: once an outer cache is cleared, it goes back to the inner layer for the page, and if the inner layer is still stale, the outer layer stores the old version again.

Step 6 was added after 10 October: the rule to clear both layers was written into Claude’s long-term memory, so a deployment in a new session follows the same order. For how I limit what AI can do on the live website, see Running WordPress Without Knowing SSH. More posts are on the AI startup topic page.

FAQ

Why is my WordPress site unchanged after clearing the WP Rocket cache?

Cloudways has another Varnish cache at the server level. Jason Career ran into this on 10 October 2026: clearing WP Rocket alone was not enough, and Varnish had to be cleared separately before visitors could see the change. Since then, both layers are cleared on every deployment.

Doesn't WP Rocket clear Cloudways' Varnish automatically?

WP Rocket's official documentation says that on Cloudways it automatically enables its Varnish add-on and clears Varnish along with its own cache. But the documentation also lists two exceptions: the WP-CLI command wp rocket clean does not clear Varnish, and when a proxy such as Cloudflare sits in front of the site, Varnish may not get cleared.

Where do I clear the Varnish cache on Cloudways?

According to the official Cloudways blog, go to the server's Manage Services in the platform dashboard and click Purge on the Varnish row. Cloudways also has an API that can clear Varnish.

Does Cloudflare cache WordPress HTML pages?

Cloudflare's official documentation says its CDN does not cache HTML by default. Unless you have set up a cache rule, Cloudflare usually does not store your article pages. To check, look at the cf-cache-status response header: only HIT means the page came from Cloudflare's cache.

How can I tell which cache layer served the page a visitor sees?

Open the page in a private window and, in the browser's developer tools, check the response headers of the first request on the Network tab. A cf-cache-status of HIT means it came from Cloudflare. If it is not HIT, look at age: WP Rocket's documentation says it is the number of seconds the page has been in the Varnish cache, and it resets to zero after Varnish is cleared.

Which caches should I clear after deploying WordPress changes?

Clear from the inside out: first WP Rocket, then Cloudways' Varnish, and finally Cloudflare if it caches HTML. Afterwards, confirm with a private window and the response headers, then write this order into your deployment process.