WordPress white screen and 'critical error' — what it actually means and how to fix it without losing your site

Your WordPress site was working yesterday. Today it shows a blank white page — or the dreaded “There has been a critical error on this website.” No admin panel, no error message, no clue what broke. This is the most common WordPress emergency, and the good news is it is almost always fixable in under an hour — if you know where the real error is hiding.

Why the screen goes white

A white screen means PHP hit a fatal error and stopped executing. WordPress (or your hosting) suppresses the error output for security — showing raw PHP errors to visitors leaks server paths and version info. So instead of an error message, you get nothing. The error exists; you just can't see it.

The “critical error” message is WordPress 5.2+ doing the same thing slightly better — it catches the fatal error, shows a generic message, and emails the admin a recovery link. But the actual error is still hidden until you go looking for it.

Step 1: Find the real error message

You need to see what PHP is actually complaining about. Three ways, from easiest to most involved:

Option A: Check the admin email

If you got the “critical error” screen, WordPress sent an email to the admin address with a recovery link and often the error details. Check the inbox of the email set under Settings → General. This is the fastest path — the email usually names the exact plugin or theme that failed.

Option B: Enable WP_DEBUG

If no email came, force WordPress to show errors. Edit wp-config.php (in your site root, via FTP or your host's file manager) and find the line define( 'WP_DEBUG', false );. Replace it with:

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

This writes errors to wp-content/debug.log instead of showing them to visitors. Reload your site, then open debug.log — the fatal error will be the last line, and it names the file and line that failed.

Option C: Check your host's PHP error log

Most hosts (cPanel, Plesk, WP Engine, Kinsta) keep a PHP error log separate from WordPress. In cPanel it's under Metrics → Errors. On WP Engine it's in the dashboard under Site → Logs. This catches errors that WordPress itself can't.

Step 2: Identify the culprit

The error log will point at a specific file. The path tells you what broke:

• /wp-content/plugins/xyz/xyz.php — a plugin. Note the plugin folder name.
• /wp-content/themes/yourtheme/functions.php — your theme.
• /wp-includes/... — usually a plugin calling a deprecated WordPress function (the file path is in core, but the trigger is a plugin).

The most common cause: a plugin update broke compatibility. Either the plugin updated to a version that conflicts with your PHP version, another plugin, or your WordPress version. The second most common: a PHP version upgrade on your host (e.g., 7.4 → 8.1) broke an old plugin using deprecated syntax.

Step 3: Fix it — without losing the plugin

You have the culprit. Now, in order of preference:

If it's a plugin conflict:

Rename the plugin folder (via FTP/file manager): wp-content/plugins/xyz → wp-content/plugins/xyz-disabled. This deactivates it without deleting it. Your site comes back immediately. Then check if the plugin has an update — if yes, update and re-enable. If no, either contact the plugin developer, find an alternative, or hire someone to patch the compatibility issue.

If it's a theme issue:

Same approach — rename the theme folder to force WordPress back to a default theme (Twenty Twenty-Four). If the site comes back, the theme is the culprit. Check for a theme update or a function in functions.php calling deprecated code.

If it's a PHP version issue:

Your host upgraded PHP and an old plugin can't handle it. Two options: downgrade PHP in your hosting panel (temporary fix), or update/replace the offending plugin (permanent fix). Downgrading PHP is a security risk long-term — PHP 7.4 reached end of life in 2022.

Step 4: Patch vs. fix — know the difference

A patch hides the symptom. A fix solves the root cause. If you don't fix the root cause, the white screen comes back on the next update.

Disabling a plugin is a patch. Updating it, replacing it, or patching the deprecated code is a fix. If you just disable and move on, you've lost functionality and the underlying incompatibility is still there. A proper fix includes: identifying why the error happened, resolving that specific cause, and testing on a staging copy before pushing to production.

How to prevent it next time

White screens are preventable with a simple workflow:

• Test updates on staging first. Most managed hosts (WP Engine, Kinsta, Cloudways) include a staging environment. Apply plugin/theme updates there, click through the site, then push to production.
• Keep a backup before every update. If something breaks, you're one click from restored — not debugging PHP at midnight.
• Don't run end-of-life PHP. PHP 7.4 is unsupported. PHP 8.1+ is current. Old PHP doesn't get security patches and breaks with modern plugins.
• Limit plugins. Every plugin is a potential conflict. If a plugin hasn't been updated in 2+ years, replace it.

If your site is white-screening right now and you need it back fast, message me on Telegram @wpservicelab with EMERGENCY in the first line. I diagnose the error, identify the culprit, and fix the root cause — usually within a few hours. You get a plain-English explanation of what went wrong and what I changed, so you understand your own site better.