All guides
Troubleshooting guide Critical Errors

How to Fix 'There Has Been a Critical Error on This Website' in WordPress

A practical guide to the WordPress 5.2+ 'critical error on this website' message, Recovery Mode emails, and matching the error ID to your debug.log.

Arjun Mehta Published June 20, 2026 Last reviewed June 20, 2026 10 min read Step-by-step walkthrough
Reviewed and tested by the WPRescue team on a real WordPress install before publishing. How we test fixes
WordPress Health Check & Troubleshooting Recovery Mode screen

What's Happening

WordPress 5.2 introduced a friendlier but still terrifying message: 'There has been a critical error on this website.' The page is down, but the site is trying to email you a recovery link that contains an error ID. That ID, plus the debug log, is your fastest path back online.

The first time you see 'There has been a critical error on this website' it feels like the worst-case scenario. It is not. WordPress introduced this message in version 5.2 specifically to be less scary than the old white screen of death, and more importantly, it now emails the site admin a recovery link.

Over the last few years, this screen has become the most common way clients discover their site is broken. The good news is that the message is a gateway, not a dead end. The recovery email contains an error ID, and that ID is the key to matching the crash to a real line in your debug.log.

This guide walks through the exact process I use when a client forwards me that WordPress email. We will cover how to read the email, what to do when the email never arrives, how to enable the error log, and how to cross-reference the error ID with the file path that actually broke the site. By the end, you will have a repeatable recovery plan.

What the WordPress 5.2 Critical Error Message Means

Before WordPress 5.2, a fatal PHP error produced a blank white page or a raw stack trace. Since 5.2, WordPress catches the fatal error and shows a clean message: 'There has been a critical error on this website.' Behind that screen, it tries to email the site administrator with a Recovery Mode link.

The message is a safety net. It means PHP could not finish loading the page, but WordPress is still partially functional enough to log the failure and send a notification. The goal is to get you back into wp-admin without exposing the raw error to visitors.

Step 1: Check Your Admin Email for Recovery Mode

Within minutes of the crash, the site administrator email should receive an email with the subject 'Your Site is Experiencing a Technical Issue' or similar. The body contains a link to Recovery Mode. Click that link as soon as possible because the token inside it expires after a set period, usually a few hours.

The link looks like https://yoursite.com/wp-login.php?wp-recovery-mode=safe-XXXX, where the random string after the equals sign is the error ID. Keep that ID handy. It is the bridge between the email and the line in your debug.log.

textExample Recovery Mode URL. The token after the equals sign is the error ID.
https://yoursite.com/wp-login.php?wp-recovery-mode=safe-abc123xyz

Step 2: Turn On the Error Log

Even if the email arrived, you still need to see the actual error. The recovery link tells you which component WordPress suspects, but the log tells you the exact file and line. Edit wp-config.php through FTP or your hosting file manager and add the standard debug constants above the 'stop editing' line.

phpProduction-safe logging. Errors are written to /wp-content/debug.log without showing them to visitors.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Step 3: Reproduce the Critical Error and Read the Log

After enabling the log, reload the broken page once. WordPress writes the most recent fatal error to the bottom of /wp-content/debug.log. Each line includes a timestamp, the error type, the message, and a file path with a line number. The path almost always contains the plugin or theme folder responsible.

textA typical fatal error line. The plugin folder is at /wp-content/plugins/broken-plugin/.
[20-Jun-2026 14:32:01 UTC] PHP Fatal error: Uncaught Error: Call to undefined function my_custom_function() in /home/site/public_html/wp-content/plugins/broken-plugin/loader.php:27

Step 4: Match the Error ID to the Log Entry

If the error ID from the Recovery Mode link appears in the log, you can be certain you are looking at the right entry. In some logs, the Recovery Mode system includes the error ID in the debug line. If not, use the timestamp, the file path, and the fact that the newest fatal error is the one that caused the critical error screen.

Once you know the component, you have three options: update it, replace it with an alternative, or remove it. I rarely patch third-party code directly. A clean swap is safer and faster than editing someone else's plugin on a live server.

Step 5: Recover When the Email Never Arrives

If the email is blocked by your host or goes to an old address, you can still recover the site manually. The fallback method is the same one I use for the white screen of death: disable all plugins, switch to a default theme, and re-enable components one by one.

  • Connect via FTP or your host's file manager.
  • Rename /wp-content/plugins to /wp-content/plugins-off.
  • Reload the site. If it works, rename the folder back and deactivate plugins one by one in wp-admin.
  • If the issue persists, rename /wp-content/themes/your-theme to force a default theme.
  • Check debug.log after each change to confirm the fatal error is gone.

Step 6: Fix the Broken Component and Prevent Recurrence

After you identify the plugin or theme, look for an update, a support thread, or a replacement. If the issue started after an update, rolling back to the previous version can buy you time while the developer fixes the bug. Once the site is stable, disable WP_DEBUG and delete the debug.log so the next error is easy to spot.

  • Update the plugin or theme to the latest version.
  • If the update caused it, use WP Rollback to return to the previous version.
  • Replace the component if it is abandoned or repeatedly causes fatal errors.
  • Test updates on a staging copy before applying them to the live site.

Complete Fix Checklist

  1. 1Check the admin email address for a WordPress Recovery Mode email from WordPress with a link ending in ?wp-recovery-mode=...
  2. 2If the email did not arrive, enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php and reproduce the error.
  3. 3Open /wp-content/debug.log and find the most recent PHP Fatal error that matches the timestamp of the crash.
  4. 4Match the error ID from the Recovery Mode link to the line in the log if available, or use the file path and line number in the log to find the failing plugin or theme.
  5. 5Rename the culprit plugin or theme folder via FTP to restore access, then update, replace, or contact the developer.

Quick Tips

  • Recovery Mode links expire after a set time, so use the email quickly or generate a new crash to trigger a new email
  • Some hosts block WordPress emails, so check spam and your host's mail log before assuming the email failed
  • You can also recover by renaming /wp-content/plugins if the email never arrives

Frequently Asked Questions

Why did WordPress start showing this message?
WordPress 5.2 added a fatal error handler that displays the 'There has been a critical error on this website' screen instead of a blank white screen. It also sends a Recovery Mode email to the site admin so the error can be diagnosed without the admin area going down too.
What is the Recovery Mode email link for?
The link contains a temporary token that pauses the broken plugin or theme long enough for you to log into wp-admin. Once inside, WordPress shows you which component caused the fatal error and lets you deactivate it from the dashboard. The token expires after a few hours, so use it promptly.
I never received the email. What now?
Check spam, confirm the admin email at Settings > General, and verify your host is not blocking wp_mail. If email cannot be fixed, recover manually: rename /wp-content/plugins via FTP, switch to a default theme, and enable WP_DEBUG_LOG to find the fatal error.
How do I match the error ID to the debug log?
The error ID appears in the Recovery Mode link. After enabling WP_DEBUG_LOG, reproduce the error and look at the bottom of /wp-content/debug.log. The most recent fatal error line will show the same timestamp, and often the same error ID, plus the file path and line number of the failing code.
Can I just disable all plugins?
Yes. Renaming /wp-content/plugins to /wp-content/plugins-off via FTP will disable all plugins and usually bring the site back. Then rename the folder back and reactivate plugins one by one to find the culprit. This is the fallback method when Recovery Mode is not available.
Will this error break my database?
No. The critical error is a PHP fatal error that stops the page from rendering. It does not corrupt your database, posts, or media. Once you remove the broken component, the site usually returns to normal.

Related Guides