What to Do When a Plugin Update Breaks Your WordPress Website

The standard advice for this situation was written before WordPress had any of the tools that now handle it. It tells you to log in and deactivate plugins one by one, and if you cannot log in, to connect over FTP and delete folders until the site comes back. That advice still works. It is also about four generations out of date, and it skips the single fastest route back to a working site.

WordPress 5.2 introduced fatal error protection. When a plugin throws a fatal error, WordPress detects it, pauses the plugin, and emails the administrator a recovery link. The site frequently stays up for visitors while the dashboard is broken. Nobody who last read about this problem in 2016 knows that, which is why people still start by deleting directories.

This is the full triage, ordered by how fast each route gets you back, including the diagnosis step most guides skip entirely, and the prevention that means you only read this once.

First: work out which failure you have

Broken is not one condition. These four present differently and have different fastest fixes, and applying the wrong one costs you an hour.

Symptom	What it is	Fastest route back
Site and dashboard both blank white	Fatal error, display disabled	Recovery mode email, then debug log
Front end fine, dashboard blank or erroring	Fatal error in an admin-only code path	Recovery mode email
There has been a critical error on this website	Fatal error protection already caught it	Recovery mode email – it has been sent
Site loads but layout or a feature is wrecked	Not fatal. CSS, JS or a data conflict	Roll the plugin back to the previous version
Briefly unavailable for scheduled maintenance	Update died mid-flight, .maintenance file stuck	Delete .maintenance from the WordPress root
500 Internal Server Error	Could be PHP fatal, could be .htaccess or memory	Check the server error log, not the WP log

Route one: the recovery email (under two minutes)

Search the inbox of the address set under Settings, then General, for a message with the subject line Your Site is Experiencing a Technical Issue. It contains the name of the plugin and the file and line number that failed, plus a link that logs you into recovery mode.

In recovery mode the failing plugin is paused, the dashboard works normally, and you can deactivate or update it properly. That is the whole fix. The link expires after 24 hours by design.

You can also force the admin email to something you control regardless of the database value:

// wp-config.php
define('RECOVERY_MODE_EMAIL', '[email protected]');

Route two: deactivate from the dashboard, if you still have one

If you can log in, this is straightforward, with one refinement on the standard advice. Do not deactivate plugins one at a time from the top of the list. Deactivate the one you just updated. You know which it was, because WordPress records it.

If auto-updates ran overnight and you genuinely do not know what changed, the bisect method is faster than sequential testing on a site with many plugins: deactivate half, test, and keep halving whichever half is still broken. Thirty plugins takes five tests rather than up to thirty.

Route three: force-deactivate over SFTP

Locked out entirely and no recovery email. This is the classic fix and it still works, but rename rather than delete. WordPress only loads plugins whose folders it can find, so renaming deactivates without destroying the plugin’s files or settings, and renaming it back restores everything.

1. Connect over SFTP or open your host’s file manager and go to wp-content/plugins/.
2. Rename the suspect folder, for example woocommerce to woocommerce-OFF. Load the site.
3. If you do not know which plugin it was, rename the whole plugins folder to plugins-OFF. Every plugin deactivates at once and the site should come back.
4. Rename it back to plugins. All plugins now show as deactivated in the dashboard, which you can reach again.
5. Reactivate one at a time, loading the front end after each, until the site breaks. That is your culprit.

With SSH access, WP-CLI does the same thing in one line and is considerably less nerve-wracking:

wp plugin deactivate --all          # everything off
wp plugin activate akismet          # back on, one at a time
wp plugin list --update=available   # what is pending
wp plugin deactivate the-bad-plugin --skip-plugins   # bypass a fatal error

The --skip-plugins flag is the one worth remembering. It lets WP-CLI boot WordPress without loading any plugin code, so you can act even when a fatal error would otherwise stop the command from running at all.

Finding out what actually broke

This is the step the older guides omit, and it is the difference between fixing the site and understanding it. A fatal error names the file and line. That tells you whether the plugin is genuinely broken, or whether it is fine and your PHP version is the problem.

// wp-config.php - log without printing to visitors
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Reproduce the error, then read the end of wp-content/debug.log. Three patterns cover most of what you will find.

Log line contains	Cause	Fix
Cannot redeclare function	Two plugins defining the same function name	A genuine conflict. One of them has to go
Call to undefined function or method	Plugin expects a dependency or PHP version you do not have	Check the plugin’s minimum PHP and WP requirements
syntax error, unexpected …	Usually a corrupted or partial download	Delete the folder and reinstall cleanly
Allowed memory size exhausted	Not a bug. The update needed more memory	Raise WP_MEMORY_LIMIT, then update again
Deprecated / Passing null to parameter	Old plugin on PHP 8.x	Plugin is unmaintained. Plan a replacement

That fourth row matters more than it looks. A memory exhaustion error is not a broken plugin, and deleting the plugin does not fix anything. The update simply needed more headroom than the host allows, and the same failure is waiting for the next large plugin you install.

Rolling back to the version that worked

Deactivating removes the error but also removes the functionality, which is no good if the plugin runs your checkout. Rolling back to the previous version keeps the site working while you wait for a fix.

• WP Rollback. Adds a Rollback link next to any plugin from the WordPress.org repository and lets you pick any previously released version from the dashboard. Free, and the least painful option.
• Manual download from the repository. Every plugin’s WordPress.org page has an Advanced View at the bottom with a Previous Versions dropdown. Download the ZIP, delete the current folder, upload the old one.
• Commercial plugins. Usually no public archive. Check your account area on the vendor site, which normally keeps previous builds, or open a support ticket and ask for the prior version specifically.

When to restore from backup, and when not to

Restoring is the blunt instrument. It works, and it costs you everything that happened since the snapshot: orders, form submissions, comments, new posts. On a store, that is real money.

Restore when the site is down, revenue is being lost, and you cannot identify the culprit within about fifteen minutes. Do not restore as a first move, and do not restore files and database together when only the files are damaged. Plugin fatal errors live in the files; restoring the database as well throws away orders for no benefit.

The failure mode to avoid: restore a snapshot from before the update, watch the site come back, then watch auto-updates reinstall the same broken plugin that night. If you restore, disable auto-updates before you do anything else.

Stuck on Briefly unavailable for scheduled maintenance

This one looks catastrophic and is trivial. During any update WordPress writes a file called .maintenance to the root directory and deletes it when finished. If the update dies partway, the file is left behind and every request sees the maintenance notice.

Delete .maintenance from the WordPress root over SFTP. It is a dotfile, so enable hidden files in your client or you will not see it. The site returns immediately. Then check whether the update actually completed, because a half-installed plugin is its own problem.

Making sure it does not happen again

Everything above is recovery. This is the part that stops you needing it. None of it is exotic, and the first item alone removes most of the risk.

1. Use a staging site. Most decent managed hosts include one-click staging. Update there, click through the pages that matter, then push. This single habit eliminates the majority of update outages and costs nothing on a host that already provides it.
2. Be selective about auto-updates. Leave them on for small, well-maintained utility plugins. Turn them off for anything that touches checkout, payments, membership or your page builder. WordPress lets you set this per plugin from the Plugins screen.
3. Verify your backups restore. An untested backup is a belief, not a backup. Restore one to a staging environment once a quarter. People discover their backups have been silently failing at precisely the wrong moment.
4. Make sure email actually sends. Configure SMTP rather than relying on PHP mail(). This is what makes the recovery mode email available when you need it, and it fixes your order confirmations at the same time.
5. Reduce the plugin count. Every active plugin is a chance for a bad release to take the site down. Twelve plugins that each do a job beats thirty where nine are dormant experiments.
6. Check the changelog before major version bumps. A 3.x to 4.0 jump in a plugin you depend on deserves two minutes of reading. Breaking changes are usually announced.

The decision, in order

Check email for the recovery link. If it is there, you are done in two minutes. If not, and you can log in, deactivate the plugin you just updated. If you cannot log in, rename the plugins folder over SFTP. Once the site is back, turn on debug logging and read the actual error before deciding whether to roll back, replace the plugin, or fix a server setting. Restore from backup only if you are losing money and the clock has run out.

If the same plugin breaks repeatedly, the plugin is the problem rather than your process. Our list of essential WordPress plugins notes which categories have stable, well-maintained options worth switching to, and if the update left you unable to install anything at all, the causes are covered in our guide to plugins not installing on WordPress.

Frequently asked questions