White Screen of Death in WordPress: diagnosing a blank page when the critical error screen never loads

You open your WordPress site and see nothing. No header, no footer, no error message, no text of any kind. The browser tab loads, the page finishes, and the result is pure white. View source shows an empty document. That is the classic White Screen of Death, and in 2026 it is rarer than it used to be but meaner when it happens.

What this actually means in 2026

Since WordPress 5.2 introduced the fatal error recovery mode in April 2019, most PHP fatals no longer produce a blank page. WordPress catches them in WP_Fatal_Error_Handler, returns HTTP 500, renders the "There has been a critical error on this website" screen, and emails the admin a recovery link. If you see that message instead of a blank page, you want the targeted fix in there has been a critical error on this website, not this article.

A fully blank page today means one specific thing: a PHP fatal fired so early in the request, or in a context the handler cannot reach, that WordPress never had a chance to render the fallback screen. On top of that, PHP's display_errors directive is off on virtually every production host (and should be), so the fatal is never shown on screen either. The result: silence.

Common causes of a blank page, ordered by likelihood

After years of seeing these on managed sites, the order is consistent:

1. A fatal in wp-config.php or an early-loaded file. A parse error in wp-config.php, in wp-settings.php, or in a must-use plugin under wp-content/mu-plugins/ fires before WP_Fatal_Error_Handler has been registered. The handler is set up via register_shutdown_function() during WordPress boot, so anything that crashes before that runs produces a raw blank page.
2. A parse error in a regular plugin or theme file. A missing semicolon or bracket in functions.php or a plugin file is a compile-time error (E_PARSE), and PHP refuses to execute the file at all. If the error is in a file loaded very early, or in a file that prevents the handler from initializing, you get a blank page instead of the critical error screen.
3. The critical error screen shows in wp-admin but the front end is blank. This is the most misleading variant. The fatal error handler ran fine on the admin request, and even sent you a recovery email, but a caching layer or a page cache plugin is serving a stale empty HTML document to visitors. The back end is healthy; the front end is a ghost.
4. Output buffering or caching ate the error page. A plugin that calls ob_start() without a matching ob_end_flush(), or a misbehaving page cache, can strip the critical error screen and write an empty response to the cache. Subsequent visitors get the empty response.
5. A fatal during WordPress maintenance mode. The handler explicitly skips execution when wp_is_maintenance_mode() is true. If an update died mid-flight and left a .maintenance file in the root, you can see a blank page for the duration.

The diagnosis path turns the blank page into a readable error before you touch any code.

Diagnose: turn the blank page into a readable error

You need to see what PHP is complaining about. The canonical approach lives in the WordPress debug documentation. Connect via SFTP or your hosting file manager, open wp-config.php in the WordPress root, and find this line:

define('WP_DEBUG', false);

Replace it with the safe logging configuration, inserted BEFORE the /* That's all, stop editing! Happy blogging. */ line:

// Enable debug mode
define('WP_DEBUG', true);
// Write errors to wp-content/debug.log
define('WP_DEBUG_LOG', true);
// Hide errors from visitors
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Save, reload the broken page once, then open wp-content/debug.log. The last entry is the fatal that produced the blank page. A typical line looks like:

[07-Apr-2026 09:14:22 UTC] PHP Parse error: syntax error, unexpected token ";" in /var/www/html/wp-content/plugins/some-plugin/init.php on line 42

You will know debug logging worked when wp-content/debug.log exists and contains a PHP Fatal error or PHP Parse error line dated to the failed page load. Note the file path and the line number. That is your entire answer.

No debug.log was created? One of three things is true. The host has overridden the log path (check your hosting control panel), the PHP process has no write permission in wp-content/, or the fatal happens inside wp-config.php itself before WP_DEBUG_LOG is defined. For that last case, temporarily flip the configuration to render errors directly by adding ini_set('display_errors', 1); and error_reporting(E_ALL); at the very top of wp-config.php, reload the page once, and read the error in the browser. Remove those lines immediately after. Never leave them on a live site; display_errors should never be enabled on production.

Apply the targeted fix

The debug log tells you the file and the error type. The fix lines up:

Parse error in a plugin or theme

If the log says PHP Parse error: syntax error, unexpected ..., a PHP file is malformed, almost always from a manual edit. The full diagnostic path lives in syntax error, unexpected: how to fix a PHP parse error in WordPress. The short version: open the named file at the named line, fix the typo, save.

You will know it worked when the site renders and debug.log stops growing.

Fatal inside a must-use plugin

If the log path contains /wp-content/mu-plugins/, a must-use plugin is crashing. These load before regular plugins and are common in managed hosting environments. Rename the file via SFTP (your-mu-plugin.php to your-mu-plugin.php.off) to disable it. Reload the site. If it recovers, the mu-plugin is the cause and needs to be repaired or removed by whoever installed it, which on managed hosts is often the host itself.

Fatal inside wp-config.php

Open wp-config.php and look for recent edits. A single stray character breaks the file. If you do not remember editing it, look for constants that reference files that no longer exist, or for constants defined twice. Restore from backup if you have one.

Memory exhausted before the handler ran

If the log says PHP Fatal error: Allowed memory size of N bytes exhausted, the script ran out of memory before WordPress could catch it. The per-cause fix lives in allowed memory size exhausted in WordPress. You will know it worked when the same page loads to completion and the memory line stops appearing in debug.log.

Blank front end, working admin

If wp-admin loads normally and you can reach it, but the front end is blank for visitors, the problem is not a fatal at all — and if you also see unexpected admin users or visitor redirects, the cause may be injected code covered in the WordPress hacked / malware redirect cleanup article. Otherwise, a. A page cache is serving an empty HTML document. Clear the page cache from your caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache), clear your host's server-side cache if it has one, and reload the front end in a private window. You will know it worked when visitors see the real page and the admin still works. If the cache keeps rebuilding the empty response, one of your plugins is writing an empty buffer during normal requests, which is a deeper bug and usually means paging through the plugin list the way php workers exhausted in WordPress describes for a related symptom.

HTTP 500 with a blank body

If the browser's Network tab shows a 500 response with zero bytes of body, the fatal happened, PHP caught it, and the web server returned 500 without any content. That is the same failure mode as a generic 500 Internal Server Error, and the server error log on your host is the fastest way to see the cause.

When to escalate

If the debug log never appears, or the blank page persists after every fix you try, hand the problem to your host or a WordPress specialist with the following bundle already collected. Every minute they save on context is a minute closer to your site being back up.

Collect before you ask:

• The exact HTTP status code and response size from the browser's Network tab on the failing request.
• Whether wp-admin loads independently of the front end.
• Your PHP version (from your hosting panel) and WordPress version (from wp-includes/version.php).
• The last 30 lines of wp-content/debug.log if one exists, or a note that it does not.
• Your web server error log if you can access it (most control panels expose this under "Error logs").
• A list of what you tried, in order, and what changed each time.
• Any change in the 24 hours before the page went blank: a plugin update, a PHP version change (see how to change the PHP version in WordPress for the full upgrade-and-rollback procedure), an edit to wp-config.php or functions.php, a theme switch.

How to prevent the next blank page

You cannot prevent every fatal, but you can make sure the next one renders the recovery screen instead of a blank page:

• Never edit wp-config.php or functions.php directly on a live site. Use staging, or at minimum keep a local copy of the file open so you can paste it back verbatim.
• Keep WP_DEBUG_LOG pointed at a writable path in wp-config.php, so future fatals land in a log you can read. Never enable WP_DEBUG_DISPLAY on a live site.
• Make sure the admin email works. The critical error handler's email recovery flow is useless if the address bounces. Test it with a simple password reset every few months.
• Take a backup before every update. Restoring from a known-good backup (if you don't have one yet, see WordPress backup strategy) is a 60-second fix; diagnosing a blank page without one is an afternoon.
• Run no more plugins than you use. Every active plugin is a potential source of the next fatal, and the average WordPress site ships with more plugins than it actually needs. When two plugins start interacting badly without throwing a fatal, the blank screen turns into a subtler "feature broke" symptom that has its own diagnostic path in how to find which plugin broke your site.