'There Has Been a Critical Error on This Website'

Your site — front end, admin, everything — is suddenly one sentence:

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

This screen is a mask. Behind it is an ordinary PHP fatal error with a file name and a line number, and that file path almost always identifies the guilty plugin or theme within seconds. WordPress hides the details from visitors on purpose (error messages leak server information), which means your first job is not fixing anything — it is getting the real error message in front of your eyes.

Key Takeaways

The critical error screen hides a specific PHP fatal error that names a file and line — recover that first, guess never.
WordPress emails a recovery-mode link to the site admin address when this happens; check spam before assuming it never came.
The failing file’s path is the diagnosis: wp-content/plugins/something means deactivate that plugin, themes/something means switch themes.
PHP version upgrades are a leading trigger — an unmaintained plugin meets a new PHP and fatals on the first request.
Every plugin can be deactivated without wp-admin access, via WP-CLI or by renaming its folder — and its settings survive.

Quick Fix

Read the last lines of the web server’s error log — the PHP fatal hiding behind the screen names the exact file and line, which nearly always identifies the plugin or theme at fault.

sudo tail -n 30 /var/log/apache2/error.log /var/log/nginx/error.log 2>/dev/null

What the Message Hides

Since WordPress 5.2, a fatal PHP error no longer produces the old blank page — WordPress catches it, shows this generic notice, and tries to email the admin a recovery link. Same failure, better wrapping. (On older sites the identical problem appears as the white screen of death — the debugging path below works for both.)

A fatal means PHP stopped mid-request: a function that no longer exists, a class two plugins both declare, exhausted memory, or code incompatible with the server’s PHP version. The error text tells you which. Get it one of three ways.

Step 1: Get the Real Error

Route A: The server’s error log

If you have shell access this is the fastest route — the fatal is already recorded:

sudo tail -n 30 /var/log/apache2/error.log /var/log/nginx/error.log 2>/dev/null

Look for a line beginning PHP Fatal error:. Reload the broken page first if the log looks stale, then read the newest entry.

Route B: WordPress debug logging

No shell, or the server log is out of reach on shared hosting? Turn on WordPress’s own log. In wp-config.php, above the line that says “That’s all, stop editing”, add:

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

Reload the broken page once, then read wp-content/debug.log. Keeping WP_DEBUG_DISPLAY false means visitors see no stack traces while you work.

Route C: The recovery email

Check the site admin inbox (and spam) for a message titled “Your Site is Experiencing a Technical Issue”. It contains the error details and a special login link — often the whole fix in one email.

Step 2: Use Recovery Mode If You Got the Email

The emailed link opens wp-admin in recovery mode: WordPress pauses the broken extension just for your session, so the dashboard works even though the site is down. Go to Plugins (or Appearance → Themes), deactivate the one flagged as causing the issue, and exit recovery mode. If the email arrived, this is usually a two-minute repair — but knowing the manual routes below still matters, because the email frequently does not arrive on servers that cannot send mail.

Step 3: Match the Error to the Fix

The trace points into wp-content/plugins/

Deactivate that plugin. With WP-CLI:

wp plugin deactivate broken-plugin-name

Without shell access, rename the plugin’s folder over SFTP or the hosting file manager — broken-plugin-name to broken-plugin-name.off. WordPress silently deactivates a plugin whose folder disappears; the site comes back immediately. Renaming loses nothing: the plugin’s settings live in the database and return when you reactivate it (update it first).

The trace points into wp-content/themes/

Switch to a default theme:

wp theme activate twentytwentyfive

No WP-CLI? Rename the broken theme’s folder the same way — WordPress falls back to a default theme if one is installed. The site will look wrong and be up, which beats looking like an error message.

The error says “Allowed memory size exhausted”

Raise WordPress’s limit in wp-config.php:

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

PHP’s own memory_limit must be at least as high — check it under Tools → Site Health → Info → Server, or with php -i | grep memory_limit. If a modest site needs endless memory raises, some plugin is leaking; the limit is the symptom.

The error says “Call to undefined function” or names PHP syntax

This is the classic day-after-a-PHP-upgrade fatal: the server moved (say from PHP 8.0 to 8.3) and an unmaintained plugin still calls something that no longer exists. Update the named plugin or theme first; if no update exists, replace it — it is abandonware on a treadmill. Downgrading PHP works as a brief stopgap but trades a broken site for an unpatched one.

The trace points into wp-includes/ or wp-admin/

Core files rarely break themselves — suspect an interrupted update or a compromise. Verify and repair:

wp core verify-checksums
wp core download --force --version=$(wp core version)

The second command re-downloads core files only — it does not touch wp-content, your uploads, or the database. If checksums keep failing after a repair, treat it as a possible malware situation and scan before trusting the site.

Verify the Fix

Load the site logged out (or in a private window) so you are not seeing a cached page, and click through a few pages including wp-admin. Then remove the debug flags from Step 1 — set WP_DEBUG back to false — and delete or truncate wp-content/debug.log, which can contain file paths you would rather not leave world-readable. Finally, Tools → Site Health should be free of critical issues.

Prevent It From Recurring

Update one thing at a time. Bulk-updating twelve plugins and then finding the site down leaves you bisecting. One at a time, with a page load between, turns the next fatal into a known culprit.

Treat PHP upgrades as a project, not a toggle. Before moving PHP versions, check each plugin’s tested-up-to information, and try the new version on a staging copy if you have one. The fatals in this guide cluster suspiciously around the day someone clicked “upgrade PHP”.

Make sure the recovery email can reach you. The admin address under Settings → General must be one you read, and the server must actually deliver mail — if password-reset emails from the site never arrive, recovery emails will not either. Fix delivery (an SMTP plugin suffices) while nothing is on fire.

Keep restorable backups. A scheduled off-server backup turns the worst case of every incident in this guide into an hour of restore instead of a rebuild.

Frequently Asked Questions

Is this the same thing as the white screen of death?

Effectively yes. The white screen was how a PHP fatal looked before WordPress 5.2; the critical error screen is the same failure with a friendlier face and a recovery email. The diagnosis is identical: recover the underlying PHP error and act on the file path it names.

What if the recovery email never arrives?

Common — many servers cannot send mail, and the message also lands in spam. Do not wait for it. Use the server error log or the WP_DEBUG_LOG method to read the fatal directly, then deactivate the offender via WP-CLI or folder rename.

Can I see the error on screen instead of digging through logs?

Temporarily set WP_DEBUG and WP_DEBUG_DISPLAY to true and the fatal prints in the browser. Only do this for the minutes you need it on a low-traffic site — stack traces expose paths and versions to every visitor — and switch it back off immediately.

Will renaming a plugin folder delete its settings?

No. Settings live in the database, not the plugin folder, so deactivating a plugin this way loses nothing. Rename the folder back (ideally after updating the plugin) and reactivate it; configuration returns as it was.