Our Crashing Sites Were on WP Engine. Our Rotting Sites Were on Ours.

On July 18, three of our WordPress sites threw fatal errors within two minutes of each other. All three were on WP Engine. Same stack trace, same plugin, same cause.

The obvious conclusion is that WP Engine broke them. That conclusion is wrong, and getting it wrong would have cost us the next six months.

Here is what the fleet actually looks like when you check all 115 sites instead of the three that were on fire.

The number that reframed the whole problem

We run personal brand sites on two platforms: our own BlitzAdmin AWS fleet, and WP Engine for a handful of client sites. Every one of them runs Rank Math for SEO. Rank Math Pro is an add-on that requires Rank Math Free installed alongside it, and the two must stay in version lockstep or the site fatals.

The platform with all the crashes is five times better maintained than the platform with none.

That is not a paradox. It is the entire lesson.

Managed hosting does not cause plugin drift. It detonates it.

WP Engine auto-updates the free plugin. That is what you pay a managed host to do. When it pushed Rank Math Free forward on July 17, the sites whose Pro add-on was still sitting at an old version — because Pro only auto-updates when the site is connected to a paid license — suddenly had a new Free running against a stale Pro. Pro called a class that no longer existed. White screen, instantly, on all three.

Our own platform auto-updates nothing. So on our 103 sites, Free and Pro are both frozen wherever they landed on install day. They do not crash. They also do not improve. Eighty-seven percent of them are running plugin versions that are months old, and one of them has been carrying a Pro build from a release cycle so far back that the moment anything updates it, it will fatal exactly like the three that did.

The crash is not the disease. The crash is the smoke alarm.

We had effectively disconnected the smoke alarm on 103 sites and then congratulated ourselves that they were not on fire. The 13% number is what that actually costs: outdated SEO plugins, missing schema features we pay for, security patches never applied, and a fleet-wide fatal queued up behind whatever finally triggers an update.

The failure nobody was looking for: one site, two platforms

While auditing this, we found the real outage — and it was neither platform’s fault.

Two sites were returning HTTP 500 on every path, including the login page. Both had healthy WordPress installs. We confirmed it: the install responded 200 and the admin login loaded fine.

The problem was that each domain’s DNS pointed at our AWS fleet IP, while the actual WordPress install lived on WP Engine. The domain was aimed at a server that did not have the site on it.

These sites had been migrated between platforms at some point, and the DNS and the install ended up on opposite sides. Nothing monitors for that. Uptime checks see a 500 and report “site down,” which sends someone hunting for a plugin conflict that does not exist. We wasted a cycle last month doing exactly that — a plugin was blamed publicly and the call had to be retracted a day later.

A split-platform site fails in a way that looks like every other failure and responds to none of the usual fixes.

The rule

One site, one platform. And whoever owns the platform owns the update discipline.

Those two halves are inseparable. Picking the right platform buys you nothing if nobody owns what the platform does not do for you.

Where a site goes

What each platform obligates you to do

On WP Engine: the host updates free plugins for you. Your job is making sure every paid add-on is license-connected so it updates in step. An unconnected paid plugin on a managed host is a scheduled crash — the host will move one half and not the other.

On our own fleet: nothing updates itself. Your job is the whole job. That means a connected license, a scheduled update pass, and a weekly check that actually reads version numbers rather than checking whether the homepage loads. A site can be nine months out of date and return a perfect 200.

Why “it isn’t crashing” is not a status report

The check we had been running looked for sites that were down. It found three, every week, and they were always the WP Engine ones — because those are the only sites where anything moves.

An availability check on a platform that never updates measures nothing. Everything looks fine right up until the day something changes, and then it all goes at once, which is precisely what happened on July 18 to the sites where things do change.

The check has to read versions. Ours now does, and the first time it did, it found that the version probe itself had been broken for three consecutive weeks — it was requesting a file that the paid plugin does not ship, getting a 404 every time, and reporting “no problems found.” Three clean reports in a row, all of them meaningless.

A monitoring system that cannot fail loudly is not a monitoring system. If your check has never returned bad news, verify that it can.

The checklist

1. Every site is on exactly one platform. Confirm DNS resolves to the same infrastructure the install actually lives on. Do this for every site, not just the ones that look broken.
2. Personal brand sites go on our fleet. Low volume, simple stack. Do not pay managed-hosting rates for a publishing site.
3. Complex and high-traffic client sites go on WP Engine. That is what the managed layer is for.
4. Every paid plugin is license-connected on install day. Not later. Connection is what turns on auto-update, and auto-update is what prevents drift. Our own agency license covers 750 sites and we run about 200 — connecting every one of them costs nothing.
5. Build it into provisioning, not into a runbook. A site we built this month was born with the exact broken version pair, because the provisioning template still ships it. Fixing sites one at a time loses to a template that keeps making them.
6. The weekly check reads version numbers. Not HTTP status. And confirm the check is capable of reporting a failure.

What this is really about

We spent weeks treating a crash as the problem. The crash was the only reliable signal we had, and it was coming from the one platform doing its job.

The sites that never crashed were in worse shape than the sites that did. They were just quiet about it.

Pick the platform that fits the site. Put the whole site on it. Then own the part the platform does not do for you — because on a low-cost platform, that part is all of it, and nothing will remind you.

Related reading: The System — how our components fit together, and login-free publishing with application passwords, which is how we read plugin versions across the fleet without a human logging into 200 dashboards.