How to Fix the WordPress White Screen of Death (2026)

You open your WordPress site one morning and instead of your homepage, there is nothing. A completely blank, white page. No error message, no admin bar, no clues at all. That is the WordPress white screen of death (WSOD), and while it looks terrifying, it is one of the most fixable problems in WordPress — because the white screen almost never means your content is gone. It means PHP crashed before WordPress could render anything, and WordPress is hiding the real error from you.

This guide walks you through the exact diagnostic order a professional uses: check recovery mode first, then read the actual error from the debug log, then eliminate suspects one at a time. Follow it in order and most white screens are fixed in 15–30 minutes.

Table of Contents

What Causes the WordPress White Screen of Death?

Every WordPress white screen traces back to a PHP fatal error or a resource limit that WordPress refuses to print on a live site (printing it would leak file paths and internals to visitors). The usual suspects are:

A broken or conflicting plugin — the most common cause, usually right after an update.
A theme error — most often a syntax mistake in functions.php or a child theme override that calls a function that no longer exists.
Exhausted PHP memory — common on WooCommerce sites and long pages with many plugins.
An incompatible PHP version — functions removed in PHP 8.0 (like create_function()) still crash old plugins and themes.
Corrupted WordPress core files — a failed or interrupted core update.

Your job is to find which one it is. Start with the fix that requires the least effort.

Before You Touch Anything

Grab two things: access to your hosting file manager (cPanel, Plesk, or whatever your host gives you) or an FTP/SFTP client like FileZilla, and the login to the email address registered as your WordPress admin email. A recent backup helps, but do not wait for one — none of the steps below delete anything.

Step 1: Check Your Inbox for WordPress Recovery Mode

Since WordPress 5.2, a fatal error automatically triggers an email to your site admin address with the subject line “Your Site is Experiencing a Technical Issue”. If WordPress could identify the failing plugin or theme, the email names it and includes a special recovery link. Clicking it logs you into wp-admin in Recovery Mode, where the broken component is paused just for your session, so you can deactivate it normally and exit recovery mode.

Check spam too — these emails get eaten by filters regularly. If the email arrived, congratulations: the diagnosis is already done for you. Deactivate the named plugin or theme, exit Recovery Mode from the admin bar, and reload your site in a normal browser window to confirm.

If no email arrived, do not waste time waiting. Recovery Mode only fires on protected endpoints like wp-admin and wp-login.php — errors on front-end pages or during cron jobs do not trigger it. Move on to Step 2.

Step 2: Enable Debug Logging to See the Real Error

Guessing is what makes the WordPress white screen of death take hours instead of minutes. The debug log turns the blank page into a precise file name and line number.

Open wp-config.php in your site root over SFTP or your host’s file manager and add these lines above the /* That's all, stop editing! Happy blogging. */ comment:

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

This is the exact configuration the official WordPress debugging handbook documents. WP_DEBUG is the master switch; WP_DEBUG_LOG writes errors to wp-content/debug.log; and WP_DEBUG_DISPLAY set to false keeps errors off the page. That last part is non-negotiable: on a live site, printing errors leaks server paths and plugin names to every visitor.

Now reload the broken page once, then open wp-content/debug.log. Scroll to the bottom and look for the most recent PHP Fatal error line. It names the file, the line number, and often the plugin or theme folder the file lives in. A path like /wp-content/plugins/some-plugin/inc/loader.php means that plugin crashed; a path in wp-includes or wp-admin points at core files instead.

Once the site is fixed, delete those four lines again. debug.log is publicly readable on many hosts, so leaving it behind is a security problem.

Step 3: Deactivate All Plugins From the File System

If you cannot reach wp-admin, this is the blunt instrument that almost always works — and it deletes nothing.

Connect via SFTP or your host’s file manager and go to wp-content/.
Rename the plugins folder to plugins-hold (any name works).
Reload your site.

WordPress cannot find the folder, so it deactivates every plugin at once. If the white screen clears, a plugin was the culprit. Now rename the folder back to plugins and visit Plugins > Installed Plugins in wp-admin. WordPress will show all plugins as inactive. Reactivate them one at a time, reloading the site after each one, until the white screen returns — the last plugin you switched on is your culprit.

Shortcut: if Step 2’s log already named the plugin, skip the mass deactivation and rename just that plugin’s folder instead.

Step 4: Rule Out Your Theme

If the site is still white with all plugins off, your theme is next. If you can reach wp-admin, go to Appearance > Themes and activate a default WordPress theme (Twenty Twenty-Five or whichever default is bundled with your install). If you are locked out, rename your active theme’s folder inside wp-content/themes/ — WordPress automatically falls back to a bundled default theme, installing one first via the file manager if none exists.

Reload the site. If it loads, the theme is the problem. Nine times out of ten the offender is a recent edit to functions.php — check the debug log for the exact line, fix the syntax (a missing semicolon or bracket is the classic), and restore the folder name. If the theme broke after an update, download a fresh copy from its source and reinstall it; if you use a child theme, check the child theme’s overrides against the parent’s latest version.

Step 5: Increase the PHP Memory Limit

A WordPress white screen of death that appears only on specific pages — long posts, the WooCommerce checkout, or the wp-admin dashboard — is the signature of exhausted PHP memory. WordPress’s default limit is small, and big sites with many plugins blow past it.

Add this to wp-config.php, again above the “That’s all, stop editing” line:

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

If the admin area specifically needs more headroom, you can also add:

define( 'WP_MAX_MEMORY_LIMIT', '512M' );

One caveat: this constant can only raise the limit up to the ceiling your host enforces at the server level. If 256M changes nothing, the cap is the hosting plan, not the setting — ask your host to raise it or move to a plan with more memory.

Step 6: Replace Corrupted WordPress Core Files

If the debug log points at files inside wp-includes or wp-admin, core files are corrupted — typically from a failed auto-update. Fix it without touching your content:

Download a fresh copy of WordPress from wordpress.org (match your installed version if you know it).
Unzip it and upload everything except the wp-content folder and wp-config.php, overwriting the old files.
Reload the site.

Your themes, plugins, uploads, and settings live in wp-content and wp-config.php, so this refresh leaves them untouched.

Step 7: Clear Every Cache

Sometimes the white screen is already fixed and you are staring at a stale copy. Clear your browser cache, purge your caching plugin’s cache, and flush any server-side or CDN cache (Cloudflare, your host’s page cache) before concluding that a step did not work. Test in an incognito window to be sure.

How to Prevent the White Screen of Death Next Time

Fixing is reactive; the workflow below is what stops the 3 AM emergencies:

Never edit live PHP through Appearance > Theme File Editor. One syntax error and you are locked out. Use SFTP and a code editor instead.
Update one thing at a time — one plugin, then check the site; then the theme; then core. If something breaks, you already know which update did it.
Use a staging site for plugin updates, theme changes, and custom block development. Most managed hosts offer one-click staging.
Keep daily backups that include both files and the database, and test that restoring actually works before you need it.
Keep PHP and plugins current — PHP 8.x deprecations crash plugins that were never updated for it.

How to Fix the WordPress White Screen of Death: Step-by-Step Guide (2026)