WordPress White Screen of Death: Every Cause, Fixed

The WordPress white screen of death (WSOD) is a completely blank page — no error message, no admin bar, just nothing — and it can hit your front end, your dashboard, or both at once. The good news: every cause has a fix, and most are reversible in under ten minutes without touching a line of code. This guide walks through all of them, easiest first.

What You're Seeing (and What You're Not)

A true WSOD returns an empty white page with no visible text. Depending on the cause, your browser's status bar may show the page as fully loaded (HTTP 200), or you might catch a brief flash of a 500-level error before the blank page settles. If your screen says "There has been a critical error on this website", that's a slightly different beast — read the dedicated guide at fixing the WordPress critical error. If you're seeing a 500 status specifically, check fixing the WordPress 500 internal server error.

The WSOD most commonly surfaces in one of three patterns:

• Front end only — visitors see blank pages; you can still log in to wp-admin.
• Admin only — the site renders fine publicly but /wp-admin is blank.
• Both — the most severe form, usually a PHP fatal error or exhausted memory.

Turn on WP_DEBUG Before Anything Else

WordPress suppresses errors by default, which is why you see white instead of a useful message. Switching on debug mode often reveals the exact file and line number causing the problem.

Before you edit any file, take a full backup. If your host provides a one-click snapshot (most do), trigger it now.

Open wp-config.php in your file manager or FTP client and find this line:

define( 'WP_DEBUG', false );

Replace it with:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );

Reload the blank page. If PHP can generate any output at all, you'll now see the error message instead of white. Read what it says — the filename and function it mentions will tell you exactly which fix below to apply. When you're done, set WP_DEBUG back to false.

Cause 1: A Broken Plugin

This is the most common cause of the WSOD by a wide margin, and it's almost always triggered right after installing or updating a plugin. A single bad plugin can kill PHP execution before WordPress finishes loading the page.

Fix: Deactivate all plugins via FTP or File Manager

1. Connect to your site via FTP or your host's file manager.
2. Navigate to wp-content/plugins/.
3. Rename the entire plugins folder to plugins_disabled. WordPress will silently deactivate every plugin when it can't find the folder.
4. Reload your site. If it comes back, plugins were the culprit.
5. Rename the folder back to plugins, then re-enter wp-admin. WordPress will show all plugins as deactivated.
6. Reactivate them one by one, reloading after each. The one that triggers the blank screen again is your offender.
7. Delete or replace that plugin. Check its support forum for known bugs with your version of WordPress.

Cause 2: A Broken Theme

A theme with a PHP syntax error — a missing semicolon, an unclosed bracket, a function that calls itself infinitely — produces a WSOD just as reliably as a bad plugin.

Fix: Switch to a default theme via the database or FTP

If you can reach wp-admin, go to Appearance → Themes and activate Twenty Twenty-Four (or any bundled default theme). If admin is also blank, do it via FTP:

1. In wp-content/themes/, rename your active theme's folder (e.g., my-theme → my-theme_broken).
2. WordPress will fall back to the next available theme automatically.
3. If no default theme is installed, download Twenty Twenty-Four from WordPress.org and upload it to wp-content/themes/.

If the site returns, the theme was at fault. Contact the theme developer with the debug error message, or hire a developer to patch the file.

Cause 3: PHP Memory Limit Exhausted

WordPress has a default memory limit. Heavy themes, page builders, and WooCommerce stores regularly exceed it. When PHP runs out of memory mid-execution, output stops — producing a blank white page with no error, even with debug on.

Fix: Increase the PHP memory limit

Add this line to wp-config.php, just above the line that says "That's all, stop editing!":

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

If that doesn't help, you can also try adding the following to your .htaccess file (Apache servers only — check with your host first):

php_value memory_limit 256M

Some managed hosts cap memory at the server level, in which case you'll need to raise the limit inside your hosting control panel or ask support. 256 MB is a reasonable target for most sites; large WooCommerce stores sometimes need 512 MB.

Cause 4: PHP Syntax Error in a Custom Snippet or functions.php Edit

Pasting code into Appearance → Theme File Editor or a code-snippet plugin is one of the most common ways to produce an instant WSOD. A single misplaced character breaks PHP parsing for the entire file.

Fix: Restore the file via FTP

1. Connect via FTP and navigate to your active theme folder.
2. Open functions.php in a plain-text editor (not Word).
3. Scroll to the bottom where you added the snippet and remove it.
4. Save and upload the file, overwriting the broken version.

If you used a code-snippets plugin, rename or delete the plugin folder in wp-content/plugins/ as described in Cause 1 above. This will deactivate all snippets stored in the plugin's database table.

Cause 5: A Failed WordPress Core Update

If your site went white mid-update — or right after one completed — the core files may be partially written. This is uncommon but happens on slow or interrupted connections.

Fix: Re-upload WordPress core files

1. Download a fresh copy of WordPress from wordpress.org/download.
2. Extract the zip. Do not upload the wp-content folder — that would overwrite your themes and plugins.
3. Upload everything else (wp-admin, wp-includes, and the root PHP files) via FTP, overwriting existing files.
4. Reload your site.

For more detail on update-related failures, see WordPress site broke after an update.

Cause 6: File or Folder Permission Errors

WordPress needs specific filesystem permissions to execute PHP. If a migration, server move, or runaway security script sets permissions incorrectly, PHP can fail silently.

Fix: Reset permissions to safe values

The correct permissions for most setups are:

• Folders: 755
• Files: 644
• wp-config.php: 600

You can set these recursively via SSH:

find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;

Replace /path/to/wordpress with your actual site root. If you're on a managed host without SSH, the file manager usually has a "Change Permissions" option you can apply recursively.

Cause 7: PHP Version Mismatch

Running an old plugin or theme against a newer PHP version (or vice versa) can cause hard fatal errors on every page load. This typically surfaces when a host upgrades its PHP version overnight.

Fix: Check and change your PHP version

Most cPanel and Plesk hosts let you choose your PHP version under PHP Configuration or MultiPHP Manager. Try rolling back one minor version (e.g., from 8.3 to 8.2). If that resolves it, the problematic plugin or theme doesn't yet support the newer version — update it or replace it, then move PHP forward again.

Cause 8: Object Cache or Opcode Cache Stale Data

After a major update, a stale opcode cache can serve compiled PHP bytecode that no longer matches the new files on disk. The result: inexplicable blank pages that clear up on their own — or don't.

Fix: Flush all caches

1. If you have a caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, etc.) and can reach wp-admin, clear all caches from the plugin's dashboard.
2. If you can't reach admin, delete the contents of wp-content/cache/ via FTP.
3. Ask your host to flush the server-side opcode cache (OPcache). Most do this through their support dashboard or a quick ticket.

How to Prevent the WSOD

The patterns above repeat constantly. Three habits eliminate most of them:

• Stage before you update. Test plugin and theme updates on a staging copy before pushing to production. Most quality hosts include one-click staging.
• Keep automatic backups running. A daily off-site backup means any WSOD is a ten-minute restore, not a crisis.
• Update PHP proactively. Check plugin and theme compatibility before your host bumps the PHP version for you. WordPress.org's plugin pages list tested PHP versions.

If you want someone else handling updates, backups, and monitoring so a WSOD never catches you off guard, the Mend Care Plan covers all of that for $99/month.

When to Call a Professional

Work through the steps above and you'll resolve the WSOD 90% of the time. The remaining 10% typically involves corrupted database tables, a hacked site injecting malformed output before PHP can render anything, a complex hosting environment with unusual PHP configurations, or a custom-built theme with deeply nested errors that debug mode only partially exposes.

If you've been through every fix above, debug mode produces no useful output, and the site is still white — that's the right moment to hand it off. Submit a free Mend Diagnosis and a senior engineer will triage the site, identify the root cause, and give you a flat quote before any work begins. Most fixes ship the same day, backed by a fixed-or-your-money-back guarantee.

For a concise reference on diagnosing this error type, bookmark the Mend WSOD fix guide.