Non-WordPress Pages
This covers any case where the document root is serving something other than a WordPress page: a static HTML placeholder, a framework running instead of (or alongside) WordPress, a hand-dropped maintenance file, anything that isn’t WordPress itself handling the request. Aero hooks into WordPress to do its job. No WordPress request, no hook, no feature. Concretely, that means:- Image optimization doesn’t run. Aero never gets a WordPress media request to intercept, so nothing gets converted to WebP or AVIF, and nothing gets resized or served through Aero’s delivery modes.
- Cache Warmer doesn’t run. It reads your sitemap and crawls URLs to keep pages pre-cached, but a non-WP page gives it nothing WordPress-shaped to warm.
- The rest of Aero’s caching and optimization stack sits idle for the same reason. Minification, deferral, and the various Batcache/Edge Cache purge triggers all live inside WordPress hooks that never fire.
Full-Site Redirects
Different setup, same root cause. This is what happens when every URL on a domain gets redirected somewhere else, most commonly a “coming soon” page, a maintenance splash, or a temporary holding page. A visitor’s browser gets bounced before WordPress ever finishes rendering a response. From Aero’s perspective, that’s functionally the same as there being no WordPress page there at all. Everything listed above under non-WordPress pages applies here too.Exceptions to Full-Site Redirects
- If a full-site redirect points to a WordPress page, analytics will work for the destination WordPress page, but won’t work for the source pages.
- Cache warming will work for the destination page, but not any source page.
What Still Works
Bandwidth monitoring keeps working. It’s measured at the server level, not pulled from inside WordPress, so it has nothing to do with whether a WP page rendered or not. Traffic to a redirected or non-WP domain still shows up correctly in the Cloud Panel. Everything else under Site Details and Analytics (visits, unique visitors, average session time) reads data that WordPress itself needs to generate. No WordPress response, no data, so those charts stay flat.Caching Never Kicks In
Worth stating plainly since it trips people up: a non-WordPress page, or a page caught in a full-site redirect, is never cached, by any layer. Not Batcache, not Edge Cache, not anything else in the stack. Every single request hits the origin directly. If you’re expecting a placeholder page to get faster after a few visits, it won’t, and that’s expected given there’s nothing for Aero to cache in the first place.Quick Reference
None of this needs manual fixing. If you’re intentionally running a holding page before launch, this is just how the WP Stratos stack behaves in that state. The moment a real WordPress page starts answering requests at those URLs, Aero and the Cloud Panel’s analytics pick back up on their own. Nothing needs to be re-enabled.