How to Fix the WordPress White Screen of Death

Quick fix: check the WordPress administrator email for a Recovery Mode link. If there is no email, enable logging in wp-config.php, reload the blank page once, and read the final fatal error in wp-content/debug.log. The file path usually identifies the plugin or theme that must be disabled or rolled back.

Do not start by reinstalling everything. A white page is a symptom; the error log is the shortest route to its cause.

First, identify the scope

Open the site in a private browser window and test:

• the homepage;
• a normal post or page;
• /wp-admin/;
• /wp-login.php;
• the REST API at /wp-json/.

If only one URL is blank, suspect its template, block or shortcode. If the frontend is blank but wp-admin works, suspect the active theme or frontend-only plugin code. If both frontend and admin are blank, a plugin, PHP compatibility problem or incomplete update is more likely.

Check the hosting status page before changing WordPress. A server outage cannot be repaired by renaming plugins.

Use WordPress Recovery Mode

Since WordPress 5.2, the fatal error handler can pause the failing plugin or theme for an administrator session and email a Recovery Mode link.

Search the site administrator inbox and spam folder for a message such as “Your Site is Experiencing a Technical Issue.” The email normally names the failing component.

Open its unique link, sign in, and then:

1. note the reported error;
2. deactivate or update the failing component;
3. check whether a rollback or vendor fix exists;
4. exit Recovery Mode only after the public site works.

If mail delivery failed, continue with logging.

Enable a private debug log

Back up wp-config.php, then place these lines above the “stop editing” comment:

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

Reload the affected URL once and inspect:

wp-content/debug.log

The official WordPress debugging guide recommends hiding errors from visitors while logging them. A log can expose paths and sensitive context, so remove or protect it after diagnosis.

Read from the bottom. Look for PHP Fatal error, Uncaught Error, Allowed memory size exhausted or a repeated file path. Warnings that predate the outage may be unrelated.

For a detailed setup and cleanup procedure, see How to Enable WordPress Debug Mode.

Disable the failing plugin

If the log points into wp-content/plugins/plugin-name/, disable that plugin.

With WP-CLI:

wp plugin deactivate plugin-name

Without SSH or wp-admin, use SFTP or the hosting file manager and rename only that directory:

wp-content/plugins/plugin-name
wp-content/plugins/plugin-name.disabled

Reload the site. If it works, keep the plugin disabled and investigate its changelog, PHP requirements and support channel. Do not reactivate it on production just to confirm the crash.

If the log does not identify one plugin, follow How to Disable WordPress Plugins Without Admin Access to isolate all plugins safely.

Switch away from a broken theme

If the fatal path is inside the active theme, first confirm that a maintained default theme is installed.

With WP-CLI:

wp theme list
wp theme activate twentytwentysix

Use the actual installed default-theme slug shown by the first command. On a staging copy, you can instead rename the active theme directory; WordPress may fall back to an available default theme.

Do not rename the only installed theme on a live site without a fallback. That can replace one failure with another.

Once access returns, move customizations into a child theme or repair the incompatible code. Never edit a vendor theme merely to suppress the error if the next update will overwrite the patch.

Check for memory exhaustion

When the log explicitly says Allowed memory size ... exhausted, temporarily request a higher WordPress limit above the wp-settings.php inclusion:

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

The server’s PHP limit can prevent WordPress from raising it. More memory also does not fix an infinite loop or a plugin loading excessive data. Use How to Increase the WordPress Memory Limit to verify the effective value and find the consumer.

Review the change that triggered it

Match the first failure time with:

• a plugin, theme or core update;
• a PHP version change;
• a code deployment;
• a restored backup;
• changed file permissions;
• disk space exhaustion.

Rollback the smallest responsible component from a trusted backup or vendor package. Avoid downgrading PHP blindly; an old unsupported PHP version can hide compatibility problems while creating security risk.

Restore WordPress core files

If logs point into wp-admin or wp-includes, or an update was interrupted, verify core checksums:

wp core verify-checksums

You can replace wp-admin and wp-includes with clean files from the same official WordPress release. Preserve wp-content and wp-config.php; they contain site-specific code, uploads and configuration.

Take a backup first and use only an official package. Replacing core files will not repair a broken plugin or database.

Confirm the fix and clean up

Test logged-in and logged-out pages, forms, scheduled tasks and the URL that originally failed. Then disable debugging on production:

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

Delete or secure debug.log, clear only the relevant caches, and document the error plus the component version that caused it. If the blank page has become an HTTP 500 response, continue with How to Fix a 500 Internal Server Error in WordPress.