A set of hard-won protocols for maintaining healthy WordPress sites on WP Engine. These emerged from a large-scale backend audit that uncovered plugin bloat, caching conflicts, and file system debris causing widespread 502/504 errors and WP Engine scores as low as 15/100.
WordPress sites degrade silently over time. The visible front end looks fine while the backend accumulates:
The result: high error rates, low WP Engine cache hit rates (target is 85%+), and plummeting Ahrefs site health scores.
Before installing any plugin, have an explicit conversation with the client:
- What is the business value of this feature?
- Are you willing to accept a slower, more fragile site in exchange for it?
- If the site breaks because of this plugin, that's a known and accepted risk.
If the client can't articulate clear business value, push back. Simpler sites are more reliable sites.
Plugins like Bookly and Event Manager Pro are a consistent source of site instability. They load tens of thousands of lines of code to accomplish tasks that often require only two or three features. Every site with a scheduling plugin has shown problems. If a client needs simple appointment booking, find the most minimal tool available — or build a lightweight alternative.
WooCommerce has hundreds of available plugins. The temptation to add one for each small feature request compounds quickly. Each addition increases fragility and the odds of version incompatibility. Treat every WooCommerce plugin request as a formal risk-reward evaluation.
The stack is: Cloudflare → WP Engine → site-level plugins. Each layer must be configured to work with the others, not against them.
Key rules:
- Only one image compression tool per site.
- Only one lazy-load feature active at a time.
- WP Engine bot blocking should be enabled to prevent bot traffic from overwhelming the server.
- Target WP Engine cache hit rate: 85% or higher.
Use AI-assisted error log analysis to find intermittent conflicts that don't surface during manual testing. WP Engine stores error logs server-side — pull these and look for patterns across thousands of lines.
When removing a plugin:
1. Deactivate and delete the plugin through WordPress admin.
2. Separately audit and clean up orphaned files on the server.
3. Separately clean up orphaned database entries using a database tool.
Steps 2 and 3 do not happen automatically. Skipping them is how sites accumulate thousands of stray files and millions of database rows.
This cleanup is high-risk work. Deleting files at scale can break non-obvious things (a button behavior, a checkout flow). After any large cleanup, do a full site walkthrough — click through pages, test forms, test checkout.
The mandatory process:
Why this matters:
- Persistent staging environments go stale. Working on an outdated staging copy and pushing it to production overwrites recent work.
- WP Engine automatically rewrites URLs during a staging-to-production push (e.g., staging.example.com → example.com, HTTP → HTTPS). This eliminates the need for manual search-and-replace, which is error-prone.
- Deleting staging after push reduces server storage consumption (each environment is a full copy of the site) and eliminates ambiguity about what's current.
Tracking active staging environments:
Maintain a shared document (Google Sheet or equivalent) listing all sites and whether a staging environment is currently active and who is working in it. This is essential for async teams — you cannot rely on real-time communication to know whether a staging environment is safe to overwrite.
See also: [1]
Restoring a backup is a last resort, not a default response to a broken site.
Reasons:
- A backup restore erases all recent work, including backend cleanup and configuration changes that aren't visible on the front end.
- It does not fix the underlying problem. Whatever caused the break will cause it again.
Protocol:
- When something breaks, diagnose and fix the root cause.
- A backup restore requires explicit approval before proceeding.
- Reserve restores for genuine calamities where the site is unrecoverably broken.
The backend audit also surfaced widespread SEO gaps. As part of any site cleanup:
- Every page must have an optimized meta title and meta description.
- Every image must have alt text.
- Check for broken images and incorrect image formats.
- Run Ahrefs site health — target score is 98 or above.
GTM containers accumulate unused tags the same way WordPress accumulates unused plugins. A container with 60 tags for a site with 2 conversions is a performance and maintenance problem.
Correct GTM setup:
1. Identify all conversions on the site (form fills, phone calls, purchases, etc.).
2. Ensure each conversion has exactly the tags it needs in GTM.
3. Verify those tags are reporting correctly in Google Analytics.
4. Verify conversion tags relevant to paid ads are working in Google Ads.
5. Remove all tags that don't serve a current, documented purpose.
Next phase: adding social media pixels (Meta, etc.) to enable multi-touch attribution — connecting user journeys across SEO, Google Ads, and social channels.
See also: [2]