Fixing the White Screen of Death in WordPress

The WordPress white screen of death is a PHP fatal error with error display switched off: the code crashed before producing any HTML, and WordPress hides the error message so it cannot leak file paths and server details to visitors.

You update a plugin, reload the site, and get a blank page on the front end, often on wp-admin too. No error, no stack trace, nothing to click. The temptation is to start deactivating things at random, but the message already exists; it just isn’t being shown to you. Every step below works over SFTP or a host file manager, and there’s a database route for hosts that offer phpMyAdmin but no file access.

What Is the WordPress White Screen of Death?

A white screen means PHP hit a fatal error before it could render the page, and WordPress deliberately suppresses the error text on production sites because it can expose paths, versions, and other internals. The site’s files and database are intact; one component crashed the request.

Before touching anything, check the admin email inbox. Since version 5.2, WordPress emails the administrator when a fatal error occurs, naming the failing plugin or theme and including a link that enters Recovery Mode, a state in which the broken component is paused so you can reach the dashboard and deactivate it. That link carries a secret key; typing the Recovery Mode URL by hand does not grant access. If the email never arrives (spam filters eat it, and the email is only sent when the error hits a protected endpoint such as wp-login.php or the admin area, not a front-end page or a cron job), continue below.

Turn On Logging, Not Display

Open wp-config.php over SFTP or your host’s file manager and add these lines above /* That's all, stop editing! */:

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

Reload the broken page, then open the log, usually at wp-content/debug.log. Per the WordPress debugging documentation, WP_DEBUG_LOG has no effect unless WP_DEBUG is true, and WP_DEBUG_DISPLAY defaults to true, which is why the snippet sets it false explicitly. Never print errors to the page on a live site: every visitor would see server paths and code details. Remove all four lines once the site is fixed.

Read the Error: The Path Names the Culprit

The log gives you a file and a line number, and the directory in that path tells you which component failed. A realistic entry looks like this:

PHP Fatal error: Uncaught Error: Call to undefined function acme_slider_init() in /home/example/public_html/wp-content/plugins/acme-slider/includes/display.php:87

The path sits under wp-content/plugins/acme-slider/, so the Acme Slider plugin is the cause, and renaming that one folder fixes the site immediately. As a general rule:

If the log names a memory error instead, read the next section. Only if the log is empty do you fall back to the bisection steps.

How Do You Fix a WordPress Memory Exhaustion Error?

An error starting with Allowed memory size of X bytes exhausted means PHP hit its memory ceiling mid-request. Raise WordPress’s limit in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

WordPress defaults WP_MEMORY_LIMIT to 40M on single sites and 64M on multisite, and only ever raises PHP’s limit, never lowers it. The constant works only up to whatever ceiling your host enforces at the server level; if 256M changes nothing, the limit is the hosting plan, not the setting, and you’ll need the host to raise it.

How Do You Deactivate a Bad Plugin Without wp-admin?

If the log names a plugin, rename only that plugin’s folder inside wp-content/plugins/. If the log is empty, bisect: rename wp-content/plugins to plugins.hold, load /wp-admin/plugins.php so WordPress marks the missing plugins deactivated, rename the folder back, then switch the plugins on again one at a time, reloading the site after each, until it breaks. Turning every plugin back on by hand is the price of this route, but whatever settings each one stored are left alone.

No file access, but phpMyAdmin available? Open the wp_options table (your prefix may not be wp_), find the row where option_name is active_plugins, and copy or export its current option_value somewhere safe. Then replace the value with the serialized empty array a:0:{}, which deactivates every plugin at once. Restore the saved value later if you need the original list.

How Do You Disable a Broken Theme?

If the log points into wp-content/themes/, rename only the active theme’s folder, for example mytheme to mytheme.hold. WordPress falls back to a bundled default theme if one is installed; if none is, install one first via the file manager. The usual offender is functions.php, and the log has already told you the exact line, often a recent edit with a syntax error. Fix that line and rename the folder back.

Still Blank? Caches, Permissions, and PHP Version

Before trusting any result, purge every cache: the plugin’s page cache, any server cache, and your browser’s. A cached blank page can make a fixed site look broken, and a cached good page can hide a live error. Then check file permissions, typically 755 for directories and 644 for files on shared hosting, and confirm your PHP version: the baseline WordPress recommends is 8.3 or newer. A site on 7.4 will still load, but that branch stopped getting security fixes years ago.

Three cases sit outside this article’s scope: restoring from a backup (your host’s backup tool, noting you lose everything since the snapshot), corrupted core files (re-copy a fresh WordPress download over everything except wp-content and wp-config.php), and malware (follow your host’s hacked-site recovery process).

Wrapping Up

A blank WordPress page is a suppressed error message, not a mystery, and the fastest fix is always to read that message rather than guess around it. Add the four debug lines to wp-config.php now, reload once, and let the path in wp-content/debug.log tell you exactly which folder to rename.

FAQs

What is the difference between the white screen of death and the 'There has been a critical error on this website' message?

Since WordPress 5.2, a built-in fatal error handler catches most PHP fatal errors and prints the critical error message instead of a blank page. A fully white screen means PHP died before that handler could run, commonly from memory exhaustion or an error very early in the load, such as inside wp-config.php. Both stem from fatal PHP errors, and the debugging steps are identical.

Why is wp-content/debug.log empty even though WP_DEBUG is enabled?

The usual causes are an error that fires before the debug constants take effect, such as a syntax mistake inside wp-config.php itself, or a wp-content directory the web server cannot write to, which stops WordPress from creating the file. Confirm the constants sit above the stop-editing comment, then ask your host for the server-level PHP error log, which records fatal errors regardless of WordPress settings.

Why does the white screen appear on some pages but not others?

The fatal error lives in code that only executes on those requests. A crash in a theme template file blanks the front end while wp-admin keeps working, because the admin does not render front-end templates. A crash in admin-only plugin code does the reverse. Enable debug logging, load one broken page, and the file path in the logged error identifies the failing component.

Is it safe to leave WP_DEBUG and WP_DEBUG_LOG enabled after fixing the site?

No. The log defaults to wp-content/debug.log, a predictable web-accessible path that many hosts do not block, so anyone who requests that URL can read file paths, error details, and plugin internals, and the file grows without rotation. Remove the debug lines from wp-config.php once the site works, or set WP_DEBUG_LOG to a custom file path outside the public web root.