Manual purge
Two buttons live at the top of the screen, and they’re not the same action.Automated flush triggers
These decide what makes Aero purge cache without you doing anything. Each one is independently safe to leave on, and each is deliberately scoped to purge only what actually changed, so the rest of your cache stays warm. Each trigger below has its own last-run timestamp, and the Debug report lists all of them together if you ever need to confirm one actually fired.Flush cache on plugin & theme updates: Safe, recommended
Flush cache on plugin & theme updates: Safe, recommended
Runs the full sequential flush, deliberately. An update can change CSS, JS, or markup sitewide, so every layer purges in order and the Cache Warmer rebuilds immediately after. Leave this on unless you have a specific reason to manage flushes manually after deployments.
Targeted flush on page/post edit: Safe, recommended
Targeted flush on page/post edit: Safe, recommended
Surgical, not sitewide. Purges the edited URL, its archive pages, the author page, and the feed. The homepage is only included when the edit could plausibly appear there. Everything purged is re-warmed within seconds if the Cache Warmer is on.
Flush cache on page/post delete: Safe, recommended
Flush cache on page/post delete: Safe, recommended
Same surgical approach, plus the homepage, since a deletion changes list membership (what shows up in “recent posts,” archives, and so on).
Flush cache on comment delete: Safe
Flush cache on comment delete: Safe
Purges only the commented post. The rest of the site stays warm.
Per-page flushing
Flush Batcache for individual pages: Situational
Flush Batcache for individual pages: Situational
Adds a “Flush Cache” row action on the Pages/Posts list and a toolbar button on the frontend. Useful for editors who need to push a single change live without touching the full Aero dashboard. Turn it on if non-admin editors need self-serve cache control; skip it on tightly locked-down sites.
Flush Batcache for WooCommerce product pages: Safe if you run WooCommerce
Flush Batcache for WooCommerce product pages: Safe if you run WooCommerce
Product pages updated through the WooCommerce REST API (inventory syncs, price updates from a PIM, etc.) get flushed individually, deployed as an mu-plugin so it runs even outside normal WordPress hooks. If you don’t run WooCommerce this setting has nothing to do.
Batcache behavior
These change how Batcache itself decides what to store, not what triggers a purge.Extend Batcache storage to 24 hours: Safe, recommended
Extend Batcache storage to 24 hours: Safe, recommended
Raises
max_age to 86400 seconds so cached pages survive a full day instead of the platform default. Longer cache life means fewer full-render hits on your server, which is almost always a win as long as your automated flush triggers above are on to keep content from actually going stale.Ignore gclid query strings: Safe, recommended
Ignore gclid query strings: Safe, recommended
Google Ads click IDs (
?gclid=...) are unique per click, and without this setting each one fragments your cache into a separate, useless entry. Ignoring them for cache-key purposes means ad traffic actually benefits from caching instead of missing it every single time. This has no effect on your analytics, it only affects what Batcache treats as “the same page.”Exclude pages from Batcache & Edge Cache
A comma-separated list of relative paths (/checkout/, /my-account/) that should never be cached, served with no-store via an mu-plugin so the rule holds even if Batcache’s own logic would otherwise cache them.
Page cache configuration (WP Stratos hosting)
If your site runs on WP Stratos infrastructure, an additional panel lets you tune Batcache’s ownwp-config.php constants directly, with one-click auto-configuration if they’re not set yet.
This panel only appears when Aero detects it’s running on WP Stratos hosting and
wp-config.php is writable. If wp-config.php isn’t writable, values are shown read-only, since Aero can’t safely persist a change it can’t verify was written.