A WordPress site that goes down immediately after a plugin update is almost always showing a fatal PHP error from the plugin that just changed, and it is recoverable without touching the database. WordPress will usually email you a recovery mode link automatically. When that email does not arrive, which is common, renaming the plugin's folder over SFTP deactivates it in seconds and brings the site back.
This article gives you the recovery ladder in order, from the least invasive step to the one that always works, then covers how to identify the culprit when several plugins updated at once, and finishes with the preparation that turns this from an emergency into an inconvenience.
What WordPress does automatically before you do anything
Since version 5.2, WordPress has shipped fatal error protection. When a plugin or theme triggers a fatal PHP error, WordPress catches it, pauses the offending extension, and emails the site's administration address a link to recovery mode. Recovery mode loads the admin area with the broken plugin deactivated, so you can log in, remove or roll back the plugin, and exit. Visitors see a generic message rather than a stack trace while this is happening.
The gap in this design is the email. Recovery mode depends on WordPress being able to send mail, and a great many WordPress installations cannot send mail reliably at the best of times. Shared hosts block the PHP mail function, SMTP plugins are themselves plugins and may be the thing that broke, and the administration email address on older sites frequently belongs to somebody who left the company. If the email arrives, use it, because it is by far the cleanest path. If it has not arrived within a few minutes, stop waiting and move down the ladder.
The recovery ladder
Try wp-admin first. A fatal error on the public site sometimes leaves the admin area reachable, because the broken code only runs on the front end. If you can log in, deactivate the plugin you just updated through the normal plugins screen and the site returns immediately. This takes fifteen seconds to test and is worth testing before anything else.
Rename the plugin's folder over SFTP. Connect to the site with SFTP or your host's file manager, open the wp-content directory, then plugins, and rename the folder belonging to the plugin you updated by adding a suffix to it. WordPress looks for plugins by folder path, cannot find it, and force-deactivates it on the next page load. This works whether or not you can reach wp-admin, and it does not touch the database.
Rename the whole plugins directory. If you do not know which plugin broke, rename the entire plugins folder. Every plugin deactivates at once and the site comes back on its theme alone. Rename it back, and the plugins stay deactivated in the database, so you can then log in and reactivate them one at a time until the site breaks again. That plugin is your answer.
Roll back rather than reinstall. Once the site is up, do not simply update the broken plugin again and hope. Install the previous version from the plugin's developer page, or use a rollback plugin, and stay on the working version until the developer ships a fix.
Reading the actual error
Deactivating the plugin restores the site but tells you nothing about why it broke, and you will need that answer before you can safely update again. Turn on debugging by setting the debug constant to true in wp-config.php alongside the debug log constant, which writes errors to a file in wp-content rather than displaying them to visitors. Never enable the display option on a live site, because PHP errors printed to the page leak file paths and occasionally worse.
The log usually names the file and line, and the message tells you which category you are in. A call to an undefined function or method typically means a plugin conflict or a missing dependency. An error mentioning a syntax feature usually means a PHP version mismatch, which is the quiet cause behind a surprising share of these incidents: the plugin update requires a newer PHP than the server runs, and the failure has nothing to do with the plugin's code being wrong. Memory exhaustion messages point at a limit rather than a bug. Each of these has a different fix, and guessing between them is how a fifteen minute outage becomes a two hour one. Our overview of website downtime covers how to think about the wider category of outages this belongs to.
Why this keeps happening to the same sites
Plugin updates break sites for structural reasons rather than unlucky ones. WordPress installations accumulate plugins over years, each written by a different developer against a different version of WordPress and PHP, and no one tests the specific combination running on your server. Automatic updates apply changes at times nobody chose, which is why site owners discover the problem from a customer rather than from a deployment. Sites without staging environments update straight into production because there is nowhere else to update.
The pattern that removes most of the risk is unglamorous. Keep a staging copy and apply updates there first, even if staging is only a subdomain refreshed occasionally. Update plugins one at a time rather than using the select-all checkbox, so that when something breaks you already know what did it. Take a backup immediately before updating rather than relying on last night's. And know that the site went down within minutes rather than within hours, which is entirely a matter of whether anything was watching.
Common mistakes in recovering a WordPress site after an update
Waiting for the recovery email that never comes. Recovery mode depends on WordPress being able to send mail, which many installations cannot do. Give it a few minutes, then go to SFTP rather than continuing to refresh an inbox.
Editing files to comment out the error. Modifying plugin code to suppress a fatal error leaves you running a broken plugin and loses the change on the next update. Deactivate it and roll back to the previous version instead.
Updating everything again to see if it fixes itself. Applying more changes on top of an unresolved failure makes the cause harder to isolate. Get the site up, identify the plugin, then move forward deliberately.
Enabling error display on a live site. Printing PHP errors to the page exposes file paths and internal details to anyone who visits. Log errors to a file instead and read the file.
Assuming the plugin is at fault. A plugin that requires a newer PHP version than the server runs will fail on a perfectly healthy server with perfectly good code. Check the PHP requirement before reporting a bug.
FAQ
How do I deactivate a WordPress plugin without access to wp-admin?
Connect over SFTP or your host's file manager, open wp-content and then plugins, and rename the plugin's folder. WordPress cannot find the plugin at its expected path and deactivates it automatically on the next page load.
Why did my WordPress site go completely white after an update?
A white screen is a fatal PHP error with error display switched off. The page stopped executing partway through and produced no output. Enabling the debug log constant in wp-config.php records the underlying error to a file.
Will renaming the plugins folder delete my settings?
No. Plugin settings live in the database, not in the plugin folder. Deactivating a plugin this way leaves its data intact, and reactivating it restores the configuration you had.
Should I turn off automatic plugin updates?
Automatic updates close security holes quickly, which is worth a great deal. The safer compromise is to leave security updates automatic, apply feature updates manually after testing on staging, and monitor the site so a bad update is noticed in minutes rather than hours.
Closing thought
Every recovery step here is a variation on the same move: stop the broken code from loading, get the site answering again, and only then work out what happened. Sites stay down for hours not because the fix is hard but because the person who could apply it did not know there was a problem, or spent the first forty minutes refreshing an inbox waiting for an email that a broken installation was never going to send.
That first gap is the one worth closing, because it costs nothing to close and it determines the length of every incident that follows. Odown checks your site from seventeen locations on the interval you choose, watches for the error page as well as the error code, and alerts you through Slack, Teams, email, or SMS the moment a plugin update takes the front end down. If your WordPress site updates itself while you sleep, website monitoring from twelve dollars a month is the difference between a five minute outage and an overnight one.
