“There has been a critical error on this website”: the fix

What the message means

There has been a critical error on this website. Please check your site admin email inbox for instructions. Learn more about troubleshooting WordPress.

Since WordPress 5.2 this message replaces the old blank “white screen of death”. Underneath it is the same thing: PHP stopped with a fatal error, so the page could not be built. WordPress catches the error, shows this message instead of a blank page, and — if it can tell which plugin or theme caused it — pauses that extension for a recovery session and emails the site’s admin address a link to log in safely.

Nothing is deleted and the database is not damaged. One piece of code cannot run, and every page that loads it fails. The job is to find which one.

Step 1: the recovery mode email

Check the inbox of the address under Settings → General → Administration Email Address — not necessarily your own. The email is titled “Your Site is Experiencing a Technical Issue”, names the plugin or theme that failed and the file and line, and contains a recovery mode link. That link logs you in with the failing extension paused, so you can deactivate it, update it or switch theme from the normal admin screens.

The link expires after a day. If the error happens again, WordPress does not send a new email for every occurrence, so an old, expired message is a common dead end.

Step 2: no email? Read the error yourself

The email often never comes: the admin address is out of date, the server cannot send mail, or the error happens before WordPress has loaded enough to send it. Turn on WordPress’s own error log instead. In wp-config.php, above the line that says “That’s all, stop editing!”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // keeps errors off the public page

Load the broken page once, then open wp-content/debug.log. The last “PHP Fatal error” line is the one that matters, and its file path names the culprit:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /var/www/site/wp-content/plugins/old-slider/includes/widget.php:42

Anything under wp-content/plugins/<name>/ is that plugin; wp-content/themes/<name>/ is the theme. If debug.log stays empty, the host’s own PHP error log (in the control panel, or error_log files in the site folder) will have the same line. Turn WP_DEBUG back off when you are done — the log can grow large and it can contain paths you would rather not publish.

Step 3: disable the plugin or theme without wp-admin

If you cannot log in, deactivate from the file system. Over SFTP, FTP or the host’s file manager, rename the plugin’s folder — wp-content/plugins/old-slider to old-slider-off. WordPress cannot find it, treats it as deactivated, and the site loads. Rename it back later to reinstall or update it.

Not sure which plugin? Rename the whole wp-content/plugins folder to plugins-off. If the site comes back, it was a plugin: rename the folder back (every plugin will show as deactivated) and reactivate them one by one until the error returns. For a theme, rename its folder and WordPress falls back to a default theme such as Twenty Twenty-Five — if one is installed.

With WP-CLI it is one command: wp plugin deactivate old-slider, or wp plugin deactivate --all.

If it started after a PHP update

This is the most common cause on shared hosting, because hosts move sites to newer PHP versions on a schedule. PHP 8 removed functions that old code still calls — create_function(), each(), money_format() — and turned many warnings into fatal errors, such as passing the wrong type to a built-in function or counting something that is not an array.

• Read the fatal error in debug.log: “Call to undefined function” on one of those names is the giveaway.
• Update the plugin or theme. Maintained code was fixed for PHP 8 years ago; an extension with no update is the problem, not PHP.
• If you need the site back right now, switch PHP back one version in the hosting panel, then replace the extension before the host forces the upgrade again.

Other causes

• Memory exhausted: “Allowed memory size of 134217728 bytes exhausted”. Raise it with define( 'WP_MEMORY_LIMIT', '256M' ); in wp-config.php, then find what used it — usually an import, an image library or a page builder.
• An update that did not finish: a plugin folder with half its files after a timed-out update. Delete the folder and reinstall the plugin.
• Code pasted into functions.php: a missing semicolon or bracket fatals every page. Undo the edit over SFTP.
• Two plugins declaring the same function or class: “Cannot redeclare”. Deactivate one of them.

The checklist

1. Look for the recovery mode email in the site’s admin inbox.
2. No email: turn on WP_DEBUG_LOG and read the last fatal error in wp-content/debug.log.
3. Rename the plugin or theme folder it names, or all plugins if unsure.
4. Log in, update or replace the extension, and reactivate.
5. After a PHP upgrade: update anything that calls removed functions, or roll PHP back temporarily.
6. Turn WP_DEBUG off again.