WordPress White Screen of Death: How to Fix It

The WordPress White Screen of Death (WSOD) is one of the most frustrating errors for site owners. The screen is completely blank, with no error message, no indication of the cause. The site is inaccessible and the WordPress dashboard may be too.

This guide walks you through systematic diagnosis and resolution of every possible WSOD cause. From simple solutions to advanced FTP interventions, every step is detailed to help you recover your site.

Understanding the WordPress White Screen of Death

What Is the White Screen of Death?

The WSOD manifests as a completely blank white screen when you try to access your site or its WordPress dashboard. Unlike a 500 error that displays a server message, the WSOD shows absolutely nothing. It results from a fatal PHP error that WordPress cannot handle.

The WSOD can affect:

• Front-end only: the public site is blank but /wp-admin works.
• Back-end only: the dashboard is blank but the site works.
• Both: no page loads, both front-end and back-end are blank.

Common Causes of the WordPress WSoD

The WSOD is always caused by a fatal PHP error that halts script execution. In production, error display is disabled (display_errors = Off), which produces a blank white page instead of an explicit error message.

Most frequent causes:

Impact of the White Screen on Your Site

A WordPress white screen goes beyond a visual inconvenience. The consequences are significant:

• Traffic loss: every minute of downtime drives visitors away.
• SEO impact: if Googlebot encounters a WSOD, your site risks temporary deindexation and a ranking drop.
• Revenue loss: for e-commerce or lead-generation sites, the financial impact is immediate.
• Trust degradation: users who encounter a blank white page may never return.

Acting quickly is essential. Follow the steps below in order to identify and fix the cause.

Step 1: Enable WordPress Debug Mode

Debug mode is the first crucial diagnostic step. It transforms a generic symptom (the white screen) into a specific, traceable PHP error. Without this information, you are troubleshooting blind.

Via wp-config.php (FTP Access)

Connect to your server via FTP or SFTP and edit the wp-config.php file at the root of your WordPress installation.

<?php
// Replace these lines in wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

With this configuration:

• WP_DEBUG enables debug mode.
• WP_DEBUG_LOG writes errors to wp-content/debug.log. This file is the primary source of information for diagnosis and will guide your next steps.
• WP_DEBUG_DISPLAY stays false to avoid showing errors to visitors. Leaving this set to true in production exposes sensitive information (server paths, file names) and can create security vulnerabilities.

Via WP-CLI (SSH Access)

# Enable debug
wp config set WP_DEBUG true --raw --path=/var/www/html
wp config set WP_DEBUG_LOG true --raw --path=/var/www/html
wp config set WP_DEBUG_DISPLAY false --raw --path=/var/www/html
 
# View the error log
tail -50 /var/www/html/wp-content/debug.log

Reading the Error Log

After enabling debug, reload the blank white page. Then check wp-content/debug.log:

# View recent errors
tail -100 /var/www/html/wp-content/debug.log
 
# Search for fatal errors
grep -i "fatal" /var/www/html/wp-content/debug.log

Common error message examples:

PHP Fatal error: Allowed memory size of 67108864 bytes exhausted
PHP Fatal error: Uncaught Error: Call to undefined function
PHP Fatal error: Cannot redeclare function_name()
PHP Parse error: syntax error, unexpected '}' in /path/to/file.php

Each message points to a specific cause. The rest of this guide addresses each cause individually.

Step 2: Resolve PHP Memory Exhaustion

Symptoms

The error message in debug.log contains Allowed memory size of X bytes exhausted. This is one of the most common causes of the WordPress white screen of death.

Immediate Solution: Increase the PHP Memory Limit

Before making any changes, back up your site completely (files and database). Try the solutions in this order of preference:

1. Via wp-config.php (direct control, recommended method):

<?php
// In wp-config.php
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

WP_MEMORY_LIMIT controls the memory allocated to the front-end (public pages), while WP_MAX_MEMORY_LIMIT handles memory for the admin interface (/wp-admin), which typically requires more resources.

2. Via .htaccess (if wp-config.php is insufficient or ignored by the server):

# In .htaccess
php_value memory_limit 256M

3. Via php.ini (often requires server access or a request to your hosting provider):

; In php.ini or .user.ini
memory_limit = 256M

# Via WP-CLI
wp config set WP_MEMORY_LIMIT '256M' --path=/var/www/html
wp config set WP_MAX_MEMORY_LIMIT '512M' --path=/var/www/html

Long-Term Solution

Increasing memory is a stopgap. The root cause is usually:

• A poorly optimized plugin consuming too much memory. Identify it with the Query Monitor plugin, which displays memory consumption per plugin.
• Too many active plugins: each plugin loads PHP code on every request. Perform a regular audit to remove unused or redundant plugins.
• A heavy theme with excessive built-in features. Consider a lighter theme or optimize the current one using performance tools.
• Undersized hosting for your traffic. Check resource metrics in your hosting dashboard and consider an upgrade if needed.

Step 3: Diagnose a Plugin Conflict

Plugin conflicts are the number one cause of the WordPress white screen of death. A plugin can conflict with another plugin, the active theme, or the server's PHP version.

Before proceeding, check the debug.log file. Often, the log directly names the file or the plugins folder responsible, allowing you to target the deactivation without resetting everything. Also back up your site before any manipulation.

Method 1: Deactivate All Plugins via FTP

If the dashboard is inaccessible, deactivate all plugins by renaming their folder:

# Via FTP or SSH: rename the plugins folder
mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_backup

If the site comes back, it is confirmed: a plugin is the cause.

# Recreate the plugins folder
mv /var/www/html/wp-content/plugins_backup /var/www/html/wp-content/plugins

Method 2: Deactivate Plugins via WP-CLI

# Deactivate all plugins
wp plugin deactivate --all --path=/var/www/html
 
# Check if the site works, then reactivate one by one
# Replace "akismet" with the slug of each plugin to test
wp plugin activate akismet --path=/var/www/html
wp plugin activate woocommerce --path=/var/www/html
# ... continue until you identify the problematic plugin

Method 3: Deactivate via Database

If neither FTP nor WP-CLI is available, deactivate plugins via phpMyAdmin, Adminer, or any other database management tool:

-- First backup the current value
SELECT option_value FROM wp_options WHERE option_name = 'active_plugins';
 
-- Deactivate all plugins
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';

Identifying the Faulty Plugin

After deactivating all plugins, reactivate them one by one, checking the site between each activation. The plugin that brings back the white screen of death is the culprit.

Possible actions:

• Check if a plugin update is available.
• Contact the plugin developer to report the bug.
• Look for an alternative plugin offering the same functionality.
• Verify compatibility with your PHP version.

Step 4: Resolve Theme Errors

Symptoms

The WordPress white screen appears after:

• Activating a new theme.
• Updating the active theme.
• Modifying the theme's functions.php file.

Solution: Switch to a Default Theme

# Via WP-CLI
wp theme activate twentytwentyfour --path=/var/www/html
 
# Or via FTP: rename the active theme's folder
mv /var/www/html/wp-content/themes/my-theme /var/www/html/wp-content/themes/my-theme_backup

WordPress will automatically switch to a default theme if the active theme is no longer found.

Via Database

-- Change the active theme in the database
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';

Fixing a functions.php Error

If the WSOD is caused by a recent modification to functions.php:

# View recent modifications
ls -la /var/www/html/wp-content/themes/my-theme/functions.php
 
# Edit the file to remove problematic code
nano /var/www/html/wp-content/themes/my-theme/functions.php

Common functions.php causes:

• Syntax error (missing brace, forgotten semicolon).
• Function already declared in a plugin (name conflict).
• Call to a function that no longer exists after update.
• Copy-pasted code with invisible characters (typographic quotes).

Step 5: Check the .htaccess File

The .htaccess file is often overlooked when diagnosing the WordPress white screen of death, but an error in this file can cause a WSOD or a 500 error.

Diagnosis

# Temporarily rename the .htaccess file
mv /var/www/html/.htaccess /var/www/html/.htaccess_backup

If the site comes back after renaming the file, .htaccess is the cause.

Regenerate .htaccess

# Via WP-CLI: regenerate rewrite rules
wp rewrite flush --path=/var/www/html

Or manually, create a new .htaccess file with the default WordPress content:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Step 6: Repair Corrupted Core Files

Symptoms

The WSOD occurs after an interrupted update or incomplete file transfer. WordPress core files are damaged or missing. This can also be related to a 504 Gateway Timeout error if the update timed out.

Integrity Verification

# Verify core file integrity via WP-CLI
wp core verify-checksums --path=/var/www/html

This command compares each core file against the official versions from WordPress.org and flags any differences.

Core Reinstallation

# Reinstall core files without touching wp-content
wp core download --force --skip-content --path=/var/www/html
 
# Verify after reinstallation
wp core verify-checksums --path=/var/www/html

Manual Reinstallation via FTP

If WP-CLI is unavailable:

1. Download the same WordPress version from wordpress.org.
2. Extract the archive.
3. Upload all files except the wp-content folder and wp-config.php file.
4. Overwrite existing files.

Step 7: Resolve PHP Version Issues

Symptoms

The WordPress white screen appears after a PHP version change on the server. Deprecated or removed functions cause fatal errors.

Diagnosis

# Check current PHP version
php -v
 
# Check for PHP version-related errors
grep -i "deprecated\|removed\|undefined function" /var/www/html/wp-content/debug.log

Solutions

Temporarily downgrade PHP version:

Most hosting providers allow PHP version changes from the control panel (cPanel, Plesk). Revert to the previous version to restore the site.

Update plugins and themes:

# Update everything for compatibility with the new PHP version
wp plugin update --all --path=/var/www/html
wp theme update --all --path=/var/www/html
wp core update --path=/var/www/html

Recommended PHP compatibility:

Step 8: Diagnose Database Errors

Symptoms

The message "Error establishing a database connection" may appear instead of the blank screen, or the WSOD may be caused by corrupted database tables.

Connection Verification

# Test the database connection
wp db check --path=/var/www/html

Database Repair

<?php
// Temporarily add to wp-config.php
define('WP_ALLOW_REPAIR', true);

Then access your-site.com/wp-admin/maint/repair.php to launch the repair.

# Or via WP-CLI
wp db repair --path=/var/www/html
 
# Optimize the database
wp db optimize --path=/var/www/html

Remember to remove the WP_ALLOW_REPAIR constant after repair, as this page is not protected by authentication.

Verify Connection Credentials

# Check connection parameters in wp-config.php
grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST" /var/www/html/wp-config.php

Recovery via FTP When the Dashboard Is Inaccessible

When neither the site nor the WordPress dashboard is accessible, the FTP client (or SFTP) is your rescue tool.

Complete Recovery Procedure

# 1. Connect via FTP/SFTP to the server
 
# 2. Enable debug to identify the error
# Edit wp-config.php and add:
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
 
# 3. Check the error log
# Download wp-content/debug.log
 
# 4. If the error points to a plugin:
# Rename wp-content/plugins to wp-content/plugins_off
 
# 5. If the error points to the theme:
# Rename wp-content/themes/my-theme to my-theme_off
 
# 6. If core files are corrupted:
# Download WordPress from wordpress.org
# Upload all files EXCEPT wp-content and wp-config.php
 
# 7. Test the site
 
# 8. Disable debug once the problem is resolved

Emergency Access via Rescue PHP File

If all methods fail, create a diagnostic PHP file:

<?php
// emergency-check.php - place at site root
// DELETE IMMEDIATELY AFTER USE
 
echo "<h1>WordPress Diagnostic</h1>";
 
// Check PHP
echo "<h2>PHP</h2>";
echo "Version: " . phpversion() . "<br>";
echo "Memory: " . ini_get('memory_limit') . "<br>";
echo "Extensions: " . implode(', ', get_loaded_extensions()) . "<br>";
 
// Check DB connection
echo "<h2>Database</h2>";
$config = file_get_contents('wp-config.php');
preg_match("/define.*DB_HOST.*'(.+?)'/", $config, $host);
preg_match("/define.*DB_NAME.*'(.+?)'/", $config, $name);
preg_match("/define.*DB_USER.*'(.+?)'/", $config, $user);
preg_match("/define.*DB_PASSWORD.*'(.+?)'/", $config, $pass);
 
$conn = @mysqli_connect($host[1], $user[1], $pass[1], $name[1]);
if ($conn) {
    echo "Connection: OK<br>";
    echo "MySQL Version: " . mysqli_get_server_info($conn) . "<br>";
    mysqli_close($conn);
} else {
    echo "Connection: FAILED - " . mysqli_connect_error() . "<br>";
}
 
// Check critical files
echo "<h2>Files</h2>";
$files = ['wp-config.php', 'wp-load.php', 'wp-blog-header.php', 'wp-settings.php'];
foreach ($files as $f) {
    echo $f . " : " . (file_exists($f) ? "OK (" . filesize($f) . " bytes)" : "MISSING") . "<br>";
}

Delete this file immediately after use as it exposes sensitive information.

Preventing the WordPress White Screen of Death

Regular Maintenance and Backups

• Test on staging before updating production.
• Back up before every intervention (database + files). Our WordPress maintenance guide details backup best practices.
• Update regularly: minor updates are rarely problematic.

Plugin and Theme Best Practices

• Limit plugin count: each plugin adds potential attack surface and bugs.
• Choose quality plugins: check last update date, installation count, PHP version compatibility.
• Use a child theme for customizations: parent theme modifications will be overwritten at the next update.

Server and Performance Monitoring

• Check server metrics: PHP memory, CPU usage and disk space via your hosting provider's dashboard.
• Set up monitoring to be alerted immediately when a white screen occurs.

# Basic monitoring script
#!/bin/bash
SITE_URL="https://your-site.com"
ALERT_EMAIL="admin@your-site.com"
 
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" $SITE_URL)
 
if [ "$HTTP_CODE" != "200" ]; then
    echo "ALERT: $SITE_URL returns HTTP $HTTP_CODE" | mail -s "Site down" $ALERT_EMAIL
fi

Schedule this script as a cron job every 5 minutes for rapid WSOD alerts.

Managing Updates Safely

• Never interrupt a WordPress update in progress.
• Disable automatic updates for critical plugins and update them manually after staging verification.
• Check compatibility before changing your hosting's PHP version.

FAQ

How do I find which plugin is causing the white screen?

Check the wp-content/debug.log file first: it usually contains the exact path of the faulty file. If the log is not precise enough, deactivate all plugins (via FTP or WP-CLI), then reactivate them one by one, reloading the site after each activation. The plugin that brings back the white screen is the culprit.

Can the WordPress white screen of death impact my SEO?

Yes. If Googlebot encounters a WSOD during crawling, your page is interpreted as a server error. If the issue persists, Google may deindex the affected pages and your rankings will drop. Additionally, an inaccessible site degrades user experience, a negative signal for SEO. Fix the white screen as quickly as possible.

What should I do if I do not have a recent backup of my WordPress site?

Without a backup, you can still use the methods in this guide (debug, plugin deactivation, theme switching). If core files are corrupted, reinstalling via wp core download --force --skip-content replaces the core without touching your content (wp-content folder). For the database, contact your hosting provider: many keep automatic backups for 7 to 30 days.

Is it dangerous to enable debug mode on a production site?

Debug mode itself is not dangerous if you set WP_DEBUG_DISPLAY to false. With this value, errors are written to the debug.log file but never displayed to visitors. The risk only arises if you leave WP_DEBUG_DISPLAY set to true, which exposes file paths and technical information. Always disable debug after diagnosis.

What is the difference between the WSOD and a 500 error?

A 500 error displays a server message ("Internal Server Error"), while the WSOD shows a completely blank screen. The causes are often similar (PHP errors), but a 500 error appears when the server intercepts the error, while the WSOD occurs when PHP fails silently with error display disabled. For 500 error solutions, see our dedicated guide.

Get Your Site Back Online

The WordPress White Screen of Death is intimidating but rarely irreversible. By following the diagnostic methodology presented in this guide, from enabling debug to systematically checking plugins, theme, PHP memory, and core files, you will identify and resolve the cause in the vast majority of cases.

For professional diagnosis and rapid resolution, our team handles the most complex cases. Also check our guide on common WordPress bugs and our 500 error solutions for additional troubleshooting scenarios.