Quick summary
A performance engineering note about moving fixes into a child theme and must-use plugin, rebuilding static caching, and verifying hundreds of production URLs without stale-host leaks.
The problem
A WordPress site had inconsistent output across live, local, staging, and cached production copies, including old host references, layout shifts, duplicate schema, and cache files that could be regenerated stale.
What I checked
- Live, local, staging, and production layouts and assets
- Browser traces, console output, cache behavior, and page paint
- Database host references, canonical URLs, and schema duplication
- Header, hero, form, font, and embedded-widget behavior
- Every production URL selected for static-cache generation
What I changed
- Built a child theme and must-use performance plugin so fixes lived in versionable files
- Added critical CSS, layout-stability rules, delayed noncritical scripts, and asset protections
- Reworked purge and rebuild controls to avoid writing stale or redirected pages
- Normalized old environment URLs and removed duplicate LocalBusiness-style schema
- Rebuilt 278 production cache files with no failures and removed temporary deployment tools
Result
Production gained deterministic static caching, cleaner rendered output, safer admin controls, and a verified cache set covering all 278 intended URLs.
Where this fix usually leads next
This kind of work usually connects back to Site Speed, WordPress Support and Production Debugging so the fix note can lead into a clearer support path instead of staying as an isolated one-off task.
What I'd watch next
- Whether content saves purge only the affected cache paths
- Whether new plugins reintroduce old hostnames or duplicate schema
- Whether delayed third-party scripts remain compatible with lead forms