WordPress White Screen or 'Critical Error': Find the Cause and Fix It

You open your site and get a blank white page. Or WordPress shows this message instead of your content:

There has been a critical error on this website. Please check your site admin email inbox for instructions.

Both are the same problem seen two ways. PHP hit a fatal error and stopped before it could build the page. Older WordPress versions show nothing at all, which is why people call it the "white screen of death". Since WordPress 5.2, the error handler catches most fatal errors, shows the critical error message and emails the site administrator.

The fix depends on what caused the error. In most cases it is a plugin, a theme, a PHP memory limit or a PHP version mismatch. The steps below find the cause first, so you change one thing, not ten.

Before you start: take a backup

If your host keeps automatic backups, note the time of the most recent one. If you can reach the files and database, take a fresh copy before you change anything. Some fixes below rename folders or replace files. A backup makes every step reversible.

Step 1: Check the recovery mode email

When WordPress catches a fatal error, it sends an email to the admin address in Settings > General. The subject is usually "Your Site is Experiencing a Technical Issue". It names the plugin or theme that caused the error and includes a special login link.

That link opens recovery mode. In recovery mode, WordPress pauses the faulty plugin or theme for your session only, so you can log in to the dashboard, deactivate or update it, and leave recovery mode. Visitors still see the error until you fix it. The link expires after a limited time, so use it soon.

If the email never arrived, check spam, and check that the admin email address is one you can still read. Many sites cannot send mail reliably until they use SMTP, so do not count on the email. The next steps work without it.

Step 2: Read the actual error with WP_DEBUG_LOG

Guessing wastes time. Turn on the debug log and let PHP tell you which file failed. Edit wp-config.php in the site root and add these lines above the line that says /* That's all, stop editing! */. If a WP_DEBUG line already exists, change it rather than adding a second one.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

This writes errors to wp-content/debug.log and keeps them hidden from visitors. Reload the broken page once, then read the end of the log:

# From the WordPress root folder
tail -n 50 wp-content/debug.log

If you do not have SSH, open the file in your control panel's file manager. Look for lines that start with PHP Fatal error or PHP Parse error. Some typical examples:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /home/user/public_html/wp-content/plugins/old-slider/slider.php:42

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/user/public_html/wp-includes/class-wpdb.php on line 2345

PHP Parse error:  syntax error, unexpected token "}" in /home/user/public_html/wp-content/themes/my-child/functions.php on line 88

The path tells you where to look. A path inside wp-content/plugins/ points to a plugin. A path inside wp-content/themes/ points to a theme. "Allowed memory size exhausted" points to a memory limit, and "Call to undefined function" in old code often points to a PHP version change.

If debug.log stays empty, check your hosting control panel's PHP error log. Some servers write fatal errors there instead.

Step 3: Rule out plugins

Plugins cause most critical errors, especially right after an update. If the log names a plugin, disable just that one. If it does not, disable them all and see whether the site comes back.

Without dashboard access: rename the folder

WordPress cannot load plugins from a folder it cannot find. Using SFTP, SSH or the file manager:

# Disable every plugin at once by renaming the folder
mv wp-content/plugins wp-content/plugins.off

# Site works again? Restore the folder name, then disable plugins one by one
mv wp-content/plugins.off wp-content/plugins
mv wp-content/plugins/old-slider wp-content/plugins/old-slider.off

WordPress marks a renamed plugin as deactivated. When you rename the folder back, you will need to activate the healthy plugins again from the dashboard.

With WP-CLI

The --skip-plugins and --skip-themes flags let WP-CLI run even when a plugin or theme crashes WordPress on load:

# List plugins without loading them (works even when the site is broken)
wp plugin list --skip-plugins --skip-themes

# Deactivate one plugin, or all of them
wp plugin deactivate old-slider --skip-plugins --skip-themes
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme
wp theme activate twentytwentyfour --skip-plugins --skip-themes

Step 4: Rule out the theme

If the log points to your theme, or the site still fails with all plugins off, switch to a default theme. You can use the WP-CLI command above, or rename your active theme's folder. WordPress then falls back to a default theme if one is installed. A common cause here is a small edit to functions.php with a missing bracket or semicolon. The parse error in the log gives the exact line.

Step 5: Raise the PHP memory limit, carefully

An error like Allowed memory size of 134217728 bytes exhausted means PHP reached its memory limit, here 128 MB. WordPress has its own setting on top of PHP's limit:

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

Two things to know. First, WordPress cannot go above the server's PHP memory_limit. If the host sets 128 MB, asking for 256 MB in wp-config.php changes nothing. Raise the PHP limit in your control panel's PHP settings, or ask support. Second, 256 MB is a reasonable rule of thumb for most sites, including many stores. If a site needs much more than that on every page, a plugin is probably loading too much data, and more memory only delays the next crash.

Step 6: Check the PHP version

PHP versions remove old functions. For example, create_function() and each() were removed in PHP 8.0, so an old plugin that uses them breaks the moment the server moves to PHP 8. The reverse also happens: a plugin update may require a newer PHP version than your site runs.

• If the error started right after a PHP upgrade, switch back to the previous version in your control panel, then update or replace the plugin that failed.

• If it started right after a plugin update, check the plugin's minimum PHP requirement and move to a supported PHP version.

Check the version the site really uses in Tools > Site Health > Info > Server. The php -v command over SSH can show a different version from the one that serves your website.

Other causes worth checking

• "Briefly unavailable for scheduled maintenance": an update was interrupted. Delete the .maintenance file in the site root.

• Damaged core files: after a failed update or a malware cleanup, compare and replace core files with WP-CLI.

# Check that core files match the official release
wp core verify-checksums

# Replace core files without touching wp-content
wp core download --skip-content --force

• Only the dashboard is white: often a plugin that loads only in the admin area, or the admin needing more memory than the front end. The debug log shows which.

• Error appears only for logged-in users: clear your caching plugin and any CDN cache. Visitors may be seeing an old cached copy while the real site is broken.

After the fix: turn debugging off

Set WP_DEBUG back to false and delete or empty debug.log. The log can contain file paths and other details you do not want public, and on busy sites it grows quickly. Then re-enable plugins one at a time, update the one that failed or replace it, and test the pages that matter most: home, a post, contact form and checkout.

Run WordPress on IM HOST

IM HOST WordPress Hosting runs on NVMe storage with LiteSpeed Cache and free daily backups for the whole subscription, so you can roll back if an update breaks the site. Our 24/7 engineers can read the error logs with you, change the PHP version, and help you find the plugin at fault. If your site is with another provider, our free migration moves files, databases and email with no downtime.