How to manage cache across multiple WordPress sites
Manage cache site by site by clearing each caching plugin, hosting cache, object cache and CDN separately. For several WordPress sites, a central dashboard is faster because it can purge supported caches in bulk and after updates, but you still need to check unsupported layers.
- 01Map every caching layer
- 02Clear each site manually
- 03Use WP-CLI for repeatable purges
- 04Set a safe purge routine
- 05Verify the result across sites
- 06Centralise the fast way
What you need
- Administrator access to each WordPress site
- Access to hosting and CDN controls
- A list of the caching layers used by each site
- SSH and WP-CLI access if you want to automate purges
Map every caching layer
Make a list of each site and record its page-cache plugin, host-level cache, object cache and CDN. Common layers include a WordPress caching plugin, a hosting control-panel cache, Redis or another persistent object cache, and Cloudflare or a different CDN.
Do not assume one purge clears everything. A page-cache purge can leave an old copy at the CDN, while flushing the object cache does not necessarily remove generated page files.
Clear each site manually
Log in to each WordPress dashboard and use the active caching plugin’s own clear or purge action. Then clear any cache exposed by your host and purge the CDN from its dashboard. If the site uses a persistent object cache, flush that only when needed because the cache will have to rebuild.
Open the site in a private browser window and check an updated page. If visitors still see old content, the missed layer is usually the CDN, host cache or browser cache rather than WordPress itself.
Use WP-CLI for repeatable purges
If you have SSH access, run wp cache flush from each WordPress installation to flush the WordPress object cache. In a multisite installation with persistent object caching, this can affect all sites, so avoid running it casually on a busy production network.
WP-CLI does not automatically purge every page-cache plugin, hosting cache or CDN. Add the relevant host or provider commands only after confirming them in that provider’s documentation.
Set a safe purge routine
Purge after publishing major layout or code changes, changing theme or plugin files, and completing updates that affect rendered output. For ordinary content edits, use the cache plugin’s normal invalidation behaviour where possible instead of flushing every cache on every request.
Check dynamic areas such as checkout, cart, account pages, previews and logged-in views. Caching those pages incorrectly can show one visitor another visitor’s content or make a recent order appear missing.
Verify the result across sites
After a bulk purge, check a representative page on every hosting stack rather than assuming the operation succeeded. Confirm the page shows the new content, images and CSS load correctly, and the response is being cached again after the first uncached request.
Keep a short record of the site, cache layers, purge time and any error. This makes Friday-night troubleshooting much quicker when one provider silently rejects a purge request.
Centralise the fast way
For a portfolio managed through MainWP, MainWP Cache Control Extension can detect supported caching solutions, purge selected sites from the Manage Sites area, and automatically purge supported caches after WordPress core, theme or plugin updates. Its documentation lists support for Cloudflare and several caching plugins, including LiteSpeed Cache, WP Rocket, W3 Total Cache and WP Super Cache.
Install and activate the extension on the MainWP Dashboard, enable cache control, save the settings and synchronise the child sites. Select sites and use the bulk cache action, or use the cache widget for an individual site. Configure Cloudflare credentials separately when you want Cloudflare purged as well. Test one site from each hosting setup before relying on bulk actions.
Let MainWP Cache Control Extension do it
Centralized cache clearing and settings across MainWP sites, ideal for agencies managing multiple WordPress installations.
Sources
- developer.wordpress.org /cli/commands/cache/flush/?utm_source=openai
- docs.mainwp.com /add-ons/performance/cache-control-extension?utm_source=open…
Questions
- Does clearing a WordPress plugin cache clear the CDN too?
- No, clearing a WordPress page cache does not necessarily clear a CDN. The plugin may remove generated files on the server while the CDN continues serving its own stored copy. Purge the CDN separately unless your hosting or cache integration explicitly connects the two layers, then verify the changed page from a private browser window.
- Can I clear cache across several sites with WP-CLI?
- Yes, if you have SSH and WP-CLI access, you can run <code>wp cache flush</code> in each installation to flush the WordPress object cache. That command does not automatically clear page-cache plugins, hosting caches or CDNs. On multisite with persistent object caching, one flush can affect all sites, so use it carefully in production.
- Why do visitors still see old content after a cache purge?
- Visitors can still see old content when another cache layer was missed. Check the CDN, host-level page cache, object cache and browser cache, then confirm that the correct site and domain were purged. Preview and logged-in pages may also behave differently because some caching systems bypass or vary the cache for those requests.
- Should cache be cleared after every WordPress update?
- Clear or invalidate cache after updates that change the page output, styles, scripts or generated files, but avoid indiscriminate flushing on every request. Frequent purges slow the site while caches rebuild and can cause problems for dynamic workflows. Use automatic purging only when the cache integration is known to work with that site’s plugins and hosting.
- Is a central cache-management plugin necessary for multiple sites?
- No, it is not necessary if you manage only a few sites and can purge each layer manually or through SSH. A central tool becomes worthwhile when the same task must be repeated across many sites, especially after MainWP updates. It still cannot replace provider-specific checks for unsupported hosts, CDNs or caching systems.