WP Rocket hosting where one cache owns the page.
WP Rocket on a host that already caches pages means two layers deciding what is stale. The fix is not removing the plugin - it is deciding which layer serves the page.
Everything WP Rocket asks of a host that already caches.
The plugin does far more than page caching, and that is the part worth keeping.
One layer serves the page
Page caching moves to the platform, where it runs in front of PHP rather than inside it. Two caches in front of one site means two things deciding what is stale, and whichever purged last wins.
The optimisation features stay on
Lazy loading, script delay, CSS handling and font preloading are the parts of WP Rocket no server cache replaces. Switching the whole plugin off to avoid a conflict throws those away too.
Purge wired through
Clearing the cache from wp-admin clears the platform cache as well, so a purge does what the button says rather than appearing to work.
Cleanup on a real scheduler
Its database cleanup runs on WP-Cron, which on a quiet site does not fire when it believes it does. That moves to the platform scheduler.
Preload kept in its lane
WP Rocket's preloader can hit a site harder than its visitors do. It is rate-limited so a cache warm never competes with the people the cache is for.
See which layer answered.
The confusing part of running a caching plugin on a caching host is not knowing which one served the page you are looking at. That should not be guesswork.
- Cache layer visible per response
- Purge status across both layers
- One-click admin login
- Restore any daily backup from the dashboard
A cached page, answered once.
A page cached by a plugin is still a PHP process starting up to hand you a file. Cached at the edge, WordPress is not involved at all.
What we change for WP Rocket
These differ from a standard WordPress site on the same plan, and each follows from a caching plugin running on a caching platform.
| Setting | What we do | Why |
|---|---|---|
| WP Rocket page caching | Switched off, with the platform cache serving pages instead | Two page caches in front of one site means two things deciding what is stale, and the one that wins is whichever purged most recently. |
| Optimisation features | Left enabled. Lazy load, script delay, CSS and font handling | These are the parts of the plugin no server-side cache replaces, and disabling the whole plugin to resolve a conflict quietly loses them. |
| Cache purging | Wired so a purge from wp-admin clears the platform cache too | Otherwise clearing the cache appears to succeed and changes nothing a visitor actually sees. |
| Database cleanup | Moved from WP-Cron to the platform scheduler | Its cleanup schedule depends on traffic to fire, so on a quiet site it runs late or not at all. |
| Preload crawler | Rate-limited against the site's own capacity | The preloader can generate more requests than the site's visitors do, and on a small plan it competes with them for workers. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Do I have to uninstall WP Rocket?
Which cache actually serves my visitors?
If I clear the cache in WP Rocket, does it clear yours?
Will my WP Rocket licence still be worth paying for?
Does the preload feature cause problems?
Run WP Rocket on a host that knows which layer owns the page.
Free migration, one cache serving responses, and every optimisation feature still doing its job.