WordPress White Screen of Death: Every Cause, Fixed

The WordPress white screen of death (WSOD) is a completely blank page — no error, no text, just white — that can hit your front end, your admin panel, or both at the same time. It almost always means PHP has crashed hard enough that WordPress cannot output anything, and the fix depends entirely on which crash triggered it. Work through the causes below in order and you will find it.

What You Are Actually Seeing

A true WSOD returns an HTTP 200 status (the server thinks everything is fine) but sends an empty body. Occasionally it returns a 500, which points more directly at a server-level problem. Either way, the browser has nothing to render, so you see white. A few variations worth distinguishing:

• White screen on the front end only — the admin dashboard still loads. This usually means a theme or a front-end plugin has a fatal error.
• White screen on the admin only — the public site still works. This points to an admin-specific plugin, a corrupt option in the database, or an incompatible screen option.
• White screen everywhere — front end and admin both blank. This is the most serious variant and typically means a core file problem, a memory exhaustion, or a site-wide PHP conflict.
• White screen after an update — the timing narrows it down immediately. See the fix guide for WordPress sites that broke after an update for extra context.

Before You Touch Anything: Back Up First

If your admin panel is still accessible, run a full backup right now before you start changing things. If it is not, check whether your host offers server-side snapshots — most managed WordPress hosts do. A backup gives you a safe rollback point if a fix attempt makes things worse.

Step 1: Turn On WordPress Debug Mode

WordPress suppresses PHP errors by default, which is why you see white instead of a message. Enabling debug mode turns that off and reveals the real problem. Open your wp-config.php file (in the root of your WordPress installation) and find these two lines:

define( 'WP_DEBUG', false );

Replace them with:

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

Setting WP_DEBUG_DISPLAY to false writes errors to wp-content/debug.log instead of printing them to the screen — safer on a live site. Reload the broken page, then open wp-content/debug.log and read the first error. That error is your diagnosis. The sections below map to the most common ones you will see.

Cause 1: PHP Memory Limit Exhausted

The most frequent cause of a site-wide WSOD is WordPress running out of PHP memory. The debug log will say something like Fatal error: Allowed memory size of X bytes exhausted.

Fix: Open wp-config.php and add this line before the /* That's all, stop editing! */ comment:

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

If the site comes back, the memory limit was the culprit. A persistent fix means finding out what is consuming that memory — usually a plugin with a memory leak or a theme loading large libraries. Your host may also need to raise the server-side PHP memory limit in php.ini or .htaccess; the WordPress constant cannot exceed the server cap.

Cause 2: A Plugin Fatal Error

A bad plugin update, an incompatible plugin, or a plugin that conflicts with another is the second most common trigger. The debug log will typically name a file inside wp-content/plugins/plugin-name/.

Fix — if admin is accessible: Go to Plugins → Installed Plugins and deactivate every plugin. If the white screen clears, reactivate plugins one at a time, reloading after each, until the screen goes white again. The last plugin you activated is the culprit. For a structured approach to this process, see How to Isolate a Plugin Conflict Without Killing Your Site.

Fix — if admin is not accessible: Connect to your site via FTP or your host's file manager. Navigate to wp-content/plugins/ and rename the entire folder to something like plugins_disabled. WordPress will deactivate all plugins automatically. Once the site loads, rename the folder back to plugins, then reactivate plugins one at a time through the admin.

Cause 3: A Theme Fatal Error

If disabling all plugins does not fix the white screen, the active theme is the next suspect. A syntax error in a theme file, a theme that requires a newer PHP version, or a corrupted theme update will all produce a WSOD.

Fix — if admin is accessible: Go to Appearance → Themes and switch to a default WordPress theme (Twenty Twenty-Four, for example).

Fix — if admin is not accessible: Via FTP or file manager, go to wp-content/themes/ and rename your active theme's folder. WordPress will fall back to the next available theme. If no other theme exists, add a default theme folder via FTP. Once the site loads, inspect the broken theme or reinstall it from a clean copy.

Cause 4: A Corrupt Core File

A failed WordPress core update, a botched migration, or malware tampering can corrupt core PHP files. The debug log may reference a file in wp-includes/ or wp-admin/.

Fix: Download a fresh copy of WordPress from wordpress.org that matches your current version number. Unzip it, then upload the wp-includes/ and wp-admin/ folders to your server, overwriting the existing ones. Do not delete or overwrite wp-content/ or wp-config.php. This replaces every core file without touching your content or settings. If malware is suspected, the fix guide for a hacked WordPress site covers a full clean-up process.

Cause 5: PHP Version Incompatibility

If your host recently upgraded the server PHP version — or you changed it yourself — code in a theme or plugin that relied on an older PHP syntax can produce a fatal parse error and a white screen. The debug log will say Parse error: syntax error and point to a file.

Fix (short-term): Roll the PHP version back to the previous one in your host's control panel. Most cPanel, Plesk, and managed WordPress hosts expose this under PHP Configuration or PHP Manager. This buys you time to update the offending theme or plugin, or find a replacement that supports the current PHP version.

Fix (permanent): Update or replace the incompatible code, then upgrade PHP again. Running an outdated PHP version leaves your site exposed to security vulnerabilities, so staying on an old version is not a long-term solution.

Cause 6: A Syntax Error in wp-config.php or functions.php

If you or a plugin recently edited wp-config.php, a theme's functions.php, or any other PHP file directly, a single misplaced character — a missing semicolon, an unclosed quote, a stray character before <?php — will crash the entire site.

Fix: Open the file via FTP or file manager and look at the lines you (or the plugin) most recently changed. The debug log will name the file and the line number. Correct the syntax, save, and reload. If you are unsure what changed, replace the file with a backup copy. This is exactly why editing theme files directly is risky — see Why Direct Theme Edits Break Sites for safer alternatives.

Cause 7: The .maintenance File Left Behind

This one produces a slightly different result — a "briefly unavailable" message, not a true white screen — but it is worth checking because it is easy to rule out. If a WordPress update was interrupted, a hidden file called .maintenance may have been left in your root directory. Delete it via FTP and the site will return. This is not a white screen but is frequently confused for one.

Cause 8: Exhausted Disk Space or Inodes

When a server's disk is completely full, PHP cannot write temporary files, sessions, or logs, and the result is often a blank output. Log in to your host's control panel and check disk usage. If you are at or near 100%, delete log files, old backups stored on the server, or spam uploads. Then contact your host if you need more space.

After You Find the Fix: Harden Against Recurrence

• Keep debug mode enabled in a staging environment but disable it on production once you are done troubleshooting (WP_DEBUG false).
• Keep plugins, themes, and WordPress core updated on a regular schedule to reduce the chance of a compatibility-triggered WSOD.
• Keep at least one default WordPress theme installed so WordPress has a fallback if your active theme breaks.
• Set up automatic daily backups stored off-server — your host's built-in backup often only keeps a short history.
• Set a PHP memory limit high enough for your site's real usage, but investigate any plugin that consistently consumes hundreds of megabytes.

When to Call a Professional

Most white screen causes respond to the steps above within 20–30 minutes. Call in a professional when:

• The debug log points to multiple interacting errors and you cannot isolate the root cause.
• The white screen appeared after a hack and you are not certain the site is clean.
• You are not comfortable accessing files via FTP or editing wp-config.php.
• The site is a live business and every minute of downtime has real cost.

Mend's senior engineers fix WordPress white screens fast — most same day — on a backup-first workflow, and every fix comes with a plain-English explanation of exactly what caused it and what changed. If you need it resolved now, Emergency Rescue is a flat $499 and is backed by a "fixed, or your money back" guarantee. Not sure what you are dealing with? A free Diagnosis triages the problem and gives you a flat quote before any work starts — no card required.

A white screen is alarming but it is almost always fixable, and the debug log almost always tells you exactly where to look. Work through the causes in the order above, start with memory and plugins before assuming the worst, and you will have your site back.