WordPress white screen of death: the fix, in order

The white screen of death is worse than the critical-error box for one reason: it tells you nothing. No message, no email, no hint. Newer WordPress versions usually catch a fatal error and show the polite box instead, so when you get a pure white page in 2026 it means one of three things: the error happened before WordPress could catch it, the output was cut off halfway, or something is deliberately hiding it. All three are findable. Here is where I look, in order.

Step 01 Check whether it’s really blank

Right-click the white page and choose “View page source”. A truly blank source means PHP stopped before printing anything. If instead you see a full page of HTML, the problem is in the browser: usually a CSS or JavaScript file that fails to load and leaves the page invisible, not broken. Open the browser console (F12) and look for red lines. A net::ERR or a 404 on a stylesheet is a hosting, CDN, or caching issue, not a PHP one, and clearing the site cache (plugin and host) fixes a surprising share of “white screens”.

Also check wp-admin separately. If the front end is white but /wp-admin/ loads, the fault is in your theme. If both are white, it’s a plugin, core, or the server.

Step 02 Make the error visible

A white screen is a fatal error with display_errors off. Turn on logging in wp-config.php, above the “stop editing” line:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload once and read wp-content/debug.log. If the log stays empty, the error may be happening before wp-config.php is even reached, or the host blocks writes to that folder. In that case your hosting panel’s error log (cPanel: “Errors”; most managed hosts: Logs → PHP) has it. Look for the newest line containing PHP Fatal error or PHP Parse error.

Plain English A parse error means a file has a typo in it, usually functions.php after someone pasted a snippet. A fatal error means the code ran and hit a wall. Both name the file and line.

Step 03 Deactivate plugins from the file system

Over FTP or your host’s file manager, rename wp-content/plugins to plugins-off and reload. If the site returns, rename it back and reactivate plugins one at a time in wp-admin until the white screen comes back. The last one you activated is the cause. If you have a hunch (you updated one plugin right before this started), rename only that plugin’s folder first and save yourself the elimination round.

Step 04 Rename the theme

If only the front end is white, this is the likeliest step. In wp-content/themes/, rename your active theme’s folder; WordPress falls back to a default theme. If the site loads, the error is in your theme, and it is nearly always functions.php: a pasted snippet with a missing semicolon, a closing ?> followed by a blank line, or a function that was already defined by a plugin.

The ?> trap A stray space or newline after a closing PHP tag in functions.php sends output before WordPress is ready and can blank the page or break logins with “headers already sent”. Delete the closing tag entirely; PHP files don’t need it.

Step 05 Raise the memory limit

The classic white-screen cause. If the log says Allowed memory size … exhausted, add define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php. If the host caps PHP memory below that, raise it in the hosting panel or php.ini. This gets the site back; it doesn’t explain why a page needed more than 128 MB, and that question usually has a plugin’s name as the answer.

Step 06 Core files and the server

Two remaining places. A failed automatic update can leave wp-includes half-written; re-upload wp-admin and wp-includes from a fresh download of the same version (never wp-content, never wp-config.php). And if the log mentions mysql, MySQL server has gone away, or nothing at all while the host’s status page shows trouble, the site isn’t broken, the server is. That’s a ticket to the host, and a good moment to reconsider the host.

If you’ve done all six and it’s still white, something is unusual enough that a post can’t guess it: a server misconfiguration, a .htaccess rule from a security plugin, a disk that ran out of space. That is the point where I’d want the logs in front of me, and it’s the rescue I do most often.

Rather hand it over at this point? Finding the one plugin, theme or file behind the error is the first thing our critical error fix does, with a fixed price before we start.