wp-perf-fix

Run changes one at a time through a guarded loop: write a change plan, validate it, get explicit per-change approval, capture a verified snapshot, apply, purge the correct cache layer, verify what visitors receive, and measure the delta. Never batch changes or skip the snapshot.

WP Engine, Kinsta, Flywheel, Pressable, Bluehost, and WordPress.com publish policies prohibiting third-party page-cache plugins, and several remove them automatically. SiteGround and Cloudways permit only specific plugins like sg-optimizer and breeze; unconfirmed hosts are treated as prohibited by default.

No. Both hosts publish disallowed-plugin lists covering page-cache plugins and remove them from sites. The validator refuses such plans automatically and routes you to the host's own caching controls instead; removing an existing cache plugin is never gated.

The purge likely hit the wrong layer. Caches must be purged innermost outward (object, page-plugin, server, edge), because an outer cache refills from a stale inner layer. Verify with anonymous fetches checking cache-status headers, Age, and the actual response body.

Roll back first, diagnose second. Every change requires a verified snapshot captured before applying, so the prior state can be restored immediately. Incidents like fatals or 5xx errors trigger rollback before any investigation begins.

Yes, under compensating controls: the most reversible mechanism available, a syntax check before writing, visitor-visible verification that triggers rollback, and a confirmed admin recovery email. The report must state the change went to production untested.