The WordPress White Screen of Death, Explained

The white screen of death is a PHP fatal error that you cannot see. WordPress hit an unrecoverable error mid-render, PHP stopped, and because error display is turned off on production servers, the page came back blank instead of printing the reason. The fix is almost never guesswork: turn on the debug log, open wp-content/debug.log, and read the last fatal line. It names the exact file — nearly always a plugin or theme — and that one line is the whole repair.

Why the screen is blank

PHP has a setting called display_errors. On a development machine it’s usually on, so a fatal error prints a stack trace to the screen. On a real host it’s off by default, because leaking file paths and errors to visitors is a security problem. So when something throws a fatal error — a call to a function that no longer exists, a class that isn’t loaded, a syntax error in a plugin update — PHP dies and sends nothing. Your browser renders an empty document. That’s the “white screen.”

Since WordPress 5.2 there’s a fatal error handler (WP_Fatal_Error_Handler) that tries to catch these. When it works, you don’t get a blank page — you get “There has been a critical error on this website,” plus an email to the admin address that often contains the actual error and a link to Recovery Mode. A truly blank screen usually means the error fired before that handler could run: a parse/syntax error (caught at compile time), a broken must-use plugin, or a fatal in the active theme’s functions.php. Either way, the cause is written down somewhere. You just have to switch on the writing.

Fix it, in order

1. Turn on the log. Edit wp-config.php over SFTP and add this above the /* That's all, stop editing! */ line:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_DISPLAY false keeps the errors off the public page while WP_DEBUG_LOG writes them to wp-content/debug.log. Reload the broken page once to generate a fresh entry.

2. Read the last fatal. Open wp-content/debug.log and look at the bottom:

tail -n 30 wp-content/debug.log

You’re looking for a line like this:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

The path names the culprit: plugins/some-addon. That’s your answer. If the trace is long or the message is cryptic (Allowed memory size exhausted, Cannot redeclare, a class name you don’t recognize), paste it into our error log decoder — it strips the noise, tells you which plugin or theme the path points to, and explains what the specific error type means.

3. Deactivate the named component. You can’t reach /wp-admin, so do it over SFTP. Rename the offending plugin’s folder, e.g. some-addon → some-addon.off. WordPress can’t load a folder it can’t find, so it deactivates the plugin and the site comes back. If the log points at your theme, switch to a default theme by renaming the active theme folder — WordPress falls back to a bundled twentytwentysomething.

4. If the log won’t write, wp-content isn’t writable, or the error is at the server level. Check the host’s PHP error log instead:

find . -name "error_log" -newermt "-1 hour"

Same information, different file. cPanel/Apache stacks often drop an error_log in the site root or in the failing directory.

What not to do

Don’t just raise the memory limit. The most-repeated advice online is to bump WP_MEMORY_LIMIT to 256M or 512M. That only fixes the WSOD if the log actually says Allowed memory size of N bytes exhausted. If the error is Call to undefined function, more memory does nothing — you’ve changed a setting at random and the screen is still white. Read the log first, then raise memory only if memory is the stated problem.

Don’t clear your cache and call it a diagnosis. The white screen is PHP dying on the server before any HTML exists. A stale cached asset can’t cause a blank document. (A broken caching plugin can — but the log will name it, which is the point.)

Don’t edit or reinstall core WordPress. The fatal is almost never in wp-includes or wp-admin; it’s in the plugin or theme the log points to. Reinstalling core is slow, risky, and treats a symptom you haven’t confirmed.

Don’t disable all plugins and re-enable them one by one blind. Bisecting works, but it’s the slow path. The log tells you the exact folder in one step. Reach for the “turn everything off” method only when there’s no readable error at all.

Don’t leave display_errors on in production. Once the site is back, remove the debug defines (or set WP_DEBUG back to false). Errors printed to visitors expose your paths.

Still stuck?

If the log names a plugin but disabling it doesn’t clear the screen, there’s a second fatal underneath the first — turn the log back on and read the new last line; fatals stack. If the message itself is the wall, drop it into the error log decoder and let it translate the error type and file path for you. The white screen only stays a mystery while the log is off.