WordPress White Screen of Death: The Recovery Mode Workflow

Your site goes white. No error message, no stack trace, nothing — just a blank page where your WordPress site used to be. The White Screen of Death (WSoD) is one of the most common failure modes in WordPress, and most guides jump straight to “disable all your plugins.” There’s a faster, less destructive path, and it starts with a feature most site owners don’t know exists.

What’s actually happening

A white screen almost always means PHP hit a fatal error with error display turned off — which is the correct production setting, but it means the error message goes nowhere visible. Plugin conflicts are by far the most common cause: a plugin update that breaks compatibility with your current PHP version, your theme, or another plugin. The error exists; you just can’t see it yet.

Step one: check your email for a recovery mode link

Since WordPress 5.2, core includes a feature called recovery mode that most people never notice until they need it. When WordPress detects a fatal error on the frontend, it automatically sends an email to the site administrator containing a special recovery mode link. Clicking that link logs you into wp-admin with the offending plugin or theme automatically paused — not uninstalled, just paused — so you can get back into the dashboard without touching a single file over SFTP.

This is the single fastest fix for a WSoD when you have admin email access, and it’s worth checking before doing anything else. If the email never arrived, check spam, and confirm your site’s admin email address is current and actually monitored.

Step two: turn on debug logging (not debug display)

If recovery mode isn’t available or doesn’t resolve it, enable logging in wp-config.php:

• define('WP_DEBUG', true);
• define('WP_DEBUG_LOG', true);
• define('WP_DEBUG_DISPLAY', false);

The third line matters as much as the first two — it keeps raw PHP errors from being printed directly onto the page for every visitor to see, while still writing them to wp-content/debug.log. Reload the broken page once, then open debug.log and look for the fatal error line. It will almost always name the specific plugin folder responsible. Remember to turn WP_DEBUG back off once you’ve found the issue — leaving it on exposes internal file paths and error details to anyone who happens to trigger an error.

Step three: isolate by bisection if the log isn’t clear enough

When the log doesn’t point clearly at one plugin, the standard bisection method still works and doesn’t require admin access:

1. Over SFTP or your host’s file manager, rename the wp-content/plugins folder to something like plugins-disabled. This deactivates everything at once without needing to log in.
2. Reload the site. If it comes back, the problem is a plugin.
3. Rename the folder back, then deactivate and reactivate plugins one at a time — checking the site after each one — until the white screen returns. That’s your culprit.

If the white screen persists even with every plugin disabled, switch to a default theme (Twenty Twenty-Four or similar) to rule out a theme conflict, and check your hosting panel’s PHP memory limit and PHP version — a mismatch between an updated plugin’s requirements and your server’s PHP version is a frequent, easy-to-miss cause.

One more place to look

If debug.log is itself empty despite the fatal error clearly happening, check your hosting panel’s raw server error log instead. Some fatal errors occur early enough in WordPress’s bootstrap process that core’s own debug logging never gets a chance to run — the server-level log catches those.