What to Do When a WordPress Plugin Update Breaks Your Site

You click "Update" on a plugin, the screen goes white, and your stomach drops. Or maybe it's worse — you wake up to an email from WordPress saying "There has been a critical error on your website" and you have no idea which of last night's auto-updates caused it.

I see this at least twice a month across the 70+ sites I manage. Plugin updates are the single most common cause of WordPress breakage, and in 2025 alone Patchstack documented over 11,000 new vulnerabilities in the WordPress plugin ecosystem. Updates are essential — but they carry real risk if you don't have a plan for when they go wrong.

Here is exactly what to do, step by step, whether you have server access or not.

Step 1: Don't Panic — Check What WordPress Already Told You

Since WordPress 5.2, a built-in feature called Recovery Mode catches fatal PHP errors and emails the site administrator a special login link. Check your email (including spam) for a message with the subject line "Your Site is Experiencing a Technical Issue."

That email contains two critical pieces of information:

1. The plugin or theme that caused the error — WordPress identifies it by name
2. A one-time Recovery Mode link — valid for 24 hours, lets you log into the dashboard even though the site is broken

Click that link. You will land in your WordPress admin with the offending plugin automatically paused for your session. From here you can deactivate it properly and your site will come back online.

If you never received the email, check that your admin email address is correct in Settings > General. If WordPress can't send emails at all (a common problem I've written about before), Recovery Mode still works — you just won't know about it unless you check.

Step 2: If Recovery Mode Didn't Kick In

Recovery Mode only catches fatal PHP errors. If the update caused something subtler — a white screen, a redirect loop, broken pages, or a 500 Internal Server Error — you need to identify the culprit yourself.

Option A: You Have Dashboard Access

If you can still log into wp-admin but the frontend is broken, go to Plugins > Installed Plugins and deactivate all plugins. If the site comes back, reactivate them one at a time until it breaks again. That is your culprit.

This binary search approach works but it is slow if you have 30+ plugins. A faster method: deactivate plugins in batches of five. When the site breaks again, you have narrowed it down to five suspects. Then test those individually.

Option B: You Have SFTP or File Manager Access

If you cannot reach the dashboard at all, connect via SFTP (or your hosting provider's File Manager) and navigate to wp-content/plugins/. Find the folder for the plugin you suspect and rename it — for example, rename woocommerce to woocommerce-disabled. WordPress will deactivate any plugin whose folder name doesn't match its registration.

If you don't know which plugin caused it, rename the entire plugins folder to plugins-disabled. This deactivates everything at once. Load your site — if it comes back, rename the folder back to plugins and then rename individual plugin folders one at a time to isolate the problem.

wp-content/
├── plugins/                  ← rename to plugins-disabled
│   ├── woocommerce/          ← or rename just this one
│   ├── wordfence/
│   └── contact-form-7/
└── themes/

Option C: You Have SSH Access and WP-CLI

This is the fastest route. SSH into your server and deactivate the suspect plugin in one command:

wp plugin deactivate plugin-slug --path=/var/www/yoursite

If you are unsure which plugin was updated most recently, check the timestamps:

ls -lt /var/www/yoursite/wp-content/plugins/ | head -10

The most recently modified plugin folder is almost certainly your culprit. Deactivate it and check your site.

To deactivate all plugins at once via WP-CLI:

wp plugin deactivate --all --path=/var/www/yoursite

Step 3: Roll Back to the Previous Version

Deactivating the plugin gets your site back online, but you probably still need that plugin. The fix is to roll it back to the version that was working before the update.

Using WP-CLI (Fastest)

If the plugin is hosted on WordPress.org, you can install any previous version with a single command:

wp plugin install woocommerce --version=9.6.2 --force --path=/var/www/yoursite

The --force flag overwrites the current version without asking for confirmation. The --version flag pulls that exact version from the WordPress.org repository.

To find out which version was installed before the update, check your site's debug log or the plugin's changelog. You can also list all available versions:

wp plugin info woocommerce --fields=versions --path=/var/www/yoursite

Using the WordPress Dashboard

If you don't have SSH access, install the WP Rollback plugin. It adds a "Rollback" link next to every plugin on your Plugins page, letting you pick any previous version from a dropdown. It has over 300,000 active installations and has been maintained for over 10 years.

Manual Download via SFTP

Go to the plugin's page on WordPress.org and click "Advanced View" in the right sidebar. There is a dropdown labelled "Previous Versions" — select the version you need and download the ZIP file. Upload it via SFTP to wp-content/plugins/, overwriting the broken version.

Step 4: Prevent This From Happening Again

Once your site is back online and the rolled-back plugin is running, take a few minutes to prevent this from recurring.

Check What Changed

Before updating the plugin again, read the changelog. Look for:

• PHP version requirements — a plugin might now require PHP 8.1+ while your server runs 7.4
• WordPress version requirements — some updates drop support for older WordPress versions
• Breaking changes — major version bumps (e.g. 8.x to 9.0) often include breaking changes
• Known conflicts — plugin support forums on WordPress.org are full of reports within hours of a bad release

Disable Auto-Updates for Critical Plugins

WordPress lets you enable or disable auto-updates per plugin from the Plugins page. For anything that directly affects revenue — WooCommerce, payment gateways, shipping plugins, subscription plugins — I recommend disabling auto-updates and updating manually after testing.

You can also disable auto-updates entirely with a single line in wp-config.php:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Or disable only plugin auto-updates while keeping security updates for WordPress core:

add_filter( 'auto_update_plugin', '__return_false' );

Set Up a Staging Environment

The most reliable prevention is testing updates on a copy of your site before they touch production. Most managed WordPress hosts (Kinsta, WP Engine, SiteGround, GridPane) offer one-click staging environments. If you manage your own server, a subdomain with a cloned database works just as well.

My workflow for the sites I maintain: every update goes through staging first. I run it, check the frontend, check the admin, run any automated tests, and only push to production once I am confident nothing broke. It adds 10 minutes to the update cycle. It has saved me from disaster more times than I can count.

Keep Backups You Can Actually Restore

A backup is only useful if you can restore it quickly. Check that your backup solution:

• Runs daily at minimum (hourly for WooCommerce stores)
• Stores backups off-server (not just in wp-content/)
• Includes the database, not just files
• Has been tested — actually try restoring from it at least once

If you are using a VPS, tools like UpdraftPlus, BlogVault, or server-level snapshots (DigitalOcean Droplets, Hetzner snapshots) all work. The key is having a restore path you have actually tested.

When It Is Not the Plugin's Fault

Sometimes the update itself is fine — the real problem is a conflict with another plugin, your theme, or your PHP version. Signs that you are dealing with a conflict rather than a buggy update:

• The plugin works fine on a fresh WordPress install
• The error only appears when another specific plugin is also active
• The error mentions a function or class name from a different plugin

In these cases, rolling back won't help long-term. You need to identify the conflict. The fastest way is to switch to a default theme (Twenty Twenty-Five) and deactivate all other plugins, then reactivate them one by one with the updated plugin active. When the error returns, you have found the conflict.

Report the conflict to both plugin developers — they may already have a fix in progress.

The Real Fix: Proactive Maintenance

Plugin updates break sites when nobody is watching. Automatic updates run overnight. Nobody checks the changelog. Nobody tests on staging. The site breaks at 3am and stays broken until a customer complains at 9am.

That is six hours of lost orders, lost leads, and lost trust.

The sites I maintain don't have this problem — because I test every update before it reaches production, I keep verified backups, and when something does go wrong I catch it within minutes through uptime monitoring, not hours later through customer complaints.

---

Stop Firefighting. Start Maintaining.

I manage 70+ WordPress sites for UK agencies and businesses. Whether you need ongoing maintenance, emergency support, or a one-off performance fix — I can help.

View Maintenance Plans Get in Touch