WordPress White Screen of Death: Read It by Where the Screen Is Blank

The white screen of death isn’t a WordPress feature, a virus, or a mystery. It’s PHP hitting a fatal error partway through building your page and stopping. WordPress, by default, swallows the error text and hands the browser nothing, so you get a clean white nothing instead of a red error message. We’ve walked into this on client sites enough times to know the blank page is the least useful part. The useful part is figuring out what crashed, and the fastest way to do that is to notice where the screen is white before you touch a single file.

Most guides hand you the same nine steps in the same order: disable plugins, switch the theme, raise the memory limit, turn on debugging. That list works eventually. It’s just slow, because it asks you to try everything instead of reading the one clue you already have. So we’ll start with the clue.

Look at where the page is blank first

A WordPress install loads different code depending on what you’re viewing. The front end runs your theme plus the plugins that hook into public pages. The dashboard runs admin-only code. A single post runs whatever that post’s content calls, like a page builder or a shortcode. Match the symptom to the layer and you’ve already cut the suspect list down.

Where it’s white	What that points at
Front end blank, wp-admin still works	Your active theme, or a plugin that only runs on public pages
wp-admin blank too, you’re locked out	A plugin that loads everywhere, a memory limit, or a core file problem
One post or page blank, the rest fine	Something inside that page: a builder, a shortcode, a broken embed
Everything went blank right after an update	The exact plugin, theme, or core version you just updated

That last row is the most common one we get called about, and it’s also the easiest. If the site was fine ten minutes ago and you updated one plugin, you don’t need a debugging session. You need to switch that plugin off. We’ll get to how.

Make WordPress tell you what actually died

The blank page is hiding a real error message, and you can unhide it. Open wp-config.php in the site root over SFTP or your host’s file manager, and find the line that says define( 'WP_DEBUG', false );. Replace it with these two lines:

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

Reload the broken page once, then open wp-content/debug.log. The last few lines are what you want. WP_DEBUG_LOG writes the error to that file instead of printing it to the screen, which keeps visitors from seeing it while you read it. When you’re done, set both back to false so the log stops growing and nothing leaks publicly.

Three error lines cover most of what you’ll see, and each one tells you exactly where to go next:

• “Allowed memory size of 134217728 bytes exhausted” means the page ran out of RAM. That’s the memory limit, covered below.
• “Uncaught Error: Call to undefined function” or “syntax error, unexpected” with a file path inside /wp-content/plugins/some-plugin/ names the plugin that crashed. Go disable that one.
• “PHP Fatal error” pointing at your theme folder, or a message about an undefined function after you changed PHP versions, means a version mismatch. The plugin or theme hasn’t caught up to PHP 8.

Check your inbox before you open FTP

Since version 5.2, WordPress catches fatal errors and emails the admin address a message titled something like “Your site is experiencing a technical issue.” That email contains a recovery link. Click it and WordPress logs you into a stripped-down dashboard where the offending plugin or theme is already paused. You deactivate it from the screen, like any normal day, and the site comes back.

This is the fix half the internet forgets to mention. It only works if WordPress can send mail and the admin email still reaches you, which is exactly why we set up real transactional email on sites we maintain instead of leaving delivery to the default PHP mailer. When the recovery email lands, the white screen stops being an emergency and becomes a two-click dashboard task.

Disable plugins without losing your settings

If you can’t get into the dashboard at all, do it from the files. Connect over SFTP, open wp-content, and rename the folder plugins to plugins-off. WordPress can’t find any plugins, so it deactivates all of them, and the site usually loads. Renaming the folder doesn’t delete anything or wipe settings; it just hides the plugins from WordPress for a minute.

Now rename it back to plugins and go to the Plugins screen. Reactivate them one at a time, reloading the site after each. The plugin that brings the white screen back is your culprit. Leave it off, and check whether it has an update, a known conflict, or a support thread. If you already read the debug log, skip the one-by-one dance and go straight to the plugin the log named.

If the front end is white but admin works, it’s the theme

When the dashboard loads fine and only the public site is blank, your theme is the first suspect. From Appearance, switch to a default theme like Twenty Twenty-Five. If the front end comes back, the problem lives in your theme, usually in functions.php after an edit or an update. Can’t reach the dashboard? Rename your theme’s folder in wp-content/themes over SFTP and WordPress falls back to a default theme on its own.

The trap here is editing a live theme directly. One missing semicolon in functions.php takes down the whole site, and there’s no undo button. We do theme edits through a child theme on staging for exactly this reason, then push the change once it’s proven. If you’re hand-editing production, keep a copy of the file before you save.

“Memory exhausted” means find the hog, not feed it

If the log says memory is exhausted, raise the ceiling to see whether the site recovers. Add this to wp-config.php above the “stop editing” line:

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

If the site loads, you’ve confirmed the cause, not solved it. A normal WordPress page renders comfortably in 128M to 256M. When a single page needs 400M, something is wrong: a backup plugin trying to zip the whole site on every request, a poorly written import, an image library loading full-size files into memory. Raising the limit buys you time. Finding the plugin that’s burning the RAM, often the same one our plugin bloat audit across 200 sites kept turning up, fixes it for good. If the whole site feels heavy beyond this one error, our WordPress speed checklist walks through the order we tackle it in.

When it’s none of the obvious suspects

Plugins off, default theme, memory raised, and still blank? A few things are left. A stale page cache can keep serving the broken version after you’ve fixed it, so clear your caching plugin and your CDN, then hard-refresh. A PHP version jump from your host can break older code overnight; if the site died without you touching anything, check whether the host moved you to PHP 8.2 or 8.3 and roll back temporarily while you update the plugins that choked. And on rare occasions a core file is corrupted, which a fresh copy of wp-admin and wp-includes from a matching WordPress download will replace without touching your content.

If you’re staring at a corrupted core or a database connection error underneath the white screen, restoring from a clean backup is faster than forensics. That’s only an option if the backup exists and you’ve tested it, which is the whole argument in our guide on how to back up WordPress properly.

When to stop and hand it over

There’s a point where the smart move is to stop poking a live site. If the white screen is on a store taking orders, if the debug log points at the database, or if you’ve been at it for an hour and the page is still blank, the cost of guessing is higher than the cost of help. We do emergency recovery through our WordPress support service: we read the server logs, get the real error in minutes, and bring the site back without trial and error on production. Knowing when to call is part of the skill, not a failure of it.

The white screen feels catastrophic because it gives you nothing to read. It isn’t. It’s one fatal error behind a blank page, and the page itself told you where to look before you opened a single file.

Frequently asked questions

How do I fix the WordPress white screen of death?

Start by checking where the screen is blank. If only the front end is white but wp-admin still works, switch to a default theme. If the admin is white too, rename the plugins folder over SFTP to disable everything at once, then reload. If neither helps, turn on WP_DEBUG_LOG and read the last line of wp-content/debug.log. That line names the file and plugin that crashed.

What causes a white screen instead of an error message?

By default WordPress hides PHP fatal errors from visitors, so a crash shows a blank page instead of the error text. The error is still happening. It’s written to your server’s PHP error log and, once you set WP_DEBUG_LOG to true, to wp-content/debug.log. The white screen is the symptom; the log line is the cause.

Why is my WordPress admin a white screen but the site loads?

Something that only runs in the dashboard broke: an admin-only plugin, a half-finished plugin update, or wp-admin running out of memory because the admin loads more code than the front end. Bump WP_MEMORY_LIMIT to 256M in wp-config.php first. If that doesn’t clear it, disable plugins and watch which one brings the admin back.

Can I fix the white screen without FTP?

Often yes. WordPress 5.2 and later sends a ‘technical issue’ email to the admin address with a recovery link. That link logs you into a safe version of wp-admin where the broken plugin or theme is already paused, so you can deactivate it from the dashboard. No FTP, no file manager.

The site went white right after an update. What now?

The thing you just updated is almost certainly the cause. If it was one plugin, rename that single plugin’s folder over SFTP to switch it off. If it was several at once, that’s why we never batch-update on a live site without a backup. Restore from the backup you took before updating, then update one item at a time on staging.

Should I increase the PHP memory limit to fix this?

Raise it to 256M as a test. If the site comes back, fine, but treat it as a clue, not a cure. A plugin that needs 400M of RAM to render a page has a real problem, and a bigger limit just delays the next crash. Find the plugin that’s eating the memory rather than feeding it more.