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.

TL;DR: A white screen means a PHP fatal error, not a “glitch.” (1) Add the three WP_DEBUG lines to wp-config.php over SFTP. (2) Reload the broken page once, then read the last line of wp-content/debug.log. (3) That line names the plugin or theme folder at fault — rename it over SFTP (some-addon → some-addon.off) to deactivate it without wp-admin. (4) Turn WP_DEBUG back off once the site is back. No step before “read the log” — not clearing cache, not raising memory, not reinstalling core — fixes a white screen, because none of them tell you which file actually failed.

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), registered in wp-settings.php before plugins, must-use plugins or the active theme ever load. 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. That covers most fatals, including a broken plugin or a fatal in the active theme’s functions.php. A truly blank screen is narrower: a parse/syntax error (caught by PHP at compile time, before WordPress itself ever runs) or a fatal low enough in the loading sequence that the handler isn’t registered yet. 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. WordPress’s own wp-config-sample.php already defines WP_DEBUG once (as false) — PHP keeps a constant’s FIRST definition and silently ignores a later define() of the same name, so adding a second define( 'WP_DEBUG', true ) below it does nothing. Find that existing line instead and change false to true, then add the other two lines above /* That's all, stop editing! */:

define( 'WP_DEBUG', true );        // change the EXISTING line, don't add a duplicate
define( 'WP_DEBUG_LOG', true );    // new — add this one
define( 'WP_DEBUG_DISPLAY', false ); // new — add this one
@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. (New to these settings, or not sure where the existing WP_DEBUG line is? See how WordPress debug mode works.)

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 — a real entry from our test server, reproduced below as text so it’s easy to copy:

[01-Nov-2026 16:57:07 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function some_addon_missing_helper() in /wordpress/wp-content/plugins/some-addon/some-addon.php:6
Stack trace:
#0 /wordpress/wp-includes/class-wp-hook.php(353): {closure}('')
#1 /wordpress/wp-includes/class-wp-hook.php(377): WP_Hook->apply_filters(NULL, Array)
#2 /wordpress/wp-includes/plugin.php(523): WP_Hook->do_action(Array)
#3 /wordpress/wp-includes/template-loader.php(23): do_action('template_redire...')
#4 /wordpress/wp-blog-header.php(19): require_once('/wordpress/wp-i...')
#5 /wordpress/index.php(17): require('/wordpress/wp-b...')
#6 {main}
  thrown in /wordpress/wp-content/plugins/some-addon/some-addon.php on line 6

The path names the culprit: plugins/some-addon. That’s your answer — on a live host the path starts with your own document root (e.g. /var/www/html/... or /home/user/public_html/...) instead of /wordpress, since that prefix is just where our test server keeps WordPress. 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.

The exact wording after PHP Fatal error: tells you which of a handful of causes you’re dealing with, before you even open the decoder:

Log message contains	Likely cause	Fix
Call to undefined function	A plugin calls a function from another plugin (or from WooCommerce/a theme) that isn’t active or loaded yet	Activate the missing dependency, or deactivate the plugin that calls it — don’t touch memory or core
Allowed memory size of N bytes exhausted	A script genuinely ran out of PHP memory	Raise WP_MEMORY_LIMIT (and the host’s memory_limit) — this is the one case where more memory is the real fix
Cannot redeclare	The same class or function is loaded twice — often a duplicated plugin, or one plugin bundling a library another plugin also bundles	Deactivate (rename) one of the two conflicting plugins; don’t reinstall core
Parse error: syntax error	A plugin or theme file was edited or updated with a typo (often a half-applied FTP upload)	Re-upload the named file clean, or roll back to the last working copy over SFTP
Uncaught Error: Class "X" not found	A plugin was deactivated or deleted but another plugin/theme still expects its class	Reactivate the missing plugin, or remove the code in the file the log names that still calls it

This is a reference table of PHP/WordPress fatal-error patterns, not a benchmark — treat the log’s own wording as the final word over any table; when in doubt, run it through the error log decoder.

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, rename the active theme’s folder the same way — but know what that actually does: it stops the fatal (the theme’s functions.php can no longer load), which brings /wp-admin back, but it does not switch your front end to a working theme by itself. validate_current_theme() — the function that auto-switches you to a bundled default theme — only runs from one place: the Appearance → Themes screen (the Customizer triggers it too). Loading the Dashboard, Posts, or any other admin screen does not call it. So after renaming: log into /wp-admin (it works again now that the fatal is gone), open Appearance → Themes once, and WordPress will auto-switch you to a bundled default theme there. The front end comes back after that specific screen loads, not immediately after the rename and not after just any admin page.

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, and don’t forget the log file itself. Once the site is back, remove the debug defines (or set WP_DEBUG back to false) so errors stop printing to visitors. Separately, wp-content/debug.log is a plain text file inside the public web root — on hosts without directory-listing protection it stays readable at yoursite.com/wp-content/debug.log even after WP_DEBUG is off, leaking file paths and error details to anyone who requests it. Delete the file, or add a .htaccess/server rule blocking direct access to *.log, once you’re done reading it.

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.

Sources

• WordPress Advanced Administration: Debugging in WordPress
• WordPress source code: class-wp-fatal-error-handler.php
• PHP manual: display_errors
• PHP manual: memory_limit