You clicked update. The page spun. Now the site is blank and so is wp-admin. A WordPress white screen after plugin update is almost always a single plugin throwing a fatal error, and it is usually fixable in under ten minutes.
Most guides send you straight to FTP to rename your plugins folder. That works, but it is the third thing you should try, not the first, and it has a side effect nobody mentions. Below is the order that gets you back fastest, plus how to identify the exact plugin in about thirty seconds instead of switching things on and off until something breaks.
Work through it in order. Do not skip ahead.
First: check your email before you touch anything
Since WordPress 5.2, a fatal error does not just produce a blank page. WordPress catches it and emails the site administrator a link that logs you into recovery mode, with the offending plugin already paused.
This is the single fastest route back in, and it is the one most guides skip entirely.
Two things to know:
The email goes to the address in Settings > General, not to your user account's email. On sites built by someone else, that is often the developer's address, or an old one nobody reads. If you are not receiving it, that is usually why.
The link expires after about a day. If the site broke a week ago and nobody looked, the email is dead and you move on to step two.
Check spam. The subject line mentions a technical problem with your site, and it comes from your own domain, which spam filters frequently dislike.
If you get in through recovery mode, WordPress will tell you exactly which plugin crashed. Skip to the section on what to do with the broken plugin below.
Second: turn the blank page into an actual error message
If there is no email, stop guessing and make the site tell you what is wrong.
Connect by FTP or open your host's file manager, edit wp-config.php, and add this above the line that reads /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG_DISPLAY set to false matters. It keeps errors out of the page your visitors see and sends them to a file instead.
Reload the site once, then open wp-content/debug.log. The last entry looks something like:
PHP Fatal error: Uncaught Error: Call to undefined function
wc_get_container() in /home/site/public_html/wp-content/plugins/
plugin-name/includes/class-something.php:214The plugin folder name is in the path. That is your culprit, named directly, with no trial and error.
If debug.log does not appear, check your host's error log through cPanel or the hosting panel. Some hosts force their own logging configuration and ignore the WordPress constants.
Remove all three lines once you are done. Leaving debug logging on in production grows the file indefinitely and can expose paths if the log is publicly reachable.
Third: disable the plugin, precisely
Now that you know the culprit, disable only that one.
By FTP, go to wp-content/plugins/ and rename only the offending plugin's folder. For example, broken-pluginbecomes broken-plugin-off. WordPress finds the plugin files missing, deactivates that plugin alone, and everything else keeps running.
Why not rename the whole plugins folder
The advice you will read everywhere is to rename wp-content/plugins to plugins-old. It does work, and if you genuinely cannot tell which plugin is at fault, it is a reasonable fallback.
But there is a cost that no guide mentions. When WordPress loads the admin and finds every plugin missing, it clears them from the active plugins list in the database. Rename the folder back and they do not come back on. You now have to remember and reactivate every single one by hand.
On a site with thirty plugins, that is not a minor inconvenience. Reactivation triggers activation hooks. Some caching plugins rewrite configuration. Some security plugins regenerate keys or lock you out temporarily. Some plugins re-run setup wizards.
So: rename one folder if you know which one. Rename the whole folder only as a last resort, and take a screenshot of your plugins list first if you can still reach it.
Fourth: if it was memory, not code
If the log says something like Allowed memory size of X bytes exhausted, the plugin is not necessarily broken. It just pushed you past your limit.
Add to wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );Those two are different and most articles only mention the first. WP_MEMORY_LIMIT covers the front end and defaults to 40M. WP_MAX_MEMORY_LIMIT covers admin and cron operations, where the heavy work happens, and defaults to 256M.
If neither has any effect, your host caps memory at the server level and no WordPress constant will override it. That is a support ticket, or a hosting decision.
Fifth: clear every cache, including the one you forgot
You fixed it and the site is still blank. Before you panic again, the blank page may be cached.
Clear in this order:
Your caching plugin
Your host's server-side cache, separate from the plugin
Your CDN, Cloudflare included
Your browser, or just test in a private window
And one that catches people out: PHP OPcache. It holds compiled PHP in memory and can keep serving the broken version of a file even after you have replaced it. Most hosting panels have a button to flush it. If yours does not, restarting PHP does the same thing, and a support ticket will get it done in minutes.
What to do with the broken plugin
Your site is back. The plugin is off. Now what?
Contact the developer first. A fatal error immediately after a release is often a known bug with a patch already coming. Post in the support forum with the exact line from your debug.log. A specific error report usually gets a fast answer; "your plugin broke my site" usually does not.
Check the compatibility basics while you wait. In Tools > Site Health > Info > Server, check your PHP version. A plugin that suddenly requires PHP 8.1 will crash on 7.4 with exactly this symptom.
If you need it working today, roll it back. For plugins from the WordPress.org repository, the free WP Rollback plugin lists previous versions and reinstalls the one you pick. For premium plugins it will show nothing, because it can only fetch from the public repository. You will need the older ZIP from the vendor's account area, and not every vendor keeps old releases.
The part that rolling back does not fix
A rollback replaces files. It does not touch your database.
If the update ran a migration, moving data into new tables, changing how values are stored, or bumping a stored schema version, the old code you just restored is now reading a database it does not recognise. Sometimes that is another fatal error. Sometimes it is silent, wrong data that you find weeks later.
This is worth understanding before you roll anything back on a store with real orders in it. Check the changelog for the versions between where you are and where you want to go, and look for any mention of migration, schema, or new tables.
Two things not to do
Do not restore a full backup from yesterday to fix one plugin. It works, and it also erases every order, comment, form submission, and edit made since that backup was taken. On a store, a day of orders is a real loss and you may not even know what you lost. Fix the plugin, not the whole site.
Do not reinstall WordPress core. It is a common suggestion and it almost never helps here. The crash came from plugin code, not from core files. You will spend twenty minutes and be exactly where you started.
Stopping the next one
A white screen after an update is not bad luck. It is an untested update reaching production, and it is preventable.
Turn off auto-updates for anything that manages data.WooCommerce extensions, membership plugins, booking systems, page builders. Convenience is not worth a migration running at three in the morning while you sleep.
Test on staging first, especially across major versions. If your host does not provide staging, that is not a reason to skip it. It is a reason to use a plugin that gives you one.
Take a snapshot immediately before updating. Files and database, at the same moment. That is what makes a bad update a five-minute problem instead of a lost day, because you have one coherent point to return to rather than a file backup and a database backup taken hours apart.
Read the changelog before major versions. Thirty seconds. Migrations are usually mentioned.
Where Revertix helps
Revertix takes a full snapshot of files and database together before an update or a push, so the state you return to is coherent rather than assembled from two different moments.
The detailed sync lets you restore selectively, so you can return one plugin and its data without wiping the orders and content that arrived since. And every job runs in resumable, time-budgeted chunks, which means the snapshot actually completes on shared hosting instead of dying at a PHP timeout on a large site.
Quick reference
Situation | Do this |
|---|---|
Site just went blank | Check the admin email for the recovery link |
No email | Enable |
Know which plugin | Rename that one plugin folder only |
No idea which plugin | Rename the whole plugins folder, screenshot the list first |
Memory error in the log | Set |
Fixed but still blank | Clear plugin cache, host cache, CDN, OPcache |
Need it working now | Roll back, but check the changelog for migrations first |
