How to Fix the White Screen of Death in WordPress

The White Screen of Death (WSOD) is when your WordPress site (front end, admin, or both) shows a blank white page with no error message. It’s usually caused by a fatal PHP error, exhausted memory, or a misbehaving plugin/theme. This guide walks you through a clean, reliable recovery flow.

At a Glance (Fast Triage)

1. Open a new tab and test /wp-admin/. If admin loads, the issue is theme/plugin code on the front end.
2. Temporarily disable all plugins (via WP-CLI or by renaming the plugins folder). If site returns, reactivate one by one.
3. Switch to a default theme (e.g., Twenty Twenty-Five). If site returns, audit your theme.
4. Enable debugging to view the fatal error source, then fix or roll back the offending code.
5. Increase PHP memory limit and reset .htaccess if needed.

1) Enable WordPress Debugging (See the Real Error)

Edit wp-config.php (just above the line /* That's all, stop editing! */):

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false); // keep white screen clean; check the log instead
@ini_set('display_errors', 0);

Reload the white screen page, then open wp-content/debug.log. The last entries usually show the exact file, line, and plugin/theme responsible.

2) Disable All Plugins (Quickest Isolation)

WP-CLI (recommended)

wp plugin deactivate --all
# Test the site, then reactivate one by one:
wp plugin activate plugin-slug

No CLI Access

1. Connect via FTP or File Manager.
2. Rename wp-content/plugins to plugins.off. This deactivates all plugins.
3. If the site loads, restore the folder name to plugins, then rename individual plugin folders one by one to find the culprit.

3) Switch to a Default Theme

WP-CLI

wp theme activate twentytwentyfive

No CLI Access

1. Go to wp-content/themes.
2. Rename your active theme’s folder to force WordPress to fall back to a default theme (ensure one is installed).

If the site comes back, the issue is in your theme (often in functions.php, custom templates, or a recent update).

4) Increase PHP Memory Limit

Exhausted memory often yields WSOD. Raise it in wp-config.php:

define('WP_MEMORY_LIMIT', '256M');      // front end
define('WP_MAX_MEMORY_LIMIT', '512M');  // admin

If your host restricts this, set the limit in your hosting control panel or php.ini/.user.ini:

memory_limit = 512M

5) Clear Caches (All Layers)

• WordPress caching plugins (purge/disable temporarily).
• Server/Varnish/CDN (e.g., Cloudflare) — purge everything.
• PHP opcache — some hosts provide a reset; otherwise restart PHP-FPM if you can.
• Persistent object cache (Redis/Memcached) — flush once.

6) Restore a Clean .htaccess (Apache)

If permalinks or custom rules broke PHP routing, reset .htaccess to the WordPress default:

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

After recovery, visit Settings → Permalinks and click Save to regenerate rules.

7) Undo Recent Changes

• Rollback the last-updated plugin or theme to a known-good version.
• Revert custom code edits (child theme, functions.php, mu-plugins).
• If using a site management tool or Git, deploy a prior stable snapshot.

8) Check File Permissions

Incorrect permissions can block PHP includes and cause fatal errors or WSOD:

• Folders: 755
• Files: 644
• Never set 777. Ensure the correct owner/group per host requirements.

9) Look for Fatal Syntax/Runtime Errors

Common culprits:

• Missing semicolons, mismatched braces, or require/include paths failing after a move.
• Calling functions/classes that don’t exist (load-order issues).
• PHP version incompatibility (new plugin needs a newer PHP).

Use the error in debug.log to jump straight to the file/line and fix it.

10) Multisite & Admin-Only WSOD Notes

• Multisite: Network-activated plugins affect all sites. Use WP-CLI to deactivate network-wide if needed.
• Admin-only WSOD: Often due to admin-only hooks, screen options, or dashboard widgets from plugins. Deactivate plugins first.

11) When You Can’t Access Anything

1. Rename plugins and your active theme folder to force a minimal load.
2. Ensure WP_DEBUG_LOG is enabled and check wp-content/debug.log.
3. Temporarily move custom mu-plugins from wp-content/mu-plugins out of the way.

12) Hardening to Prevent Future WSOD

• Use a staging site for updates and custom code tests.
• Keep reliable backups (files + database) with quick restore.
• Pin critical plugin/theme versions, and read changelogs before updating.
• Match PHP version to your stack’s requirements and test upgrades first.
• Limit custom code to a child theme or small, reviewable must-use plugins.
• Monitor error logs; don’t leave WP_DEBUG_DISPLAY on in production.

Recovery Checklist

1. Turn on debugging, read debug.log.
2. Disable plugins; switch to a default theme.
3. Increase memory; clear all caches.
4. Reset .htaccess (Apache) and resave permalinks.
5. Fix the exact file/line reported; roll back recent changes.
6. Verify permissions and PHP version compatibility.

WP-CLI Cheat Sheet

# Debug (verify constants via eval)
wp eval 'echo WP_DEBUG ? "on\n" : "off\n";'

# Plugins
wp plugin list
wp plugin deactivate --all
wp plugin activate plugin-slug

# Themes
wp theme list
wp theme activate twentytwentyfive

# Cache (if available)
wp cache flush

Follow the steps in order and you’ll almost always locate the exact cause of the WSOD quickly, recover the site, and harden your workflow to avoid repeat incidents.

👉 Need more help? Explore our WordPress Troubleshooting Guide for step-by-step solutions to the most common errors.