MainWP Cache Control - WordPress Plugin

Guide to Setting Up and Using MainWP Cache Control

MainWP Cache Control is not meant to speed up a single page. Its job is different: it lets you manage cache clearing across multiple WordPress child sites from the MainWP Dashboard. In this guide, we will look at how to make the extension part of your maintenance workflow: what to check before installation, where to enable global settings, when to use manual clearing, how to configure Cloudflare, and how to confirm that visitors are seeing the latest version of the site after updates.

This guide is written for an administrator, freelancer, or agency that already has a MainWP Dashboard and connected child sites. If you are just getting familiar with MainWP, it helps to understand the overall setup first: the Dashboard is installed on a separate WordPress site, MainWP Child runs on the managed sites, and extensions add individual features to the central panel.

This article does not cover buying a subscription, bypassing a license, or sharing secrets. Cloudflare and MainWP API keys are discussed only from a secure configuration standpoint: where they are used, why they should not be sent to contractors unless necessary, and how to reduce the risk of mistakes when clearing cache in bulk.

What Problem Cache Clearing from MainWP Dashboard Actually Solves

WordPress caching usually works in several layers. A child site may have a cache plugin, the server may use object or server-side cache, and Cloudflare or another CDN may sit in front of the site. As long as everything is stable, that helps visitors load pages faster. The problem starts after updating WordPress core, a theme, or a plugin: HTML, CSS, JavaScript, generated pages, and CDN copies may continue to live longer than the actual change.

If an administrator manages one site, they can open the admin panel and click the clear button in the specific plugin. With a network of several dozen sites, that becomes a routine of its own: update the plugin, open the site, clear the cache, check the page, repeat. MainWP Cache Control is designed to eliminate exactly that routine. The extension adds both automatic and manual cache clearing to MainWP for child sites after update operations run from the Dashboard.

The main value of the extension is that it ties updates and purges into one controlled cycle. You are not clearing cache just for the sake of it. You are reducing the risk of a situation where the code has already been updated, but the visitor is still seeing the old layout, the old script, or the old cart page.

What the Official Documentation Confirms

The official MainWP page and documentation describe several key capabilities: automatic clearing after WordPress Core, theme, or plugin updates through the MainWP Dashboard; manual clearing for selected sites from the MainWP > Sites > Manage Sites table; Cache Control widgets on the main Overview page and on the Overview page for an individual child site; support for Cloudflare and a range of popular caching plugins.

The documentation also notes that the Manage Sites page can show information about the last automatic purge and the detected caching solution. That matters for troubleshooting: the administrator sees not only an action button, but also evidence of what the extension detected on the site and when the last automatic purge ran.

What It Is Not

MainWP Cache Control does not replace a full optimization plugin. It should not be treated as an alternative to minification settings, deferred script loading, image optimization, server-side caching, or CDN rules. Its role is narrower: it gives MainWP Dashboard a command layer that clears supported cache after updates or by manual admin command.

The practical takeaway is simple: the best cache settings still belong in the specific caching plugin or in Cloudflare, while MainWP Cache Control handles the moment when those layers need to be reset. If a child site has no supported caching solution at all and no Cloudflare API configured, the extension cannot magically clear an unknown cache layer.

Who This Extension Is For and When It May Be Unnecessary

This extension is especially useful for anyone managing a group of sites with regular updates. The more child sites you have, the higher the cost of manual cleanup after each maintenance cycle. If the sites use similar stacks and supported caching solutions, MainWP Cache Control helps make the process predictable: update, clear, sync, verify.

For an agency, this is also a support quality issue. Clients rarely ask whether the cache was cleared. They notice other things: "the button did not change," "the homepage still shows the old banner," or "the form is still loading the old script after the update." Complaints like that do not always mean the update failed. Sometimes the new files are already on the server, but the user is still getting an old copy. Centralized purging reduces the number of these false alarms.

Good Use Cases

• You update WordPress core, themes, and plugins through MainWP Dashboard and want cache to be reset automatically after those operations.
• Your child sites use supported solutions such as Cloudflare, LiteSpeed Cache, WP Fastest Cache, W3 Total Cache, WP Rocket, WP Super Cache, Autoptimize, WP Optimize, Cache Enabler, or other plugins from the MainWP list.
• You need to clear cache manually across a group of sites after a large template change, a plugin setting update, or publishing important content.
• You want the sites table to show which caching solution was detected and when the last automatic purge ran.

When to Think Twice

MainWP Cache Control may be unnecessary if you have only one site, updates are done manually in that site's admin panel, and the cache is already being cleared correctly by the plugin itself. In that case, the extra central layer does not add much value. The extension also will not solve a slow site caused by a heavy theme, poor hosting, unoptimized images, or a bloated database. Those problems require other tools: performance profiling, plugin optimization, a CDN, object cache, or query auditing.

Another edge case is custom hosting-level cache that is not on the supported list and is not managed through the Cloudflare API. In that situation, the extension may not detect the layer you need. Before enabling it on a production network, test at least one site of each type: see which caching plugin is detected, whether the manual clear button works, and whether the result actually changes on the public side.

What to Check Before Installing It on the Dashboard

Preparation matters not because the extension is hard to install, but because cache is tied to updates, site availability, and external APIs. It is better to verify the basics once than to untangle later why some sites cleared successfully, others stalled, and Cloudflare returned an error.

MainWP Base Infrastructure

Make sure MainWP Dashboard is installed on a separate WordPress site and that child sites are connected through MainWP Child. Official MainWP materials recommend keeping the Dashboard as a management hub rather than using it as a busy public site loaded with unnecessary plugins. That reduces conflicts and makes bulk operations more predictable.

Then open the sites list and run a sync. In MainWP, this is not just a formality: sync requests pull data about child sites, available updates, site status, and extension data. After changing Cache Control settings, synchronization also helps pass the necessary parameters to child sites or update them there.

A Supported Cache Layer

Check how each site is actually being cached. The official MainWP Cache Control list includes Cloudflare and popular cache plugins, including Breeze, LiteSpeed Cache, SiteGround Optimizer, Swift Performance, WP Fastest Cache, W3 Total Cache, WP Rocket, Hummingbird Performance, Cache Enabler, Nitropack, Autoptimize, Nginx Helper, WP Optimize, Comet Cache, FlyingPress, WP Super Cache, Rocket.net, Pressable Cache Management, and RunCloud Hub. The product page also mentions Seraphinite Accelerator.

Do not enable bulk clearing blindly. If your network includes sites on different hosts and with different cache plugins, start with a small group. Test one LiteSpeed site, one site with Cloudflare, one with WP Rocket, and one without an external CDN. That makes it much easier to see where behavior is expected and where a separate maintenance procedure is needed.

Permissions, Server Limits, and Parallel Requests

Bulk updates followed by cache clearing put load on the Dashboard, child sites, and external services. MainWP documentation includes separate settings for the number of simultaneous update and sync requests. If you are on standard shared hosting or many sites run on the same server, do not chase maximum parallelism. Slower but stable is usually better: reduce the number of concurrent update requests, add a pause between them, and confirm that the Dashboard does not become unavailable during maintenance.

For Cloudflare, keep purge API limits in mind. If you clear a large number of zones at once or run repeated purges back to back, the service may throttle requests. This guide does not list specific limits as a universal rule for every plan, but in practice you should leave some delay between large batches of sites and avoid clicking purge repeatedly without a reason.

Installing the Extension and Running the First Check

MainWP Cache Control is installed as a MainWP Add-on on the Dashboard site. You do not install it on each child site as a separate management plugin. Child sites only need MainWP Child and a supported caching layer if you expect the extension to clear a specific plugin cache or Cloudflare.

Install It Through Manage Add-ons

Official MainWP documentation recommends installing Add-ons from MainWP > Add-ons > Manage Add-ons. The general flow is straightforward: connect your MainWP account, open the installer, find the extension by category or search, select it, and start the installation. Once installed, the extension is activated like a normal WordPress plugin on the Dashboard site.

1. Open the Dashboard site using an administrator account.
2. Go to MainWP > Add-ons > Manage Add-ons.
3. If required, add your MainWP API key and complete license verification in the MainWP interface.
4. Open the Add-ons installer, find Cache Control, and install the extension.
5. After activation, make sure the Cache Control page appears in the Add-ons menu.

If the extension is installed manually through Plugins > Add New, the principle is the same: upload the ZIP file to the Dashboard site, activate the plugin, and confirm that the page appears in MainWP. That path is useful when automatic Add-on installation is unavailable, but for day-to-day use it is easier to keep installation and updates inside the standard MainWP interface.

A Safe First Test

After installation, do not start by clearing the entire network. Pick one test child site where the current cache layer is easy to identify. Run a sync, then open MainWP > Sites > Manage Sites and check whether Cache Control data appears in the table. If your Dashboard documentation shows dedicated cache columns, verify that the detected solution and the time of the last purge are displayed.

Then use manual clearing for one site. In Manage Sites, select the site you want, choose Clear Cache Control under Bulk Actions, and click Apply. After that, open a public page in a private browser window or with a URL parameter that does not break the site logic, and make sure the updated CSS, banner, script, or HTML is actually visible.

Global Settings and Per-Site Overrides

The main MainWP Cache Control setting lives on the MainWP > Add-ons > Cache Control page. That is where you enable the feature for all child sites, then save the settings and synchronize the sites. Sync matters here: MainWP sends and receives data over secure HTTPS requests between the Dashboard and child sites, and some extension settings are transferred through that exchange.

Configuration for All Child Sites

For a typical network, start with the global mode. It works well if most sites use supported caching plugins and you want clearing to run after updates from MainWP. The sequence is simple: sign in to the Dashboard, open the Cache Control page, enable the feature, click Save, then sync the child sites.

After saving, check a few sites in Manage Sites. If the extension has detected the caching solution, that is a good sign, but it is not the final test. The real test is a manual purge followed by a visible result on the public side. On a site with Cloudflare, also confirm that the API credentials were entered correctly and are not causing errors.

Configuration for One Child Site

Not every site in the network has to follow the same pattern. One project may use both Cloudflare and a cache plugin, another may use only server cache, and a third may be a staging domain where clearing is better handled manually. For those cases, use per-site settings: open MainWP > Sites > Manage Sites, go to the Dashboard for the specific child site, and open its Cache Control page.

The documentation describes the option to override global settings with a Yes or No dropdown, and also to enable the Cloudflare Cache API and set a site-specific API key. In practice, that means you can leave the global rule enabled but define separate behavior for a sensitive site. For example, disable automatic clearing for a test project where you want to compare the cache state before and after changes, or enable the Cloudflare API only for the site that actually uses that CDN.

How to Choose a Safe Setting

For most production sites, enabling automatic cache clearing after updates through MainWP makes sense. For sites with custom CDN rules, aggressive page cache, or critical forms, it is better to run one cycle manually first: update on a test site, run a manual clear, then check the homepage, form, account area, cart page, or any other critical workflow.

Rolling back a questionable setting is simple: go back to the Cache Control page, disable the override or the global feature, save the settings, and sync the site again. Then verify that manual clearing is no longer triggered automatically where you did not want it.

Cloudflare and Multiple Cache Layers

Cloudflare is a special case because it sits in front of the site and may keep serving a cached copy even after the WordPress cache plugin on the server has already been cleared. MainWP Cache Control supports Cloudflare cache purging, but for that to work you need to enter valid Cloudflare API details in the settings and enable Use Cloudflare Cache API.

MainWP documentation includes one important clarification: starting from the change described in the official help materials, the extension can clear both Cloudflare and a supported cache plugin at the same time if both layers are present. Previously, when two solutions were active, the plugin layer could take priority by itself. This guide does not tie that behavior to a specific version number, because the practical takeaway matters more: when a site has dual caching, test both layers, not just the WordPress button.

When to Enable the Cloudflare API

Enable the Cloudflare API only for sites whose domain actually runs through Cloudflare and where you have permission to manage the zone. If a site uses Cloudflare only for DNS without caching, the benefit will be limited. If the CDN is controlled by the client, request the minimum access you need and do not place secrets into content generation tasks, non-private tickets, or third-party chats.

Cloudflare supports different purge methods: individual URLs, tags, hostnames, prefixes, and purge everything. In the MainWP Cache Control interface, it is presented as a cache-clearing tool through integration, but administrators should remember that frequent full CDN purges can cause a spike in requests to the origin server. On a large site, the first visitors after a bulk purge will effectively warm the cache again.

How to Test Dual-Layer Cache

For a site that uses both Cloudflare and a cache plugin, use this test flow:

1. Make a small visible change on a test page, such as editing text in a hidden draft block or adding a temporary CSS class.
2. Update the site or plugin through MainWP if you are testing the automatic scenario, or run a manual Clear Cache Control.
3. Open the page in a private browser window and compare what you see with the current state inside WordPress.
4. Make sure the browser is not serving its own local cache: do a hard refresh or open the page in another browser.
5. If you still see the old version, clear Cloudflare from its own panel and compare the result. That tells you which layer is holding the stale content.

If the public site still shows the old page after a manual clear in MainWP, do not click purge ten times in a row. Separate the layers first: browser cache, plugin cache, CDN, hosting-level server cache. Repeating the command without diagnosis rarely helps and usually just adds more load.

Manual Clearing from Manage Sites and Widgets

Automatic clearing after updates covers the main use case, but manual purge is needed just as often. It is useful after publishing an important page, changing a menu, editing a global template, updating theme settings, modifying CSS, or replacing banners. If the action is not a core, theme, or plugin update triggered through MainWP, the automatic trigger may not run, and the administrator decides when cache should be cleared.

Clearing a Group of Sites from the Table

On the MainWP > Sites > Manage Sites page, select one or more sites. Then open Bulk Actions, choose Clear Cache Control, and click Apply. This works well when you updated a shared component across several sites or made the same change using another MainWP tool.

Before running a bulk action, it helps to filter sites by tag, client, or group. That way you do not send a purge command to projects that were not part of the change. Ideally, the network follows a simple grouping discipline: production, staging, WooCommerce, Cloudflare sites, LiteSpeed sites, sites on another stack. Then Cache Control becomes part of a clear maintenance process instead of a "clear everything" button.

Widgets on Overview

MainWP documentation says Cache Control widgets are available on the main Overview page and on the Overview page for an individual child site. If the widget is not visible, you can enable it through Page Settings. This is a convenient path for quick actions: the administrator opens the site overview, sees the context, clicks Clear Cache, and immediately checks the related page.

The widget is especially useful when you are supporting one problematic site. For example, the client reports that header changes are not visible. You open the Overview for that specific child site, clear the cache from the widget, then check the public page and Network Activity. If the issue disappears after clearing, it was cache-related. If not, look for another layer: browser cache, CDN, CSS optimizer, server cache, or the wrong template.

What to Record After a Manual Purge

For agency support, it helps to log the basics: which site was cleared, why it was cleared, which cache layer was detected, and what result you saw. If Network Activity is enabled, use it as a general MainWP context log. Cache Control itself also shows logs and last purge data if those details are available in the interface. That kind of record helps with recurring disputes: "we did clear the cache, but the issue was in Cloudflare," "the purge worked, but the client's browser kept old files," or "the cache plugin on the site had been disabled."

Practical Scenario: Update Plugins and Make Sure Visitors See the Fresh Page

Let us walk through a real workflow. Imagine a client network where most projects use a supported cache plugin and some domains run through Cloudflare. You need to update several plugins through MainWP and make sure the public site is not still serving old CSS or old HTML after the update.

Goal

The goal is to run updates from MainWP Dashboard, clear cache automatically or manually on the affected sites, and verify that visitors see the current result. This is not about improving speed metrics in one step. It is about avoiding a mismatch between updated code and stale cached output.

Preparation

Before you begin, make sure the child sites were synchronized recently, MainWP Cache Control is enabled, and the Manage Sites table clearly shows which caching solution was detected. For sites with Cloudflare, confirm that API settings are filled in only where needed. If the update is potentially risky, apply it to one site or a low-risk group first.

Steps

1. Open MainWP > Updates and review which plugins or themes need updates.
2. Select a small group of sites or a single plugin if you want to observe behavior before a large rollout.
3. Run the update through MainWP and wait for it to finish.
4. If automatic clearing is enabled, go to Manage Sites and check the last purge time for the affected sites.
5. If cache must be cleared manually, select the sites, apply Clear Cache Control, and wait for the action to finish.
6. Open the public pages where the change should be noticeable: the homepage, a form page, a product page, a post template, or the page with the changed script.

Verifying the Result

Do not check something abstract like "the site opened." Check a concrete result. If you updated a form plugin, submit a test entry on staging or use a safe test form. If you updated a theme, review the header, menu, mobile layout, and any page with custom templates. If you updated an optimization plugin, make sure styles did not disappear and that no JavaScript errors appear in the browser console.

You can treat the result as valid when three signals line up: the update finished without error in MainWP, Cache Control shows a purge or the manual action completed successfully, and the public page in a clean browser session displays the expected state.

A Detail That Is Often Mistaken for an Error

If the administrator is logged into WordPress while the client is viewing the site as a normal visitor, they may be seeing different versions of the page. Some cache plugins do not cache pages for logged-in users, while Cloudflare may cache only for anonymous visitors. That is why public-side testing should be done without signing into the admin panel. For disputed cases, use two browsers: one for the Dashboard, the other for visitor-side verification.

How to Tell Whether the Setup Is Working Reliably

One successful purge is not enough. A good setup should be repeatable: today after a plugin update, tomorrow after a theme update, and later after a large change across several sites. That is why it helps to build a simple validation routine.

Check the Sites Table

Start with Manage Sites. If Cache Control shows the detected caching solution and the time of the last automatic purge, you get a quick network-level overview. Sites where no solution is detected or where the timestamp does not change after updates should go on the manual review list. Do not assume this is automatically an extension error: the site may simply have no supported cache or the updates may not have been run through MainWP.

Check from the Public Side

Create a small internal verification page or use an existing page where you can safely change one visible element. After a purge, check the page in a private window, then from another device or through an external header inspection tool. If you use Cloudflare, review not only the page itself but also indirect CDN cache indicators, such as response headers and behavior after a hard refresh.

Check the Load

On a large network, monitor more than purge success. Watch the condition of the Dashboard itself. If the panel becomes slow during bulk updates, child sites start timing out, or some operations stall, reduce update and sync parallelism. MainWP lets you control the number of simultaneous requests, and that matters more than trying to clear everything in one minute.

A stable pattern usually looks like this: sites are grouped, updates are run in batches, Cache Control clears cache after updates, the administrator checks two or three key pages across different site types, and disputed cases move into cache-layer diagnostics.

Common Problems and Troubleshooting

Cache-related issues often look the same: "the change is not visible." But the causes differ. Below is a practical troubleshooting guide specifically for the combination of MainWP Dashboard, Cache Control, child sites, caching plugins, and Cloudflare.

The Extension Is Installed, but Cache Control Does Not Appear in Add-ons

Symptom: you are sure the extension is installed, but you cannot find it on the Add-ons page, or the list looks empty. Possible cause: the extension is not activated, the wrong ZIP file was installed, you are not on the Dashboard site, or the Add-ons search field was auto-filled by the browser. MainWP documentation describes a case where a password manager fills the Find add-on field and makes the list appear empty.

What to check: open WP Admin > Plugins on the Dashboard site, confirm that the Add-on is active, then return to MainWP > Add-ons and clear the search field. If the extension requires license activation for updates, check the API key status in the MainWP interface. When to roll back: if the Dashboard became unstable after installation, temporarily deactivate the Add-on and review the WordPress or hosting error log.

Cache Does Not Clear After an Update

Symptom: a plugin or theme update through MainWP completed successfully, but the public side still shows the old state. Possible causes: Cache Control is disabled globally, the site overrides the global setting, the child site was not synchronized, the caching plugin is not supported, the update was not run through MainWP, or the stale copy is being held by Cloudflare, the browser, or the host.

What to check: open the Cache Control settings for all sites and for the specific child site, run a sync, then start a manual Clear Cache Control. If manual clearing works, the issue may be with the automatic trigger or with the fact that the change was not part of an update through the Dashboard. If manual clearing does not help, inspect the external CDN and server-side cache.

Cloudflare Returns an Error or the Result Does Not Change

Symptom: a site behind Cloudflare still serves the old page after a purge, or the interface shows that the Cloudflare purge is failing. Possible causes: incorrect email or API key, the key does not have access to the correct zone, the domain is wrong, the wrong Cloudflare account is enabled, a rate limit has been reached, or the page is being cached under a different rule.

What to check: do not send keys in an open ticket. Verify access permissions in Cloudflare, the zone domain, whether Use Cloudflare Cache API is enabled, and the settings on the specific child site. After one failed attempt, do not keep repeating the purge indefinitely. Open the Cloudflare Dashboard first and check manually whether the result changes after clearing it there. If it does not, the problem is not MainWP Cache Control.

Load Increased or the Site Became Slower After a Purge

Symptom: right after a bulk purge, the first page loads became heavier and the server saw a spike in requests. Cause: the purge removed ready-made cached copies, so the site had to start generating pages again for visitors and bots. That is a normal effect of a full cache reset, especially on a site network or behind a CDN.

How to fix it: run updates in batches, reduce simultaneous update requests in MainWP, do not clear sites that were not part of the change, and use the cache-warming features of the specific cache plugin if they are available there. For WP Rocket, for example, MainWP has a separate extension for managing settings, clearing cache, and preload, if your network is standardized around that solution.

Only One Client Sees the Old Version of the Site

Symptom: everything looks correct for the administrator and for external testing, but one user still sees the old page. Possible cause: local browser cache, ISP cache, a mobile app, a corporate proxy, or an old open tab. What to check: ask them to open the page in a private window, on another device, or over a mobile connection. If the problem disappears, MainWP Cache Control has already done its part, and the remaining issue is on the client side or in an intermediate cache layer.

A Safe Working Pattern for an Agency

For an agency, the real value of MainWP Cache Control shows up not in a one-time button press, but in an ongoing maintenance process. A good process is short, repeatable, and easy for the rest of the team to follow. It should answer three questions: who runs the updates, which sites are included in the batch, and how the result is checked.

Split Sites by Risk Level

Brochure sites, blogs, and small business websites are usually easier to maintain in bulk. WooCommerce stores, membership projects, sites with account areas, and sites with aggressive CSS/JS optimization are better updated in separate batches. MainWP Cache Control can clear the cache, but it does not guarantee that a complex checkout flow, login process, or form logic will still behave correctly after the update. That is why critical projects need separate workflow testing.

Make Purge Part of the Checklist, Not a Separate Habit

A short checklist might look like this: sync the sites, choose the group, update, check update status, confirm cache clearing, open two or three pages, record the result. If the site uses Cloudflare, add a CDN check. If the site uses non-standard hosting cache, add a separate step for the hosting panel.

This kind of order helps you avoid forgetting manual purge after changes that do not trigger the automatic scenario. For example, you changed a global block in the theme but did not update the theme itself. Automatic purge may not start, but a manual clear from Manage Sites or from the widget will solve the problem.

Do Not Store Secrets in Extra Places

Cloudflare API email and key belong only in the settings where they are actually used. Do not paste them into articles, contractor tasks, unredacted screenshots, or public notes. MainWP as a platform pays attention to sensitive data handling, but safe operation starts with the administrator: fewer copies of secrets, fewer people with access, and more attention to permissions.

If an employee or contractor who had access to Cloudflare leaves, review the keys. If the site is handed over to another agency, disable the site-specific API key in Cache Control and verify who still owns the CDN zone.

When MainWP Cache Control Is the Right Choice

MainWP Cache Control is worth using if you already manage sites through MainWP Dashboard and want to eliminate a recurring task: remembering to clear cache on child sites after updates. The extension is especially useful when the network includes different caching solutions and signing into each site manually after maintenance takes time and increases the chance of missing one project.

Before rolling it out, check the basics: Dashboard and Child are connected, sites are syncing, cache plugins are on the supported list, Cloudflare API is enabled only where needed, and bulk operations do not overload the server. Then set up the global mode, add overrides for special cases, and lock in a simple result-checking routine.

If, after reading this guide, you understand which sites will be managed through the extension and how you will verify the outcome, the next step is to test it on a small group. Use the product page download block for that: get the MainWP Cache Control file and install it on the Dashboard site, not on every child site. Start with one site, verify manual clearing, and then enable the automatic workflow for the rest of the network.