Manage GPL

← Back to blog

What to do when a WordPress plugin update breaks a client site

· John MM
What to do when a WordPress plugin update breaks a client site

Every agency that manages more than a couple of WordPress sites has lived through this moment: you roll out a routine plugin update, walk away from the desk, and ten minutes later the phone rings. The homepage is white. Checkout throws a 500. The client is upset because they were mid-launch. This post is a playbook for that moment — a calm, ordered sequence for going from "site is down" to "site is back and the client isn't angry" — plus some habits that stop it from happening in the first place.

Step 1 — Stop the bleeding

The first move is not to diagnose. The first move is to stop losing traffic and transactions. If the site is fully white-screened, you have two fast options:

  • Enable maintenance mode at the server or Cloudflare level so visitors see a friendly "we'll be right back" page instead of a white screen or a PHP error. Don't rely on WordPress's built-in maintenance file — if the fatal is early enough, WordPress never runs it.
  • Drop a static HTML holding page at the doc root if you can't enable maintenance mode quickly. One minute of manual work is better than ten minutes of Fatal error: Uncaught Error showing to real customers.

Step 2 — Confirm which update did it

Open your management tool's activity log (or check debug.log if you don't have one). You want three things:

  • The exact timestamp the site went down.
  • Which plugins updated in the last hour.
  • The first fatal error in the PHP log.

Nine times out of ten the culprit is obvious: one plugin updated right before the fatal started. If two updated at the same time, you're about to guess — which is why batching updates by risk (see our earlier post) matters.

Step 3 — Roll back, don't roll forward

Resist the urge to "fix" the problem by upgrading to a newer version of the same plugin that might have already patched it. Roll back first; investigate later.

  • WP-CLI: wp plugin install plugin-slug --version=X.Y.Z --force pulls a specific prior version if the vendor still hosts it.
  • Restore from snapshot: if you took a snapshot before the update (you did, right?), this is a one-click restore.
  • Re-upload the old zip: if you kept the prior version's zip file, deactivate via WP-CLI or the filesystem, delete the new version's folder, and re-upload the old one.

A rollback is almost always safer than debugging on a live production site. Once the site is back up, you can spend an hour diagnosing in staging without anyone losing money.

Step 4 — Communicate before the client asks

Send a short message proactively, even if the site is already back:

"Hey — the 11:14am plugin update on [site] caused a fatal error. Site was down for roughly six minutes. I've rolled the plugin back to the previous version and everything's working again. Investigating why it broke and I'll send a note when it's resolved for good."

Clients forgive downtime. They don't forgive finding out about it from their customers.

Step 5 — Prevent the next one

Once the dust settles, three habits will cut the frequency of these incidents roughly in half:

  • Staging updates first for any plugin that does more than display content (anything touching WooCommerce, memberships, forms, SEO plugins with database schema).
  • Deferring major-version updates for at least 48 hours after release. Most show-stopping regressions get patched in the first few days.
  • Pinning high-risk plugins to a specific version on critical sites, and updating them on a deliberate schedule rather than whenever the plugin vendor decides.

How Manage GPL helps

Manage GPL's activity log records every update with a timestamp, the plugin, the version before and after, and who triggered it. When a site breaks, that log is the first thing you check — no digging through server logs, no guessing which plugin moved. Every update runs only when you click it (no auto-apply), so the versions on each site are exactly what you decided to leave them on. Pair that with host-level or WP snapshots before each batch, and you have the clean rollback path the rest of this post assumed.

Try Manage GPL free — five sites, no credit card needed.

Tired of updating plugins one site at a time?

Manage GPL connects all your WordPress sites and keeps premium plugins and themes up to date with one click.

Get started — free