"There has been a critical error on this website": what it means and how to fix it

"There has been a critical error on this website" is the message WordPress shows when the PHP code that runs your site hits a fatal error and stops. WordPress added this screen, and a "recovery mode" to go with it, in version 5.2 in 2019; before that, the same problem produced a blank white page. The message is generic on purpose, so visitors do not see technical details, but the cause is almost always one of a small number of things: a plugin update, a theme change, or the host upgrading PHP. It is one of the most asked-about WordPress problems: a single Stack Exchange question about it has been viewed more than 52,000 times, and the WordPress.org forums carry a steady flow of new threads about it after plugin and core updates. This guide explains what the exact wording tells you, what you can safely check yourself, and what your developer or host should do.

What the message is telling you

The message means a PHP "fatal error" stopped WordPress from building the page. The exact wording changes depending on where you see it, and each version is a clue. These are the four versions in WordPress core (from class-wp-fatal-error-handler.php):

Each version links to WordPress's troubleshooting documentation. None of them names the plugin or theme at fault. That information is in the email and in the server's error log. If your site shows a completely blank white page with no message at all, the cause is similar but the first steps differ slightly; see our guide to the WordPress white screen of death.

Symptom, likely cause, fix

When it started is the most useful clue you have. Match it here.

Forum threads such as critical error after a plugin update, critical error after an automatic plugin update and site down after a core update follow the same pattern: an update, a crash, and a fix that came from reading the actual error.

Safe checks you can do yourself

These steps cannot make things worse. They either fix the problem or give your developer exactly what they need.

1. Write down what changed and when. An update, a new plugin, an email from the host, a staff member editing something. Note the time the site was last known to work.
2. Search every inbox, including spam, for the recovery email. The subject line is "[Your Site Name] Your Site is Experiencing a Technical Issue". It names the plugin or theme that crashed and includes a recovery link.
3. If the email exists, click the link and log in. WordPress shows which plugin or theme it paused. Deactivate that one, and check the site in a private window.
4. Check the hosting dashboard for a recent PHP version change and for the date of the last backup. Many hosts show both on the main screen.
5. Do not reinstall WordPress, delete plugins, or restore an old backup yet. A restore may roll back orders, form entries or content added since the backup, and deleting a plugin can delete its settings.

If there is no email, the most likely reason is that the site's admin email address is old, belongs to a former developer, or the site cannot send email at all. That is common, and the next section explains it.

How recovery mode works, and why the email goes missing

Recovery mode is a WordPress feature that pauses the broken plugin or theme for one person, so they can log in and fix it while the public site stays broken. It was introduced in WordPress 5.2. Here is how it behaves, from the core code:

• Who gets the email: the address in Settings, General, "Administration Email Address" (the admin_email option). A developer can send it elsewhere by defining RECOVERY_MODE_EMAIL in wp-config.php (core reference).
• How often: at most once per day by default (the recovery_mode_email_rate_limit setting is one day). If the first email went to the wrong place, a second will not come for a day.
• How long the link lasts: the email says when it expires, by default about a day. If the error happens again after that, a new link is sent.
• What it changes: clicking the link sets a cookie in that browser only. The broken extension is paused for that browser. Visitors still see the error until the plugin is deactivated or fixed.

So the email goes missing for three reasons: the admin email is an address nobody reads (often the original developer's), the site cannot send email, or the email was already sent once in the last day. The first two are worth fixing permanently. See our guides to being locked out of WordPress admin and WordPress not sending email.

For your developer or host: find and fix the real error

This section needs hosting access: SSH with WP-CLI, or the host's file manager. Back up first.

wp db export before-fix.sql

1. Read the actual error

The server's PHP error log usually already has the line you need. Where it lives depends on the host (often a "Logs" or "Errors" screen in the control panel). If it is empty, turn on WordPress's own log in wp-config.php, as set out in the WordPress debugging guide. Add these above the line that says "That's all, stop editing!":

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

Load the broken page once, then read the end of the log:

tail -n 30 wp-content/debug.log

A fatal error line names the file. An illustrative example (not from a real site):

PHP Fatal error:  Uncaught Error: Call to undefined function example_helper()
in /home/site/public_html/wp-content/plugins/example-plugin/includes/class-loader.php:42

The folder after /plugins/ or /themes/ is the culprit. WordPress's own guide warns against leaving debugging on for live sites, so set WP_DEBUG back to false when you are done, and delete debug.log, because it can expose file paths.

2. Switch off the plugin that crashed

# list plugins without loading any of them
wp plugin list --skip-plugins --skip-themes --fields=name,status,version

# deactivate the one named in the log
wp plugin deactivate example-plugin --skip-plugins --skip-themes

# no SSH: rename its folder in the file manager
mv wp-content/plugins/example-plugin wp-content/plugins/example-plugin.off

# no idea which plugin: rename the whole folder, then put it back
mv wp-content/plugins wp-content/plugins.off

If you renamed the whole plugins folder and the site loads, rename it back, then reactivate plugins one at a time until the error returns.

3. Roll the plugin back to the version that worked

# for a plugin from the WordPress.org directory
wp plugin install example-plugin --version=2.4.1 --force
wp plugin auto-updates disable example-plugin

Use the version that was installed before the update. For premium plugins, download the previous version from the vendor's account area. Turning off auto-updates for that one plugin stops it reinstalling the broken version tonight; turn them back on once the vendor ships a fix.

4. Theme errors

wp theme list --fields=name,status,version
wp theme activate twentytwentyfive --skip-plugins --skip-themes

Use any default theme that is installed. If the error came from an edit to functions.php, restore the previous copy of that file instead of switching theme, so the site keeps its design.

5. PHP version and memory

# which PHP the site actually runs
wp eval 'echo PHP_VERSION, PHP_EOL;' --skip-plugins --skip-themes

If the error began right after a PHP upgrade, switching back in the host's panel is a fair stopgap while the old code is updated, but not a fix: according to php.net, PHP 8.1 is already out of support and PHP 8.2's security support ends on 31 December 2026. Our guide to WordPress and PHP end of life covers the upgrade.

For "Allowed memory size exhausted", raise the limit in wp-config.php, then find out why so much memory is needed:

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

6. A core update that did not finish

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

This replaces WordPress's own files with clean copies of the same version and leaves wp-content (themes, plugins, uploads) alone. If verify-checksums reports files that should not exist, stop: that can be a sign of a compromise, covered in how to fix a hacked WordPress site.

Do automatic updates protect you?

Partly. WordPress 6.3 added rollback when a manual plugin or theme update fails to install. WordPress 6.6 went further: for plugin auto-updates, WordPress now checks the home page with a loopback request and, if it finds a PHP fatal error, puts the previous version back and emails the site admin. The merge proposal and the 6.6 field guide describe it.

That still leaves gaps where a critical error can get through:

• The check loads the home page. An error that only shows on checkout, a form page or in the dashboard is not caught.
• It covers plugin auto-updates. A PHP upgrade by the host, a manual edit, or a theme change is not covered.
• The rollback email goes to the admin email address, with the same problem as the recovery email if that address is old.
• A host loopback failure or a caching plugin can confuse the check, which has been reported on the support forums.

Auto-updates remain worth having for security. The safer setup is staged updates: test on a copy, then update the live site, with a backup taken just before.

What a critical error does NOT mean

How to stop it happening again

1. Set the admin email to an address the business reads. It is where the recovery and rollback emails go.
2. Keep a daily off-server backup, and test a restore once. Our guide to backing up WordPress explains what to keep.
3. Update on a staging copy first for anything that takes payments or leads. A staging site is a private copy where updates can be tried safely.
4. Remove plugins you do not use. Every plugin is another update that can break.
5. Plan PHP upgrades rather than letting the host surprise you.
6. Make sure the site can send email, so warnings reach you.

When to hand it over, and what to gather first

Hand it over if the recovery email never came, you do not have hosting access, the site takes payments or bookings, or the first plugin you switch off does not fix it. Gather this before you contact anyone:

• The site address and the exact wording of the message.
• When it started, and what changed just before.
• The recovery email, if you found it (forward it; do not click it twice).
• Logins for the hosting account, the domain registrar and DNS, and WordPress, or at least the names of the companies.
• Where backups are kept, and the date of the newest one.
• Any premium plugin or theme licences, so the developer can download the right versions.