How to fix the WordPress white screen of death (without FTP)

You open your site and there’s… nothing. A blank white page. No menu, no error, no clue. This is the White Screen of Death (WSOD), and it’s WordPress’s least helpful failure mode: something crashed hard enough to stop the page from rendering, and by default WordPress shows you nothing about what.

The good news: a WSOD almost always has a specific, fixable cause. Here’s how to find it and get the site back — including ways that don’t require an FTP client.

What the white screen actually is

Under the hood, a blank white page usually means a PHP fatal error: some code called a function that doesn’t exist, ran out of memory, or hit a type error PHP couldn’t recover from. Execution stops, and unless error display is on (it shouldn’t be, on production), the visitor just gets an empty response.

The most common culprits:

• A plugin conflict or bad plugin update — by far the most frequent cause.
• A theme error — often after switching or updating a theme.
• A PHP version mismatch — your host bumped PHP and some code isn’t compatible.
• Exhausted memory — a heavy page blows past the PHP memory limit.
• A broken edit to functions.php or a code snippet.

First: try WordPress Recovery Mode

Modern WordPress has a built-in safety net. When a fatal happens, WordPress emails the site administrator address a special Recovery Mode link. That link logs you into a stripped-down admin where the offending plugin or theme is paused, so you can deactivate it.

Check the inbox for the admin email on the site. If the email arrived, this is the fastest no-FTP fix. If it didn’t — the mail never sent, or you don’t control that inbox — read on.

Fix it by deactivating plugins

If you can still reach /wp-admin, go to Plugins and deactivate them — either all at once, or one at a time if you suspect a specific update. When the white screen clears, the last plugin you turned off is your culprit. Reactivate the rest.

If you can’t reach wp-admin, you normally have to do this over FTP or your host’s file manager: rename the wp-content/plugins folder (which deactivates everything), confirm the site comes back, then rename it back and disable plugins one by one. It works, but it’s slow and stressful — exactly when you least want slow and stressful.

Turn on the log so you can see the real error

Blindly deactivating things is guesswork. To see the actual error, enable logging. In wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // keep errors OFF the front end

WordPress then writes errors to wp-content/debug.log. Open it and look at the last entries — a fatal looks like:

PHP Fatal error:  Uncaught Error: Call to undefined function acme_init()
in /wp-content/plugins/acme/acme.php:42

That single line usually tells you the plugin, the file, and the exact problem.

Remember to set WP_DEBUG back to false when you’re done — you don’t want debug logging on forever in production.

Other quick fixes

• Raise the memory limit if the log mentions “Allowed memory size … exhausted”: define( 'WP_MEMORY_LIMIT', '256M' ); in wp-config.php.
• Switch to a default theme (like Twenty Twenty-Four) if the error points at your theme.
• Undo your last edit if the crash started right after you changed a snippet or functions.php.

The real problem: you found out too late

Notice the pattern in every fix above: they all start after the site is already down, and usually after someone told you. On a site you check hourly, that’s an annoyance. On a client site you touch once a month, the white screen can sit there for days — costing sales and trust — until an angry email arrives.

That’s the gap FatalGuard closes. It’s a free WordPress plugin that:

• catches the fatal the moment it happens (instead of a blank page),
• messages you — on Telegram, even when wp-admin is down, so the alert doesn’t depend on the site being up, and
• for a crashing plugin, gives you a one-tap link to turn it off and restore the site — no FTP, no wp-config, no folder renaming.

So instead of “the homepage has been white for two days,” you get a message within seconds — with the exact error and a button to fix it — and the site is back before anyone notices.

The short version

1. Check the admin inbox for a Recovery Mode email.
2. If you can reach wp-admin, deactivate plugins to isolate the cause.
3. Enable WP_DEBUG_LOG and read wp-content/debug.log for the real error.
4. Address the specific cause (plugin, theme, PHP version, memory).
5. Set up alerting + one-tap recovery so the next fatal is a 30-second fix, not a two-day outage.

The white screen of death is scary mostly because it’s silent. Give it a voice — and a fix button — and it stops being an emergency.

Want to catch the next one automatically? Add FatalGuard to WordPress — it’s free.