How to Fix the WordPress White Screen of Death (WSOD)

The WordPress white screen of death can be caused by plugins, themes, or PHP errors. Here is how to diagnose and fix it step by step.

Dobromir Dechev
Dobromir WordPress agency owner

Quick answer

The WordPress White Screen of Death is caused by a PHP fatal error that WordPress silently suppresses — enable WP_DEBUG in wp-config.php to reveal the actual error message, then deactivate plugins or switch themes to isolate the cause.

The WordPress White Screen of Death (WSOD) is exactly what it sounds like: a completely blank white page where your website should be. No error message. No WordPress admin. Just white. It is one of the most disorienting things that can happen to a WordPress site, and it usually strikes at the worst possible time - right after an update or a new plugin install.

This article covers every cause and fix, from the 30-second solutions to the deeper server-level debugging.

Why the WSOD happens

The white screen is PHP crashing silently. By default, WordPress suppresses error output on the frontend to prevent exposing sensitive stack traces to the public. The result is a blank page with no useful information.

The underlying cause is almost always one of:

  • A PHP fatal error in a plugin or theme
  • PHP running out of memory (WP_MEMORY_LIMIT too low)
  • An infinite loop or recursion somewhere in the code
  • A corrupted WordPress core file (rare, usually after a bad update)
  • Incompatible PHP version after a host upgrade

Step 1 - Check if it is frontend-only or site-wide

First, visit /wp-admin/. If the admin loads normally but the frontend is white, the problem is in your theme's template files. If both are blank, the problem is deeper - likely a plugin that hooks early, or a PHP memory issue.

Also check: is the WSOD on every page, or just specific ones? A blank page only on posts but not the homepage points to a conflict in single.php or a shortcode.

Step 2 - Enable WP_DEBUG

WordPress suppresses errors by default. Turn them on:

Open wp-config.php and change (or add) these three lines:

define( 'WP_DEBUG',         true );
define( 'WP_DEBUG_LOG',     true );
define( 'WP_DEBUG_DISPLAY', false ); // keep false — write to log, not screen

With WP_DEBUG_LOG set to true, errors are written to /wp-content/debug.log. After refreshing the white screen page, open this file:

tail -50 /wp-content/debug.log

You will see the actual PHP error. It will look something like:

PHP Fatal error:  Uncaught Error: Call to undefined function acf_add_options_page()
in /wp-content/themes/mytheme/functions.php on line 47

That tells you exactly which file and line to fix. In most cases the WSOD is solved at this step.

Important: turn WP_DEBUG back off after diagnosing. Debug mode exposes information that should not be public.

Step 3 - Deactivate all plugins via FTP

If the debug log is empty or you cannot access wp-config.php, deactivate all plugins without using the admin. Connect via FTP or SSH and rename the plugins directory:

# Via SSH
mv /wp-content/plugins /wp-content/plugins_disabled

Then reload the site. If it comes back, one of your plugins was causing the problem. Rename the folder back:

mv /wp-content/plugins_disabled /wp-content/plugins

Now reactivate plugins one at a time through the admin, refreshing the frontend after each one until you find the culprit.

If renaming the plugins folder did not fix the WSOD, move on to the theme.

Step 4 - Switch to a default theme via FTP

If the problem is in the active theme, the admin may still be accessible. Go to Appearance > Themes and switch to Twenty Twenty-Four.

If the admin is also blank, switch the theme via the database. Go to phpMyAdmin or run via WP-CLI:

wp theme activate twentytwentyfour

Or update the database directly:

UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';

If the site comes back after switching themes, the problem is in your theme. Check the theme's functions.php first - look at the most recently modified files.

Step 5 - Increase PHP memory limit

PHP running out of memory produces a blank screen (or sometimes a partial page that cuts off mid-render). In wp-config.php:

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

For the admin specifically:

define( 'WP_MAX_MEMORY_LIMIT', '512M' );

You can also set this in .htaccess on Apache:

php_value memory_limit 256M

Or in a php.ini file if your host allows it:

memory_limit = 256M

After increasing memory, reload the white screen. If it comes back, this was the cause. Check which plugin or theme was consuming unusual amounts of memory by looking at the debug log for an out-of-memory error:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

Step 6 - Check PHP error logs (server-level)

The WordPress debug log only captures errors that PHP passes through WordPress. Some fatal errors happen before WordPress even loads - for example, a syntax error in wp-config.php itself.

Check the PHP error log directly. Location varies:

# Apache + Ubuntu
sudo tail -100 /var/log/apache2/error.log

# Nginx + PHP-FPM
sudo tail -100 /var/log/nginx/error.log
sudo tail -100 /var/log/php8.1-fpm.log

# cPanel hosts
# Usually in ~/public_html/logs/ or via cPanel > Error Log

A syntax error in wp-config.php will appear here:

PHP Parse error: syntax error, unexpected token ")" in /var/www/html/wp-config.php on line 32

Step 7 - Increase PHP execution time

Some operations - importing large databases, regenerating thumbnails, running WooCommerce reports - hit the max_execution_time limit and produce a blank screen instead of a timeout message. In php.ini:

max_execution_time = 120

Or in .htaccess:

php_value max_execution_time 120

This is rarely the cause of a WSOD on normal page loads, but common during bulk operations.

Step 8 - Check for a corrupted wp-settings.php or core file

A failed WordPress core auto-update can leave corrupted files. If the error log points to a core file (anything in /wp-includes/ or /wp-admin/includes/), re-upload WordPress core without overwriting wp-content/ and wp-config.php.

The cleanest way via WP-CLI:

wp core download --skip-content --force

Or manually: download WordPress from wordpress.org, unzip it, and upload everything except the wp-content folder and wp-config.php.

Step 9 - Check the PHP version

Hosts occasionally upgrade PHP automatically. A jump from PHP 7.4 to PHP 8.1 can break plugins and themes that use deprecated functions. Check your PHP version:

php -v

If it recently changed, try switching back temporarily (most hosts let you select PHP version per domain in cPanel). Then update the problematic plugins one by one, or find alternatives.

Preventing WSOD in the future

Stage before updating

Never update plugins or themes directly on a live site. Use a staging environment (most managed hosts have one-click staging). Push to production only after confirming no WSOD on staging.

Use a monitoring tool

WP Umbrella and ManageWP both run a health check after every update and can automatically roll back if the site goes down.

Keep error logging enabled but hidden

A good production setup keeps WP_DEBUG_LOG permanently on but WP_DEBUG_DISPLAY off. That way you always have a log to check without exposing errors publicly:

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

Limit auto-updates to minor versions only

Core auto-updates to major versions (5.x to 6.x) occasionally cause WSODs. In wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' ); // only patch updates, not major

WSOD diagnostic checklist

Work through this in order - most issues are resolved by step 3:

  1. Can you reach /wp-admin/? If yes, the issue is theme/template specific
  2. Enable WP_DEBUG and check /wp-content/debug.log
  3. Rename plugins folder via FTP, reload, then restore and isolate
  4. Switch to a default theme
  5. Increase WP_MEMORY_LIMIT to 256M
  6. Check server PHP error logs
  7. Re-download WordPress core with wp core download --force
  8. Check PHP version compatibility

Frequently Asked Questions

How do I fix the WordPress white screen of death?
Start by enabling debug mode: open wp-config.php and set define('WP_DEBUG', true); and define('WP_DEBUG_DISPLAY', true);. Reload the page — the white screen will be replaced by an actual PHP error message pointing to the file and line causing the crash. Fix that error (usually by deactivating the named plugin or switching themes) and then disable debug mode again.
What causes the WordPress white screen of death?
The WSOD is almost always a PHP fatal error. The most common triggers are a plugin or theme update that introduced a syntax error or incompatibility, a PHP version upgrade that broke older code, or WordPress running out of memory mid-page. WordPress hides the error to protect security, which is why you see a blank page instead of an error message.
How do I fix white screen of death when I cannot access the WordPress admin?
Connect via FTP or your hosting file manager and rename the wp-content/plugins folder to plugins-disabled. This deactivates all plugins without needing admin access. If the site loads, rename the folder back to plugins and reactivate plugins one at a time to find the culprit. If renaming plugins does not help, rename the active theme folder inside wp-content/themes to force WordPress to use a default theme.
Can a WordPress update cause the white screen of death?
Yes. A WordPress core update, plugin update, or PHP version change on the server can all trigger the WSOD if the updated code contains a fatal error or conflicts with existing plugins. Always back up before updating. If the WSOD appears immediately after an update, use FTP to deactivate plugins, or use your host's one-click restore to roll back to the pre-update backup.

Was this article helpful?