WordPress White Screen of Death: How to Recover

What the White Screen Means (Fatal Error)

A white screen means PHP hit a fatal error it could not recover from — the request dies mid-execution before any HTML renders. Production servers hide the error text from visitors, so everyone sees blank instead of a message. On WordPress 5.2 and later the same crash usually shows as "There has been a critical error on this website" with an email to the admin address; the cause and the fix path are identical.

Work the ladder in order — the log first, folder renames second:

1. Enable WP_DEBUG — edit wp-config.php: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); then read wp-content/debug.log for the actual fatal.
2. Raise memory — define('WP_MEMORY_LIMIT', '256M'); in wp-config.php; exhaustion is the most common cause.
3. Disable plugins by rename — rename wp-content/plugins to plugins.old; site returns? Rename back and bisect.
4. Switch theme — rename the active theme's folder; WordPress falls back to a default.
5. Front-end only vs wp-admin — admin-only whites point at admin-specific plugins and functions.

The full error-reading discipline lives in the PHP error logs guide, and the sibling failure mode in the WordPress 500 error guide.

Step 1: Enable WP_DEBUG to See the Real Error

Debug mode turns the blank screen into a named file and line number. Open wp-config.php in the site root and add these lines above the "stop editing" comment: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); — the last one keeps errors off the visitor-facing page while you work.

Reload the site, then open wp-content/debug.log and search for "Fatal error". The entry names the plugin file, theme file or memory ceiling that failed, which decides which step below applies. Turn debugging off once the site is fixed; leaving it on is a small information leak.

Step 2: Raise the PHP Memory Limit

Step two: raise the PHP memory limit when the log or the symptom pattern says exhaustion. WordPress works within PHP's memory_limit; busy plugins — page builders, importers, WooCommerce with large catalogs — exceed 64–128 MB defaults on ordinary days. Three places to raise it, in order of preference: wp-config.php with define('WP_MEMORY_LIMIT', '256M'); (WordPress-level), cPanel → MultiPHP INI Editor setting memory_limit (server-level, where the panel permits), or php.ini on VPS-class servers.

Verify the change landed via Site Health → Info → Server. If the white screen persists at 256M, memory was not the cause — return to the debug log, because guessing past this point wastes the afternoon the log would have saved.

Step 3: Disable Plugins via FTP Rename

This works without admin access. In the file manager, rename wp-content/plugins to plugins.old and reload the site. If it returns, a plugin caused the crash; rename the folder back — the site breaks again, which is expected — then rename individual plugin folders one at a time, reloading between each, until the culprit shows.

Check wp-content/mu-plugins too: must-use plugins load automatically, never appear in the plugins list, and crash sites just like ordinary ones. Rename every plugin back to active once the faulty one is identified.

Step 4: Switch to a Default Theme

If the plugins test came back clean, or the log points at a theme file, rename the active theme's folder inside wp-content/themes. WordPress falls back to an installed default theme automatically.

The usual culprit is a functions.php edit — a missing semicolon or bracket from a pasted snippet. Fix the syntax error named in the log, or restore the file from backup, before switching back. No default theme installed? Download one from wordpress.org and upload the folder first.

Front-end Only vs wp-admin White Screens

The split is diagnostic. Admin loads but the front end is blank: suspect the theme, because wp-admin renders without it. Both are blank: a plugin or memory problem, because plugins load for every request, admin included.

One blank page while the rest of the site works points at that page's content — usually a malformed shortcode or a template-level PHP error, not a site-wide fault. The debug log entry will name one file.

Prevention: Staging Updates and Backups

A backup you have never restored is a hope, not a backup. Keep a copy off the same server that hosts the site, and restore files and the database together so they match. On WebJi®, free migration of an existing site is available subject to terms and approval — open a ticket before the old host deletes the account.