---
title: "WordPress White Screen of Death: How to Fix It"
description: "Fix the WordPress White Screen of Death (WSOD). Step-by-step diagnosis, common causes and solutions via FTP, WP-CLI and database."
date: "2026-03-11"
author: "Bastien Allain"
category: "WordPress"
tags: ["wordpress", "white-screen", "wsod", "troubleshooting", "debug"]
keywords: ["wordpress", "white-screen", "wsod", "troubleshooting", "debug"]
image: "/blog/category-wordpress.webp"
published: true
locale: "en"
translationKey: "wordpress-white-screen"
imageAlt: "WordPress White Screen of Death: How to Fix It"
lastmod: "2026-03-11"
authorImage: "/authors/bastien-allain.webp"
authorTwitter: ""
isFamilyFriendly: true
---

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](/blog/wordpress/500-error-fix) 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`](https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors)), which produces a blank white page instead of an explicit error message.

**Most frequent causes:**

| Cause | Frequency | Diagnosis |
|-------|-----------|-----------|
| **Plugin conflict** | 40% | Occurs after plugin activation/update |
| **Theme error** | 25% | Occurs after theme change/update |
| **PHP memory exhaustion** | 20% | Site gradually slows before WSOD |
| **Corrupted core files** | 8% | Occurs after interrupted update |
| **PHP version incompatibility** | 5% | Occurs after PHP version change |
| **Database error** | 2% | "Error establishing database connection" sometimes visible |

### 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
<?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)

```bash
# 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`:

```bash
# 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
<?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):

```apache
# In .htaccess
php_value memory_limit 256M
```

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

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

```bash
# 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](https://wordpress.org/plugins/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:

```bash
# 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.

```bash
# 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

```bash
# 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**:

```sql
-- 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

```bash
# 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

```sql
-- 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`:

```bash
# 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](/blog/wordpress/500-error-fix).

### Diagnosis

```bash
# 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

```bash
# 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:

```apache
# 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](/blog/wordpress/504-bad-gateway-fix) if the update timed out.

### Integrity Verification

```bash
# 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](https://developer.wordpress.org/cli/commands/core/verify-checksums/) and flags any differences.

### Core Reinstallation

```bash
# 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](https://wordpress.org/download/).
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

```bash
# 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:**

```bash
# 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:**

| WordPress Version | Minimum PHP | Recommended PHP |
|-------------------|-------------|-----------------|
| WordPress 6.5+ | PHP 7.4 | PHP 8.2 - 8.3 |
| WordPress 6.3-6.4 | PHP 7.4 | PHP 8.1 - 8.2 |
| WordPress 6.0-6.2 | PHP 7.4 | PHP 8.0 - 8.1 |

## 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

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

### Database Repair

```php
<?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.

```bash
# 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

```bash
# 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

```bash
# 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
<?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](/blog/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](/blog/wordpress/common-bugs-fix).
- **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.

```bash
# 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](/blog/wordpress/500-error-fix).

## 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](/services/wordpress/maintenance), our team handles the most complex cases. Also check our guide on [common WordPress bugs](/blog/wordpress/common-bugs-fix) and our [500 error solutions](/blog/wordpress/500-error-fix) for additional troubleshooting scenarios.