Troubleshooting the WordPress “White Screen of Death” via SSH

A blank white page with no error text almost always means PHP hit a fatal error and died before WordPress could render anything. Troubleshooting the WordPress “White Screen of Death” via SSH is usually faster than clicking around a dashboard you can’t even load, because the server log names the exact file and line that broke. In most cases I can find the culprit in under five minutes with three commands.

The steps below assume you have SSH access, your site root path, and a user with permission to edit files. If your host only gives you FTP, the same logic applies, but you lose the speed of grep and WP-CLI.

What a Blank Page Actually Tells You

PHP is configured with display_errors off on nearly every production server, which is correct behavior for security but unhelpful during an outage. When a plugin calls an undefined function or a theme file has a syntax error, PHP halts and returns an empty response body with a 200 or 500 status code.

Two other causes produce the same blank screen: exhausted memory and an infinite redirect loop that ends in a truncated response. A quick curl -I https://yoursite.com from the command line separates them, since a 500 points at a fatal error and a 200 with zero bytes often points at output buffering or a cache layer serving a broken page.

Connect and Confirm Where WordPress Lives

Log in with ssh user@yourserver -p 22, then locate the install rather than assuming a path. Running find /home -name wp-config.php -maxdepth 4 2>/dev/null returns the site root in a second or two on most accounts.

Once you’re in the right directory, check that the core files are still present and readable:

• ls -la to confirm wp-content, wp-admin and wp-includes exist with sane ownership.
• df -h . to rule out a full disk, which silently breaks sessions, caches and log writes.
• php -v to see which PHP version the CLI uses, remembering the web handler may run a different one.

That last point trips people up constantly. A site can run fine on PHP 8.1 and fatal on 8.3 after a version bump, so verifying the PHP version your hosting stack serves is part of the diagnosis, not an afterthought.

Read the Error Log Before You Change Anything

The fastest single command in this whole process is tailing the log. Try these paths in order, since the location depends on your stack:

• tail -n 50 /path/to/site/error_log (common on cPanel and LiteSpeed setups)
• tail -n 50 /var/log/nginx/error.log or /var/log/apache2/error.log
• tail -n 50 wp-content/debug.log if WordPress logging was already enabled

You’re looking for a line beginning PHP Fatal error: followed by a file path. Something like Uncaught Error: Call to undefined function wc_get_product() in /wp-content/plugins/custom-addon/init.php:42 ends the investigation immediately.

If the log is enormous, filter it: grep -i "fatal" error_log | tail -n 20. Timestamps matter here, because an old fatal from three weeks ago will send you chasing a bug that was already fixed.

Enable WP_DEBUG Without Breaking the Front End

When the server log is empty or rotated, turn on WordPress debugging and write errors to a file instead of the screen. Edit wp-config.php with nano wp-config.php and set three constants above the “stop editing” comment:

We cover this topic in more depth in What Causes the "504 Gateway Timeout" in WordPress and How to Fix It.

We cover this topic in more depth in How to Implement Server-Side Tracking for Google Analytics 4 in WordPress.

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

Reload the broken URL once, then run tail -f wp-content/debug.log and hit it again to watch entries appear live. The official WordPress debugging documentation covers the additional constants for script debugging and database query logging if the fatal lives deeper in core.

Turn these constants back off once the site is up. Leaving WP_DEBUG enabled on a production site risks leaking file paths through any plugin that ignores the display setting.

Disable Plugins From the Command Line

Roughly 60 to 70 percent of the white screens I’ve handled trace back to a single plugin, usually one that updated overnight. With WP-CLI installed, wp plugin deactivate --all takes a second and tells you instantly whether the front end recovers.

Reactivate them one at a time with wp plugin activate plugin-slug, checking the homepage after each. If WP-CLI itself fatals (it loads WordPress, so it can), fall back to renaming the directory:

1. mv wp-content/plugins wp-content/plugins-off to disable everything at the filesystem level.
2. Load the site. A working page confirms a plugin conflict.
3. mv wp-content/plugins-off wp-content/plugins, then rename individual plugin folders until the offender surfaces.

WordPress marks renamed plugins as inactive in the database automatically, so nothing corrupts. Teams that deploy with version control can skip most of this guesswork, since a GitHub Actions deployment workflow lets you roll back the exact commit that introduced the fatal.

Test the Theme in Isolation

A broken functions.php produces the same blank page, often after a client pasted a snippet from a tutorial. Run wp theme activate twentytwentyfour to switch to a default theme, or rename the active theme folder and let WordPress fall back on its own.

If the site returns, run php -l wp-content/themes/your-theme/functions.php to lint the file. PHP reports syntax errors with a line number, and an unclosed brace or stray ?> is the usual answer.

Memory Exhaustion and How to Confirm It

An “Allowed memory size of 268435456 bytes exhausted” line in the log means PHP ran out of headroom, commonly on import scripts, page builders or large WooCommerce catalogs. Check the current value with php -i | grep memory_limit, keeping in mind the PHP configuration directives can differ between CLI and FPM pools.

Raise the WordPress-side limit by adding define('WP_MEMORY_LIMIT', '512M'); to wp-config.php, and the admin limit with WP_MAX_MEMORY_LIMIT. Most content-heavy sites run comfortably at 256M to 512M; needing more than that usually signals a runaway query rather than a legitimate need. Publishers running high-volume editorial stacks often hit this first, which is why hosting built for magazine-scale WordPress ships with larger pools by default.

Verify Core Files and Rule Out Cache

A failed update or a malware cleanup can leave core in a half-written state. wp core verify-checksums compares every core file against WordPress.org and lists anything modified or missing, and wp core download --force --skip-content restores them without touching your uploads or themes.

Before you conclude the code is broken, flush the caches: wp cache flush, plus any object cache or LiteSpeed purge command your stack provides. I’ve watched people spend an hour debugging a plugin when a stale full-page cache was serving an empty document generated during a deploy. Take a backup with wp db export backup.sql before any destructive step, and if the fatal sits inside core itself, that’s the point to involve your hosting support team rather than experimenting on production.

Frequently Asked Questions

Why Does the White Screen Appear Only in wp-admin?

An admin-only white screen almost always means a plugin’s admin-side hook is fatal, and the front end is served from cache. Rename the plugins folder over SSH, log in, then reactivate plugins one by one to find the one whose admin code breaks.

Can I Fix the White Screen Without WP-CLI?

Yes, every step here has a filesystem equivalent using mv, nano and tail. WP-CLI saves perhaps 10 to 15 minutes on a typical incident, but renaming plugin and theme directories achieves the same deactivation because WordPress cannot load a folder that no longer exists.

How Long Should Recovery Take?

A plugin-caused white screen is typically resolved in 5 to 20 minutes once you have log access. Database corruption or a compromised install can take several hours, which is when restoring a backup from the last known-good point is faster than debugging.

Does Increasing Memory Always Fix It?

No, memory limits explain maybe one in five white screens. If the log shows an “Uncaught Error” or “syntax error” instead of an exhaustion notice, adding memory changes nothing and hides the real cause.

Get SSH Access and Logs That Actually Help

Debugging is far quicker on a platform that gives you real SSH, WP-CLI preinstalled and per-site error logs you can tail. Take a look at our business WordPress hosting plans or talk to our team about migrating a site that keeps going dark.