How to fix the WordPress critical error (There has been a critical error on this website)

Short answer

A few seconds after a plugin or theme update, WordPress sometimes shows one blunt sentence instead of your site: “There has been a critical error on this website.” This message is part of the fatal error protection system that shipped in WordPress 5.2,

and it replaced what used to be a blank white screen with at least some kind of signal.. The short answer: check your admin inbox first and use the recovery mode link WordPress sends you; if no email arrives, back up before touching anything, then disable plugins one at a time to isolate the cause.

What does “There has been a critical error on this website” mean?

The there has been a critical error on this website message means WordPress core has caught a fatal error in the code running your site and stepped in to stop the whole site from crashing outright. Before WordPress 5.2, the same situation produced a blank white page with no explanation at all. The fatal error protection layer introduced in 5.2 catches the error instead, shows visitors a short message, and sends the site administrator a detailed email notification. Seeing this message is, in a real sense, WordPress trying to help you rather than just failing silently.

Why does this error happen?

There’s no single cause, but in practice the list is short:

• A recently updated or installed plugin that’s incompatible with WordPress core or the current PHP version
• A syntax error in the theme’s functions.php file
• A PHP memory limit lower than the site actually needs
• Two plugins trying to modify the same functionality at the same time
• A sudden PHP version change on the server side

What these have in common is that the error almost always follows an update or a new plugin install, so the first question should always be “what changed most recently?”

First step: check your admin email (recovery mode)

The moment WordPress displays the there has been a critical error on this website message, it automatically emails the site’s administrator address. That email names the plugin or theme responsible and includes a unique, one-time link that opens the site in “recovery mode.” If you don’t see it in your inbox, check spam first, WordPress emails frequently land there, or never arrive at all, when the server isn’t configured with proper SMTP.

How does WordPress recovery mode work?

Clicking the recovery mode link gives you a special session without a normal dashboard login. The problem plugin or theme is temporarily paused in that session, so you can reach the Plugins screen and permanently deactivate or remove the one at fault. Once you’re done, remember to exit recovery mode from the link in the admin bar, otherwise that browser session keeps treating the plugin as paused.

No email? Back up before touching any files

If the recovery mode email never arrives, or you can’t log in at all, back up wp-content and the database via a file manager or FTP before going the manual route. This single step is what keeps a wrong move reversible while fixing there has been a critical error on this website by hand. Even with automatic hosting backups in place, copying the current state yourself takes a few minutes and removes the risk entirely.

Turn on debug mode and read debug.log

Open wp-config.php with FTP or your hosting file manager and add the following lines (or change existing false values to true):

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

Leaving WP_DEBUG_DISPLAY set to false matters: otherwise the error message becomes visible to every visitor on the live site. Instead, the error gets written to wp-content/debug.log, usually as a line starting with “Fatal error” that names the exact plugin file where things broke.

Disable plugins one by one

If debug.log doesn’t give a clear answer, the classic but reliable method is eliminating plugins one at a time. Using FTP or a file manager, go to wp-content/plugins and temporarily rename the folder (to something like plugins-old). WordPress can’t find the folder, so it treats every plugin as deactivated, and the site usually comes back. Rename the folder back, then reactivate plugins one by one from the dashboard, checking the site after each one. Whichever plugin brings the error back is the culprit.

Switch to a default theme and test

If the plugins check out clean, the theme is next. If wp-content/themes doesn’t have a current default WordPress theme (like Twenty Twenty-Four), download and install one, then temporarily add this line to wp-config.php:

Define( 'WP_DEFAULT_THEME', 'twentytwentyfour' );

If the site comes back, the active theme is the problem, most likely a functions.php broken by an update, or an incompatible theme plugin.

Check your PHP memory limit

Sometimes there has been a critical error on this website appears with no plugin or theme fault at all, simply because PHP can’t allocate the memory the site needs. Raise the limit by adding this line inside wp-config.php:

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

On shared hosting plans, this can sometimes conflict with the server’s own global PHP limit. If so, raise the PHP memory value from your hosting control panel instead, or ask support to do it.

How is this different from the white screen and the 500 error?

All three errors share similar root causes, plugin/theme incompatibility, PHP limits, but surface at different layers. The WordPress white screen of death is the blank page with no message at all, seen before WordPress 5.2 or whenever the fatal error protection layer is disabled. The WordPress 500 Internal Server Error usually happens before WordPress code even starts running, at the server or .htaccess layer. There has been a critical error on this website sits between the two. WordPress has started running but hit a fatal error in the PHP layer, which is why you get both a visible message and a recovery mode email.

Should you disable recovery mode?

Developers managing many sites, or running their own error-monitoring stack, sometimes find recovery mode emails redundant. Rather than disabling the whole fatal error protection system, it’s possible to turn off just the handler by setting the WP_DISABLE_FATAL_ERROR_HANDLER constant to true. Only do this once you have an alternative error-monitoring or logging setup in place, though, or you’ll get no warning at all the next time a critical error hits.

When to contact your hosting provider

If none of the steps above work, the cause is likely server-side: a resource quota, a corrupted system file, or a server configuration issue. At this point, contacting your hosting provider’s technical support with a clear account of what you’ve tried and what debug.log shows gets the issue resolved faster.

Avoiding it again

There has been a critical error on this website is generally a preventable problem. Testing plugin and theme updates on a staging environment first, keeping a regular and accessible backup routine, removing unused plugins, and keeping your PHP version within the supported range all significantly reduce the odds of hitting it again. For the official background on how WordPress built the recovery mode feature, see the WordPress core team’s 5.2 announcement.

Next step

WordPress’s there has been a critical error on this website message, handled in the right order, is usually fixable through the recovery mode email alone, with no file editing at all. For server-side or recurring cases, though, getting professional help is the safer choice for both time and data security. If you’re weighing whether your WordPress site’s technical maintenance needs hardening against critical errors, or whether it’s time to move to a more resilient architecture, our group company Web Tasarım Ofisi supports WordPress setup and technical troubleshooting.

To discuss your site’s technical infrastructure or custom software needs, explore our custom software service or contact Argo Ajans.