Fix a WordPress white screen of death

Checked 9 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 6 minutes

Case file

Symptom: Blank page, or the critical error page, with HTTP 500
Cause: A plugin fatal error: a call to a function that does not exist
Fix: Read the debug log, then deactivate the plugin while skipping plugin loading
Result: The homepage returns HTTP 200 again

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

A white screen of death means a PHP fatal error stopped WordPress before it could print anything. The page gives you nothing to work with, so the first job is to make WordPress write the error down somewhere you can read it. That is what WP_DEBUG and WP_DEBUG_LOG do: the official debugging guide says WP_DEBUG_LOG saves errors to debug.log in the content directory, and that the log is the place to look when the error happens off-screen. The most common cause is a plugin — the official list of common errors says a plugin causing compatibility issues is the first thing to check, and to deactivate plugins and reactivate them one by one.

This guide reproduces the break first. A disposable install ran a small plugin that worked, then received a bad update that calls a function that does not exist. The homepage went from HTTP 200 to HTTP 500, the log named the plugin file and line, and deactivating that plugin brought the site back.

What you need

Access to the server files (SSH, SFTP, or your host file manager) and to wp-config.php.
WP-CLI installed, or a way to rename a folder on the server as a fallback.
A backup or a staging copy if this is a live site. The official debugging guide says the same: verify you have a staging environment or a backup before changing anything.

The diagnosis

1. Confirm the symptom

Load the homepage and note the status code, not just what the browser shows. In the reproduction, the healthy site returned HTTP 200. After the bad plugin update it returned HTTP 500 with this message:

Output — homepage after the bad plugin update

HTTP 500, 2704 bytes
There has been a critical error on this website.

Key result: HTTP 500 plus “There has been a critical error on this website” is the modern white screen. The page itself names nothing — the cause is in the log, which is the next step.

WordPress 5.2 and later shows this critical-error page instead of a literal blank page. Older installs show a genuinely blank page. Either way, the diagnosis is the same.

2. Turn on WP_DEBUG and read the log

Add three lines to wp-config.php, before the line that reads /* That's all, stop editing! Happy blogging. */. The official guide is explicit that the defines must go before that line. With WP-CLI:

Command — enable debug logging

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

WP_DEBUG_DISPLAY false keeps errors out of the page HTML while the log still records them. The official guide recommends this pairing on any site visitors can reach, and warns against leaving WP_DEBUG on live sites — it is a local and staging tool.

Then load the homepage once so the error is written, and read wp-content/debug.log:

Output — wp-content/debug.log

[09-Nov-2026 21:15:16 UTC] PHP Fatal error:  Uncaught Error: Call to undefined
function srm_broken_call_to_a_function_that_does_not_exist() in
.../wp-content/plugins/srm-broken/srm-broken.php:7

Key result: the log names the exact file, line, and function: wp-content/plugins/srm-broken/srm-broken.php, line 7. The plugin folder srm-broken is the culprit — no guessing, no deactivating everything at random.

Trap: a plugin that fatals the moment it loads cannot be activated in the first place — WP-CLI and the admin screen both refuse, because activation runs the plugin file. So if the site broke right after an update, the file changed after activation. That is the realistic trigger, and it is the one reproduced here: the plugin worked at version 1.0, and the 1.1 update broke it.

The fix

3. Deactivate the plugin that caused it

The obvious command does not work here, and the reproduction proved it. Plain deactivation loads WordPress, WordPress loads the active plugins, and the broken plugin fatals before WP-CLI can do anything:

Output — plain deactivation fails

$ wp plugin deactivate srm-broken
Fatal error: Uncaught Error: Call to undefined function
srm_broken_call_to_a_function_that_does_not_exist() in
.../wp-content/plugins/srm-broken/srm-broken.php:7
Error: There has been a critical error on this website.

The fix is --skip-plugins, a documented WP-CLI global parameter that loads WordPress without loading any plugins, so the fatal never fires:

Command — deactivate while skipping plugin loading

wp plugin deactivate srm-broken --skip-plugins

Output

Plugin 'srm-broken' deactivated.
Success: Deactivated 1 of 1 plugins.

Key result: with --skip-plugins, deactivation succeeds and the fatal error never runs. This is the step most guides skip — and the reason “just deactivate it with WP-CLI” fails on exactly the sites that need it most.

Verify the site is back

Load the homepage again and check the status code:

Output — homepage after deactivation

HTTP 200
<title>SRM Test</title>

Step	Homepage status
Healthy site, plugin working	HTTP 200
After the bad plugin update	HTTP 500 — critical error page
After `wp plugin deactivate --skip-plugins`	HTTP 200

Then decide what to do with the plugin: leave it off and find a replacement, roll it back to the previous version, or report the fatal to its author with the log line. Do not just reactivate it — the same file will fail the same way. When the site is healthy, turn WP_DEBUG back off: it is meant for local testing and staging installs, not live sites.

If that didn’t work

Rename the plugin folder

If you have no WP-CLI access, the manual method in the official common-errors guide works too: rename the plugin folder, which deactivates it because WordPress can no longer find it. The reproduction verified this independently — a clean re-break (HTTP 500) followed by renaming wp-content/plugins/srm-broken to srm-broken-OFF returned the homepage to HTTP 200:

Command — rename the plugin folder

mv wp-content/plugins/srm-broken wp-content/plugins/srm-broken-OFF

If the white screen survives deactivating every plugin, the theme is the next suspect: the official guide says to switch to a default theme such as Twenty Twenty-Five, or rename the active theme folder the same way.

What happened

The site went blank because a plugin update called a function that did not exist. The debug log named the file and the line, the plugin was deactivated while plugin loading was skipped, and the homepage returned HTTP 200. Debugging was then turned back off.

Where this came from

The debugging constants, the rule that the defines go before “That’s all, stop editing!”, and the warning against leaving WP_DEBUG on live sites come from Debugging in WordPress — Developer.WordPress.org.
The first white-screen cause to check, deactivating by renaming the plugin folder, and switching to a default theme if the theme is suspect come from Common WordPress errors — WordPress.org.
The deactivate command and its output come from wp plugin deactivate — Developer.WordPress.org.
The --skip-plugins parameter, which skips loading all plugins while mu-plugins still load, comes from WP-CLI global parameters — Developer.WordPress.org.