How to Fix the WordPress White Screen of Death

The WordPress white screen of death is what you get when PHP dies before it can render anything, so the browser receives an HTTP 200 with an empty body. No error text, no stack trace, just white, because the fatal error happens after output has already been buffered or because display of errors is switched off in the running configuration.

That last part is the whole trick to fixing it. The site is almost never truly silent. It is silent because display_errors is off and WP_DEBUG is false, which is exactly how production sites are supposed to be configured. Your job is to turn the noise back on in a controlled way, read the fatal error, and then remove or repair the one file that caused it.

Confirm it is PHP and not the web server

Before touching WordPress, separate the two failure modes. A blank page from the web server and a blank page from PHP look identical in a browser but behave differently on the wire. Ask for the headers only:

curl -sSI https://example.com/
HTTP/2 200
content-type: text/html; charset=UTF-8
content-length: 0

A 200 with content-length: 0 means the request reached PHP, PHP started, and then something fatal happened before any bytes were flushed. A 500, a 502, or a 503 with an empty body points somewhere else: the PHP-FPM pool is down, the upstream timed out, or the process manager killed the worker. Check the web server error log first in that case, then the PHP-FPM log, because a worker that segfaults on startup will never produce a WordPress error at all.

If you do get a 200 and zero bytes, you are in the right place. Continue.

Turn on error reporting without breaking the live site

Editing wp-config.php is the standard move, but do it deliberately. Set the debug constants so errors are written to a file instead of printed to the page, because printing them to the page on a live site leaks absolute paths and database details to anyone who loads the URL.

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

With that in place, WordPress writes to wp-content/debug.log. Tail it while you reload the broken page:

tail -f wp-content/debug.log

A fatal error line names the file and the line number, something like PHP Fatal error: Uncaught Error: Call to undefined function followed by the path of the offending file. That path is your answer. If the log stays empty and the page is still blank, the fatal happened before WordPress loaded its own error handler, which usually means the problem is in wp-config.php itself or in a php.ini setting. Check the PHP error log configured at the server level in that case.

Find the faulty plugin or theme by bisection

Once you know a plugin or theme is throwing the fatal, do not read code. Bisect. The fastest reliable method is to rename directories rather than deactivate through the admin, because you often cannot reach the admin at all when the front end is white.

Rename the plugins directory so WordPress cannot load any of them:

mv wp-content/plugins wp-content/plugins.off

Reload the site. If it comes back, the fault is in a plugin. Rename the directory back and then move plugins out in halves, reloading between each move, until the site breaks again. The last directory you moved is the culprit. This takes a handful of reloads even on a site with many plugins, and it never depends on guessing which plugin looks suspicious.

If the site is still white with all plugins disabled, the theme is the next suspect. Switch to a default theme by renaming the active theme directory and letting WordPress fall back, or by setting the theme in the database directly if the admin is unreachable. A theme fatal is most often a missing function from a companion plugin that you just disabled, which is worth remembering before you blame the theme itself.

Check the PHP version and memory limit

Two configuration problems produce a white screen with no plugin involved. The first is a PHP version mismatch: a theme or plugin written for an older language version calls a function or uses syntax that the current interpreter rejects, and the parse error kills the request before anything renders. Confirm what the site is actually running rather than what you think it runs:

php -v
php -i | grep -E 'memory_limit|display_errors'

Run that as the same user the web server uses, or check the version through a temporary file in the document root, because the command line interpreter and the FPM pool can be configured differently. The second problem is memory exhaustion. A request that asks for more than memory_limit allows is terminated, and depending on how the handler is configured you may get a white page rather than an error. Raise the limit in php.ini, in the pool configuration, or in wp-config.php with WP_MEMORY_LIMIT, then reload. If the page returns only after a large increase, you have a plugin with a genuine leak, not a limit that needs to stay high forever.

Recovering when you cannot reach the admin

If the front end and the admin are both white, you cannot click anything, so work from the shell. Disable plugins by renaming the directory as shown above, then log in and re-enable them one at a time. If the database is the suspect, check that the credentials in wp-config.php still work with a direct connection, since a failed database connection in some configurations also yields a blank page. Keep a copy of any file before you edit it, and prefer renaming to deleting so that reverting is a single command.

When the site is back, do not stop at the fix. Read the fatal error line again and identify whether the cause was a plugin update, a PHP version change, or a theme edit, because that tells you what to guard against next time. Set up staging so the next update is tested somewhere that is allowed to break, keep the debug log enabled on staging rather than production, and make sure you can reach the error log without loading WordPress. The white screen is not the problem; the missing error output is, and once you can always see the fatal, this failure stops being frightening.