You clicked "Update All." The page hung for a moment. Now the site is blank.
The good news: you already know the cause. Something in that batch of updates is incompatible with something else on your site, and you have a very short list of suspects. This is one of the easier WordPress failures to fix precisely because the timing tells you where to look.
Here's how to get back in, work out which update did it, and roll back without losing anything you've written since your last backup.
The short version
- Back up the broken site — yes, broken
- Check the admin email for a recovery mode link
- If you can't get in, disable plugins via FTP
- Identify the culprit by reactivating one at a time
- Roll that one back and pin it until it's fixed
Step 1 — Back up what you've got
Before touching anything. The site is broken; back it up anyway.
You need a restore point for this state, because a rollback might lose content added since your last real backup — a post, an order, a form submission. If something goes wrong mid-recovery, this is what saves you.
Files and database. Host one-click backup if available, otherwise download wp-content and wp-config.php via FTP and export the database through phpMyAdmin.
Step 2 — Check your email
Since WordPress 5.2, a fatal error sends the admin address an email containing a recovery mode link. That link logs you into wp-admin with the offending plugin or theme paused.
Check that inbox, including spam.
The email usually names the specific plugin and the file and line that crashed. If it's there, you've skipped straight to the answer.
Step 3 — Get back in without admin access
No email, or the link doesn't work? Use FTP or your host's file manager.
Disable every plugin at once: rename /wp-content/plugins to plugins-off.
WordPress can't find the plugins directory, so it deactivates all of them. Reload your site.
If the site comes back: it's a plugin. Rename the folder back to plugins — your plugins stay deactivated in the database, and you can now reactivate them one at a time from wp-admin.
If the site is still blank: it's the theme or core. Rename your active theme's folder, forcing WordPress onto a default theme. If that fixes it, the theme update was the problem.
If still blank: likely a core update issue or something server-side. Restore your backup, then investigate. The wider diagnostic.
Step 4 — Find which one did it
Reactivate plugins one at a time from wp-admin, checking the site after each.
When it breaks, the last plugin you activated is your culprit.
Two shortcuts worth knowing:
Enable WP_DEBUG_LOG first, and the log will usually name the offending file directly — skipping the whole reactivation process. In wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
And start with the plugins that actually updated. If only four things updated, test those four first rather than working alphabetically through thirty.
If no single plugin reproduces it, you may have a two-plugin conflict where each works alone. Reactivate in pairs. The full method.
Step 5 — Roll it back
Once you know the culprit, you need the previous version.
WP Rollback is the standard tool. Install it, and each plugin and theme in your admin gains a "Rollback" option letting you select any previous version from the WordPress repository. Straightforward, and it works for themes too.
Your host's restore point. Most managed hosts keep automatic daily backups you can restore in a few clicks. Blunter — it reverts everything, including any content added since — but fast and reliable.
Manual downgrade. On WordPress.org, every plugin's page has an "Advanced View" section with a version dropdown and download links. Download the old version, delete the current plugin folder via FTP, upload the old one.
Premium plugins usually let you download previous versions from your account area. If not, the vendor's support team can supply one.
Step 6 — Pin it, and tell someone
Rolling back is a pause, not a fix. The old version stops receiving security updates, so you can't leave it indefinitely.
Prevent it re-updating. Disable auto-updates for that specific plugin in Plugins → Installed Plugins, where each row has an auto-update toggle.
Report it. Open a support thread on the plugin's WordPress.org page, or email the vendor. Include your WordPress version, PHP version, the plugin version that broke, and the error from your debug log. Conflicts get fixed faster when they're reported with detail, and you're probably not the only person affected.
Set a reminder to check for a fix in a couple of weeks. Don't leave a pinned old version running for months.
Why updates break sites
Understanding this changes how you update.
Version assumptions. A plugin update assumes a newer WordPress core version than you're running, or uses a function that older core doesn't have.
Deprecated functions. A core update removes something an old plugin still calls. The plugin was fine yesterday because the function still existed.
PHP version changes. Your host upgrades PHP, and a plugin that hasn't been updated in three years stops working. Same symptom, different cause — worth checking whether your PHP version changed recently.
Newly conflicting plugins. Two plugins that coexisted fine now both try to modify the same thing.
The pattern: it's rarely a "bad update." It's an incompatibility with your specific combination of software — which is exactly why the plugin author didn't catch it, and exactly why staging matters.
Should you enable auto-updates?
A genuine judgement call, and the answer differs by what's updating.
Enable for: WordPress core minor releases, which are mostly security and bug fixes and are extremely well tested. Also security plugins, where a delayed patch is its own risk.
Consider for: simple, well-maintained plugins on a low-traffic site with reliable backups. The convenience genuinely outweighs the risk here.
Disable for: page builders, WooCommerce and commerce plugins, anything heavily customised, and anything on a site where an hour of downtime costs real money.
The middle position most people should hold: auto-update core minor releases and security plugins, manually update everything else on a schedule, and test on staging first if you have one.
And the real answer: the risk of auto-updates is almost entirely about whether you'd notice and recover quickly. With daily backups, uptime monitoring, and a staging site, auto-updates are low risk. Without them, one bad Tuesday takes your site down until someone notices.
Preventing the next one
Use staging. Most decent hosts include it free. Update there, check the site, then push. This alone prevents most update disasters.
Update in batches, not all at once. Updating twenty plugins together means twenty suspects. Four at a time means four.
Check the changelog for major version jumps. A move from 3.x to 4.0 usually signals breaking changes.
Keep a maintenance window. Update when you can watch the result, not last thing on a Friday.
Know your restore path before you need it. Practise a restore once, so the first time isn't during an emergency.
Frequently asked questions
How do I undo a WordPress update?
For plugins and themes, WP Rollback lets you revert to any previous version from the repository in a few clicks. Most managed hosts also keep automatic restore points that roll the whole site back. For core updates, restoring a full backup is the reliable route. Always back up the current broken state first, since a rollback can lose content added since your last real backup.
Why do updates break sites?
Almost always an incompatibility with your specific combination of software rather than a defective update. A plugin update assumes newer core, a core update removes a function an old plugin still calls, a PHP version change breaks an unmaintained plugin, or two plugins that coexisted now conflict. The plugin author couldn't test your exact stack, which is what staging is for.
Should I enable auto-updates?
Enable them for WordPress core minor releases and security plugins, where delayed patches carry their own risk. Disable them for page builders, commerce plugins, and anything heavily customised on a site where downtime costs money. The deciding factor is really recovery speed — with daily backups, uptime monitoring, and staging, auto-updates are low risk; without them, a bad update stays broken until someone happens to notice.
What to do next
Back up the broken site, then check the admin email for a recovery link. Those two steps take five minutes and solve a large share of cases outright.
If there's no email, rename the plugins folder via FTP. That gets your site back online while you work out which one did it — and getting back online first is worth more than diagnosing elegantly.
Free: The WordPress maintenance checklist.
Related guides
- When WordPress breaks: a diagnostic order — the wider picture
- Find a plugin conflict safely — isolating the culprit
- WordPress backups: what most people get wrong — having a restore point that works
- WordPress plugin audit — reducing the surface area
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
Transactional Email Services Compared for WordPress
Every one of these services will deliver your password resets. That's not the differentiator. What differs is setup difficulty, what the free tier covers, how good the logs are when something goes wrong, and — the one people never consider until it bites them — whether the service also handles marketing mail, and whether you […]
Contact Form Notifications Not Arriving: Every Cause
Here's the version of this problem that costs the most: it's been happening for months and you don't know. The form says "thank you." The visitor believes they've reached you. You believe nobody's been in touch. There's no error, no bounce, no alert — just an absence, and absences are invisible. Most of the time […]
WooCommerce Order Emails Going to Spam: The Fix
"I never got a confirmation. Did my order go through?" Every store owner gets this message. And when it arrives often enough, you stop treating it as customer confusion and start realising your receipts genuinely aren't landing. This costs more than most email problems, because a missing order confirmation doesn't just annoy someone — it […]