There Has Been a Critical Error on This Website: How to Fix It

You open your site and instead of your homepage you see one line: "There has been a critical error on this website." Sometimes there's a second line asking you to check your site admin email inbox for instructions, and a link to WordPress's troubleshooting guide. No layout, no menu, no content.

It looks alarming, but it's one of the more helpful errors WordPress shows. It means WordPress caught a PHP fatal error and stopped the page from loading half broken. In most cases one plugin or theme caused it, WordPress already knows which one, and you can fix it in a few minutes.

Below: what the message means, how to fix it step by step (with or without the email), how to find the update that caused it, and how to catch it next time.

What "there has been a critical error on this website" means#

The message is WordPress's fatal error protection, added in WordPress 5.2. Before 5.2, a PHP fatal error usually left visitors staring at a blank white page. Now WordPress catches the error, shows a short message instead, and emails the site administrator.

A PHP fatal error is an error that PHP can't recover from, so it stops running the page. Common causes:

• A plugin or theme calls a function or class that doesn't exist (often after one plugin updated and another didn't).
• Code that needs a newer PHP version than your server runs, or code that breaks on a newer PHP version.
• Two plugins declaring the same function or class.
• The page running out of PHP memory ("Allowed memory size of ... bytes exhausted").
• A syntax error from a manual edit to functions.php or a plugin file.

The important part: the error almost always comes from code inside wp-content, which means a plugin, a theme or a custom snippet. Your posts, pages and database are almost never damaged. Fixing the code brings the site back as it was.

Where you might see it#

The error can appear on the whole site, only in wp-admin, or only on certain pages. A plugin that only runs on checkout or a contact form may break just that page while the homepage looks fine. Keep that in mind when you test.

Step 1: check the admin email (the Recovery Mode link)#

When WordPress catches a fatal error, it emails the address in Settings > General > Administration Email Address (or the address in the RECOVERY_MODE_EMAIL constant, if your developer set one). The subject is usually "Your Site is Experiencing a Technical Issue".

That email tells you two useful things:

1. Which plugin or theme caused the error. It says something like "WordPress caught an error with one of your plugins", followed by the plugin's name.
2. A Recovery Mode link. The link lets you log in with the broken plugin or theme paused, so the admin area loads.

The email also includes the error details: the file and line number. Copy those somewhere before you do anything else.

Can't find it? Check spam, and check which address is set as the admin email: often it's a developer's old address. WordPress also limits how often it sends these emails, and if your server can't send mail, none arrive. In those cases, skip to Step 3.

Step 2: fix it in Recovery Mode#

Click the Recovery Mode link and log in as usual. WordPress loads the admin area with the faulty plugin or theme paused for your session only. Visitors still see the error until you fix it.

1. Look for the notice at the top of the dashboard saying one or more plugins failed to load properly.
2. Go to Plugins > Installed Plugins. The paused plugin is listed with the error that stopped it.
3. Click Deactivate on that plugin. This turns it off for everyone, so the public site comes back.
4. Open your site in a private browser window and check the pages that were failing.
5. Click Exit Recovery Mode in the admin bar.

If a theme caused the error, go to Appearance > Themes and activate a different theme, ideally a default one like Twenty Twenty-Five.

Deactivating is a stopgap. Next, roll the plugin back to the version that worked, wait for a fixed release, or replace it. Our guide on how to roll back a WordPress plugin walks through the options.

Step 3: deactivate plugins without wp-admin#

No email and no access to wp-admin? You can switch plugins off through your files. Use your host's file manager, SFTP or SSH.

Rename one plugin folder#

If the error message or the email named a plugin, go to wp-content/plugins/ and rename that plugin's folder, for example woocommerce to woocommerce-off. WordPress can't find the plugin, so it deactivates it on the next page load.

Rename the whole plugins folder#

If you don't know which plugin it is:

1. Rename wp-content/plugins to wp-content/plugins-off.
2. Load the site. If it works, a plugin was the cause.
3. Rename the folder back to plugins. All plugins will now be deactivated.
4. In Plugins > Installed Plugins, reactivate them one at a time, loading the site after each one. The plugin that brings the error back is the culprit.

Use WP-CLI#

If you have SSH access, WP-CLI is faster. Because the fatal error can also break WP-CLI, tell it to skip loading plugins and themes:

# See which plugins are active
wp plugin list --status=active --skip-plugins --skip-themes

# Deactivate the one you suspect
wp plugin deactivate plugin-folder-name --skip-plugins --skip-themes

# Or switch to a default theme
wp theme activate twentytwentyfive --skip-plugins --skip-themes

Step 4: turn on WP_DEBUG and read debug.log#

If you still don't know the cause, ask WordPress to write the error to a log file. Open wp-config.php in the site's root folder and add these lines above the line that says /* That's all, stop editing! Happy publishing. */:

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

If WP_DEBUG is already defined as false, change it rather than adding a second copy.

Load the failing page again, then open wp-content/debug.log. Look near the end for a line starting with PHP Fatal error. It looks something like this:

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

The path tells you where the error happened. /wp-content/plugins/example-plugin/ points to that plugin. /wp-content/themes/your-theme/ points to the theme. "Call to undefined function" often means a plugin depends on another plugin that's missing or outdated. "Allowed memory size exhausted" means a memory problem (see Step 6).

When you're done, set WP_DEBUG back to false or remove the lines. Don't leave a debug log growing on a live site, and don't set WP_DEBUG_DISPLAY to true in production, because visitors would see file paths and error details.

Step 5: switch to a default theme#

If the log points to your theme, or deactivating plugins changed nothing, switch to a default theme:

1. In wp-admin, go to Appearance > Themes and activate Twenty Twenty-Five (or any default theme you have installed).
2. Without wp-admin, rename your active theme's folder in wp-content/themes/. WordPress falls back to a default theme if one is installed. If none is installed, upload one first.
3. With WP-CLI, run wp theme activate twentytwentyfive --skip-plugins --skip-themes.

If the site loads with a default theme, the error is in your theme or child theme. The most common culprit is a snippet added to functions.php. If you edited that file recently, undo the edit.

Step 6: check the PHP version and memory limit#

Some critical errors aren't caused by a bug in one plugin, but by the server.

PHP version. Go to Tools > Site Health > Info > Server to see which PHP version runs your site. If your host recently upgraded PHP, an older plugin may break on the new version. If you recently updated a plugin, it may now need a newer PHP version than you have. Check the plugin's page on WordPress.org for its "Requires PHP" line. Most hosts let you switch PHP versions in the control panel, but don't stay on an old, unsupported version long term.

Memory limit. If the log says "Allowed memory size of ... bytes exhausted", PHP ran out of memory. Raise the WordPress limit in wp-config.php:

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

WordPress can't go above the limit your host sets for PHP, so if that doesn't help, ask your host to raise memory_limit. A sudden memory error right after an update can also point to a buggy plugin.

Step 7: restore a backup#

If nothing above works, or the site is down and you need it back now, restore a backup from before the error started. Most managed hosts keep daily backups you can restore from the control panel. A backup plugin such as UpdraftPlus can restore files and the database separately.

Two warnings. A full restore rolls back everything, including orders, form entries and comments since the backup. On a WooCommerce store, that can mean lost orders, so a file-only restore of wp-content/plugins is often safer. And a restore puts the same buggy version back, so turn off automatic updates for that plugin until a fixed version is released.

How to tell which update caused the critical error#

If the error started overnight with nobody touching the site, an automatic update is the most likely cause. Here's how to narrow it down:

1. Read the email from WordPress. The Recovery Mode email names the plugin or theme. That's usually the answer.
2. Check the automatic update emails. WordPress emails the admin after background plugin and theme updates, listing what was updated. Match the time with when the error started.
3. Check the debug log path. The plugin folder in the fatal error line points to the broken plugin, even if a different plugin's update triggered it.
4. Look at folder dates. In your file manager, sort wp-content/plugins by modified date. Recently updated plugins appear at the top.
5. Check the plugin changelog. On the plugin's WordPress.org page, the Development tab shows recent versions and what changed.

Since WordPress 6.6, plugin automatic updates also check that the site still loads after updating, and roll back if they detect a fatal error. That helps, but it doesn't cover updates you click yourself, theme updates, errors that only happen on certain pages, or updates that break a layout or a checkout without a fatal error. To learn how automatic updates work and how to control them, see our guide to WordPress automatic updates.

How to catch a critical error the moment it happens#

The real cost of a critical error is the time before someone notices. If it happens at 3 a.m. after an automatic update and the email goes to an unread mailbox, the site stays down until a customer complains.

A few habits shorten that gap:

• Use a real admin email address that someone reads, or set RECOVERY_MODE_EMAIL to one.
• Update safely. Update one plugin at a time, check key pages after each, and keep a backup. Our guide on how to safely update WordPress plugins covers the full routine.
• Check more than the homepage. Checkout, cart, contact and signup pages often break when the homepage doesn't.
• Monitor the pages automatically after every update.

The last point is what MyKavo does. Its WordPress plugin notes every plugin, theme and core update, including automatic ones, and every plugin activation, deactivation or theme switch. MyKavo then scans your monitored pages against an approved baseline and tells you whether anything changed. If a page starts returning an error after an update, the change is labelled with the update that came just before it, like "Appeared after: Updated WooCommerce 8.1.0 -> 8.2.0", so you know where to look before you open a single log file.

Update checks are included in every paid plan, from Starter at $7 a month. On the free plan, updates are still listed so you can see what changed and when. The plugin, free on WordPress.org, adds nothing to your public pages, because the scanning runs on remote servers, not yours.

A critical error usually comes with an HTTP 500 status, so for errors across the whole site, see our guide to the 500 internal server error too. If your site shows a blank page instead of the message, read our guide to the WordPress white screen of death.