WordPress White Screen of Death: Find the Cause

You load your site and get nothing — a blank white page where your homepage used to be. No error, no hint, just white. Sometimes wp-admin is white too, which makes it feel like the whole site has vanished. It's one of the most alarming things a site owner can see, and the silence is the worst part.

That silence is deliberate. When a PHP fatal error fires during page load, WordPress dies before it can render anything — including the error itself, which PHP hides from visitors by default. Under the white screen there's always a specific cause: a plugin update that fatals, a theme calling a missing function, or PHP running out of memory mid-render.

This guide gives you a fixed order of operations. You'll turn on WP_DEBUG to surface the real error, bisect plugins in minutes by renaming one folder, switch themes without wp-admin access, and bump the memory limit when that's the culprit. Follow the order and you'll go from blank page to named culprit fast. Keep SFTP and database access handy before you start — every step below uses one of the two.

Why the Screen Is White Instead of Helpful

PHP fatal errors stop script execution immediately — no shutdown HTML, no footer, nothing. When the fatal fires inside a plugin file loaded before the theme renders, WordPress dies with zero output. Production servers also set display_errors to off, so even the error text is swallowed. The result is a 200 OK response with an empty body: the infamous white screen.

This is actually a security choice. Showing stack traces to visitors would leak file paths and plugin versions to attackers. WordPress and PHP hide errors from the screen but still write them to logs. The information exists — it's in the PHP error log or wp-content/debug.log — waiting for someone with file access.

So the white screen is never the diagnosis; it's the absence of one. Your job isn't to stare at the white page but to fetch the hidden error text. A phone screenshot of white tells nobody anything — the log line tells everybody everything. Note the exact clock time of each white page next to the fatal line; matching timestamps across mirrored servers distinguishes a fleet-wide bad deploy from an isolated failure in seconds. Everything in this guide flows from that single move: turn on logging, read the fatal line, act on the filename it gives you.

Enable WP_DEBUG to Surface the Real Error

WP_DEBUG is the master switch. Setting it true in wp-config.php tells WordPress to report errors instead of hiding them. Pair it with WP_DEBUG_LOG so errors land in wp-content/debug.log, and keep WP_DEBUG_DISPLAY false on live sites so visitors still see nothing sensitive. Reload the white page once, then read the log's tail.

The fatal line follows a pattern: PHP Fatal error: Uncaught Error: Call to undefined function ... in /.../wp-content/plugins/some-plugin/file.php on line 42. The path is the diagnosis — wp-content/plugins names the plugin, wp-content/themes names the theme. Note the exact file and line; you'll need them when reporting the bug or editing around it.

One caution: debug.log grows fast on busy sites and can fill small disks. Read what you need, fix the issue, then set WP_DEBUG back to false and delete the log. On multisite, network-activated plugins log against every subsite, so check timestamps to match the error to the white page you just loaded. Never leave debugging on permanently — it slows the site and can leak paths if display ever flips on. While debugging, keep a second browser tab on the host file manager so each config change is one click from verification.

// Enable logging (keep display off on live sites)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Then reload the white page once and read the log:
// wp-content/debug.log — look for the last "PHP Fatal error" line

Bisect Plugins by Renaming One Folder

Plugins cause most white screens, and the fastest test disables all of them at once. Rename /wp-content/plugins to /wp-content/plugins-off over SFTP, then create a new empty /wp-content/plugins directory. WordPress sees no plugins and loads cleanly. If the white screen clears, a plugin is guilty — proven in under a minute with zero database edits.

Now find which one. Move plugin folders back from plugins-off one at a time, reloading the site after each. When the white screen returns, the last folder you moved is the culprit. With 30 plugins this takes a while, so use halves instead: move back half, test, and keep halving the guilty group. Binary search finds one bad plugin among 32 in at most 5 reloads.

WP-CLI users can do the same without renaming: wp plugin deactivate --all, confirm the site loads, then wp plugin activate one-slug at a time. Must-use plugins in wp-content/mu-plugins don't deactivate this way — rename that folder too if the screen persists. Leave the guilty plugin deactivated, restore everything else, and check for an update or a support thread about the fatal — popular plugins usually ship a fix within days. Document the culprit and version in the site runbook so the next update of that plugin gets staged first.

# Disable everything at once (no wp-admin needed)
wp plugin deactivate --all
# reload the site — if it works, a plugin is guilty

# Reactivate one by one until the white screen returns
wp plugin activate query-monitor
wp plugin activate wordfence
wp plugin activate broken-slug-here  # white screen? culprit found

# Leave the culprit off and bring back the rest
wp plugin deactivate broken-slug-here
wp plugin activate --all --exclude=broken-slug-here

Rule Out the Theme via WP-CLI or Database

If the site stays white with plugins disabled, the theme is next. Active themes run functions.php on every load, and a single fatal there whites out everything. You can't use Appearance menus (wp-admin is white too), so switch themes from WP-CLI or the database.

WP-CLI is one command: wp theme activate twentytwentyfour (use whatever bundled theme your install has). Reload — if the site renders, your theme fatals. The debug.log line will point at the exact theme file, usually functions.php or a template part calling a function from a now-disabled plugin.

Without SSH, use phpMyAdmin: open wp_options, edit the rows named template and stylesheet, and set both to twentytwentyfour. Clear any object cache after the switch — stale cached theme paths can keep serving the white page after the database already points elsewhere. Reload and test. Child themes deserve a special check — a child calling a parent function removed in a parent update fatals identically, so test with the parent active too before blaming custom code. Snapshot the theme folder and export customizer settings before switching; some themes store per-theme mods that vanish on switch, and restoring them by hand wastes an afternoon.

# Switch to a bundled theme without wp-admin
wp theme activate twentytwentyfour
wp theme list --status=active

# No SSH? Run this in phpMyAdmin instead:
# UPDATE wp_options SET option_value = 'twentytwentyfour'
# WHERE option_name IN ('template', 'stylesheet');

# After the site returns, confirm what the theme broke
tail -n 20 wp-content/debug.log

Raise the Memory Limit When PHP Starves

Some white screens are resource deaths, not code bugs. Page builders, multilingual plugins, and big WooCommerce catalogs can exceed the default 40–64M WordPress memory limit during render. The debug.log signature is unmistakable: Allowed memory size of X bytes exhausted. That line means the code is fine but the allowance is too small.

The first bump goes in wp-config.php: define WP_MEMORY_LIMIT as 256M. Reload and watch the log. If the error persists with a higher number, the host's PHP memory_limit ceiling is lower than your request — WordPress can't grant itself more than PHP allows. Check Site Health > Info > Server or ask the host what memory_limit is actually set to.

Treat repeated exhaustion as a smell, not just a number to raise. A plugin leaking memory per post will eat 256M as happily as 64M on large archives. Check the exhaustion byte count after the raise — if it now reads 256M, the code consumed your headroom and an audit is due. Use Query Monitor on staging to find the hungry component, and don't push WP_MEMORY_LIMIT past what your plan provides — on shared hosting, asking for 512M just moves the kill to the host's process watcher. Note the post-raise byte figure in the runbook; the next person compares ceilings instead of starting blind.

// Give WordPress more headroom (place before "stop editing" line)
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' ); // admin-side limit

// If the host caps PHP below this, WordPress can't exceed it —
// check Site Health > Info > Server for the real PHP memory_limit.

Fix Corrupted Core After Failed Updates

Sometimes the white screen follows a core auto-update that died halfway — a timeout during unzip leaves half-written files in wp-admin or wp-includes. Every page then fatals on a missing class. The signature is a fatal naming a wp-includes or wp-admin path rather than a plugin or theme.

The fix is a clean core reinstall that preserves your content. Download the WordPress zip matching your version, extract it, and upload fresh copies of wp-admin and wp-includes, overwriting the damaged ones. Never touch wp-content or wp-config.php — your themes, plugins, uploads, and settings live there. Reload after the upload.

Verify with wp core verify-checksums, which compares every core file against wordpress.org hashes and lists anything modified or missing. If checksums pass but the screen persists, the damage sits in wp-content or the database — return to the plugin and theme bisect. Keep the downloaded release zip for a week in case the dashboard updater needs files the host firewall blocks. Then re-run the update from Dashboard > Updates with plugins disabled. To stop repeats, schedule updates for quiet hours and make sure PHP timeouts and disk space can handle the unzip — most half-written cores come from 30-second timeouts on slow shared hosts.