How to Fix "There Has Been a Critical Error on This Website" in WordPress

You load your site and instead of your homepage you get one plain sentence: "There has been a critical error on this website." If you're logged in, you might also see a link to "Learn more about troubleshooting WordPress." This guide walks through exactly how I diagnose this error on client sites, from the fastest checks to the deeper fixes.

What the error actually means

Since WordPress 5.2, core includes fatal error protection. When PHP throws an error it can't recover from, WordPress catches it and shows the generic "critical error" message instead of a blank white screen. At the same time it tries to:

• Email the site's admin address with the subject "Your Site is Experiencing a Technical Issue". That email names the plugin or theme that caused the error and includes a special recovery mode link.
• Pause the faulty plugin or theme for anyone who logs in through that recovery link, so you can get into wp-admin and fix things.

So the first thing to do is check the admin email inbox, including spam. If the email arrived, you may be able to fix this in two clicks.

Step 1: Use the recovery mode email (if you got it)

1. Open the "Technical Issue" email and read which plugin or theme it blames, e.g. "In this case, WordPress caught an error with one of your plugins, Example Plugin."
2. Click the recovery mode link (it looks like /wp-login.php?action=entered_recovery_mode) and log in.
3. WordPress shows a notice listing the paused extension. Go to Plugins, deactivate it, then click Exit Recovery Mode.
4. Load the front end in a private window. If the site works, you've found the cause. Look for an update to that plugin, or contact its developer with the error details from the email.

No email? That's common: many hosts don't send PHP mail reliably. Move on to the debug log.

Step 2: Turn on the WordPress debug log

The debug log turns a vague message into an exact file and line number. Connect over SFTP or your host's file manager, open wp-config.php in the site root, 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 );
@ini_set( 'display_errors', 0 );

These lines must be placed above the line that says /* That's all, stop editing! Happy publishing. */. WP_DEBUG_DISPLAY set to false keeps errors out of the page your visitors see. They're written to wp-content/debug.log instead.

Reload the broken page once, then open wp-content/debug.log. Scroll to the bottom and look for the most recent line starting with PHP Fatal error.

Step 3: Read the fatal error line

Here are the patterns I see most often, and what each one tells you:

The path points into a plugin or theme

PHP Fatal error:  Uncaught Error: Call to undefined function get_field()
in /home/site/public_html/wp-content/themes/my-theme/functions.php:142

The folder after /plugins/ or /themes/ is your culprit. In this example the theme calls get_field(), a function from Advanced Custom Fields, and ACF has been deactivated or removed. Reactivate the missing plugin, or wrap the call in if ( function_exists( 'get_field' ) ).

Allowed memory size exhausted

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes)

PHP ran out of memory. Add this to wp-config.php:

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

If your host's PHP memory_limit is lower than these values, WordPress can't go above it, so you may need to raise the limit in your hosting panel. And if a site that used to run fine in 128M suddenly needs more, something is likely looping or loading too much data. Raising the limit gets the site back up, but the cause still needs finding.

Errors that appeared after a PHP upgrade

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
PHP Fatal error:  Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given

These come from code written for PHP 7 that breaks on PHP 8. If your host just upgraded PHP, temporarily switching back to the previous version in your hosting panel will bring the site back while you fix the code. I've written a full guide to fixing WordPress errors after a PHP 8 upgrade.

Parse error / syntax error

PHP Parse error:  syntax error, unexpected '}' in
/wp-content/themes/my-child-theme/functions.php on line 88

This one is almost always a recent manual edit, usually a snippet pasted into functions.php. Open the file, go to the line number, and undo the last change. This is exactly why I recommend a code snippets plugin or a small custom plugin over editing functions.php through the WordPress theme editor.

Step 4: Disable plugins without wp-admin

If the log isn't conclusive, or you just need the site back up right now, disable plugins from outside WordPress.

Via SFTP or file manager

1. Go to wp-content/ and rename the plugins folder to plugins-off. WordPress will deactivate every plugin.
2. Check the site. If it loads, rename the folder back to plugins, so they're all present again but still deactivated.
3. Reactivate plugins one at a time in wp-admin, reloading the front end after each one. The one that brings the error back is your culprit.

To test a single plugin, rename only its folder, e.g. wp-content/plugins/woocommerce to woocommerce-off.

Via WP-CLI (faster, if you have SSH)

# List plugins without loading any of them
wp plugin list --skip-plugins --skip-themes

# Deactivate one suspect
wp plugin deactivate example-plugin --skip-plugins --skip-themes

# Or deactivate everything
wp plugin deactivate --all --skip-plugins --skip-themes

The --skip-plugins --skip-themes flags matter here. Without them, WP-CLI tries to load the broken code and fails with the same fatal error.

Step 5: Rule out the theme

If disabling plugins didn't help, switch to a default theme. With WP-CLI:

wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

Without SSH, rename your active theme's folder in wp-content/themes/. WordPress will fall back to any installed default theme. If the site loads, the error is in your theme or child theme, and the debug log line will point you to the exact file.

Step 6: Replace WordPress core files

Occasionally a failed auto-update or a malware infection leaves core files corrupted. Verify core against the official checksums:

wp core verify-checksums --skip-plugins --skip-themes

If files are reported as modified or missing, re-download core without touching wp-content or wp-config.php:

wp core download --skip-content --force --skip-plugins --skip-themes

Step 7: Check the server error log

If debug.log stays empty, the error may happen before WordPress loads its error handler, or PHP may not have permission to write the file. Check your host's error log instead. In cPanel it's under Metrics → Errors, and many hosts also put an error_log file in the site root. On a VPS, look in /var/log/nginx/error.log or the PHP-FPM log.

After the fix: clean up

• Set WP_DEBUG back to false and delete wp-content/debug.log. Left in place, it can expose file paths to anyone who requests it.
• Clear any page cache (plugin, host and Cloudflare) so visitors don't keep seeing the cached error page.
• Write down what caused it. If an auto-update did, consider turning off auto-updates for that plugin and testing future updates on staging first.

How to stop it from happening again

Nearly every critical error I fix has the same root cause: changes going straight to production. A staging site, updates applied one at a time, and a backup taken before each change turn a site-down emergency into a five-minute rollback. If your host doesn't offer staging, a plugin like WP Staging can create one.