Fix 'There Has Been a Critical Error' in WordPress

You update a plugin, refresh the page, and instead of your site you get one flat sentence: "There has been a critical error on this website." No stack trace, no line number, nothing to Google except that exact phrase — which half of WordPress has seen at some point. Here's how to actually find out what broke and get the site back, step by step.

Symptom: What You're Looking At

This message is different from a blank white screen. It's WordPress's own built-in fatal error handler, introduced in WordPress 5.2, and it shows up when PHP hits a fatal error but WordPress core is still functional enough to catch it and print something readable instead of a raw 500 page. You'll usually see one of these:

• The front end shows the critical error message, but wp-admin still loads fine.
• Both the front end and wp-admin show it — usually means a plugin that runs everywhere (security plugin, caching plugin, SEO plugin) is the culprit.
• You get an email from your own site titled "Your Site is Experiencing a Technical Issue," with a link to enter Recovery Mode.

If you never got that email, check your spam folder or the admin email set under Settings → General — WordPress only sends it once per issue, so if you already dismissed it you won't get a second copy for the same error.

Cause: Why WordPress Shows This Instead of Just Breaking

Under the hood it's the same root cause as a classic White Screen of Death — a PHP fatal error stopped execution. The difference is WordPress core wraps the request in a try/catch since 5.2, so instead of a blank page or raw Apache/Nginx 500 error, you get this friendlier (if useless-looking) message. Typical triggers:

• A plugin update that isn't compatible with your PHP version — common after a host bumps PHP 7.4 → 8.1, or after an EasyApache/MultiPHP change in cPanel.
• Two plugins declaring the same function or class name, or a plugin calling a function from another plugin that's now deactivated.
• A theme's functions.php with a typo or a leftover snippet from a code editor that wasn't tested.
• A corrupted file from an interrupted update — connection dropped mid-save, disk quota hit during the update, etc.
• Memory exhaustion mid-request, which sometimes gets caught by this handler instead of showing the usual "Allowed memory size exhausted" text.

Fix: Three Ways In, Depending on What You Have Access To

Option 1 — Recovery Mode (fastest, no file access needed)

If you got the "Technical Issue" email, click the "Recovery Mode" link inside it. This logs you into wp-admin in a special mode where the plugin or theme that's causing the fatal error is auto-paused, so you can get back into the dashboard and deactivate it properly from the Plugins screen. The link is valid for a limited time and tied to that specific error, so use it before it expires.

Option 2 — Turn on debugging to see the real error

Connect via File Manager in cPanel or SFTP, open wp-config.php, and add these lines just above the line that says /* That's all, stop editing! */:

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

Reload the broken page once, then open wp-content/debug.log in File Manager. The most recent entry will name the exact file and line where the fatal error happened — usually something like:

PHP Fatal error:  Uncaught Error: Call to undefined function some_function() in /home/user/public_html/wp-content/plugins/some-plugin/file.php:42

That tells you exactly which plugin folder to deal with. Once you're done, set WP_DEBUG back to false — leaving it on with WP_DEBUG_DISPLAY set to true exposes file paths to anyone who hits an error on the live site.

Option 3 — Disable plugins manually via File Manager or SFTP

No admin access at all? You can still fix this without ever logging into wp-admin:

1. Go to File Manager → public_html/wp-content/plugins in cPanel (or connect over SFTP).
2. Rename the plugin folder you suspect — e.g. some-plugin → some-plugin-disabled. WordPress can't find an inactive-looking folder and will simply skip loading it.
3. Reload the site. If it comes back, that plugin was the problem — rename the folder back, then either update it, replace it with a fresh copy from wordpress.org, or leave it deactivated and update from the Plugins screen once you're back in.
4. If renaming one plugin folder doesn't fix it, rename the whole plugins folder to plugins-off, recreate an empty plugins folder, then move plugin folders back in one at a time, reloading between each, until the error returns — that one is your culprit.

If the site still breaks with every plugin folder empty, the problem is in your active theme. Rename its folder the same way — WordPress falls back to a default theme automatically if the active one is missing.

Prevention: Stop This From Happening Again

• Update one plugin at a time on anything but a low-traffic site, especially after a WordPress core or PHP version change — bulk-updating five plugins at once makes the culprit much harder to find later.
• Use a staging site before applying major updates. If your plan includes cPanel staging tools, clone the site, test the update there first.
• Keep PHP version pinned deliberately in MultiPHP Manager rather than letting it drift, and check a plugin's "Tested up to PHP" note before updating if you're near a major PHP version.
• Take a backup before big updates. If JetBackup or a similar tool is available in cPanel, a quick on-demand backup before a plugin or core update means "restore and try again later" is always an option.
• Watch disk quota. An update that runs out of space mid-write can corrupt a plugin file even if the plugin itself was fine — check quota in cPanel before pushing a big update.

Frequently Asked Questions

Is "There has been a critical error on this website" the same as the White Screen of Death?

They share the same root cause — a PHP fatal error — but this message is WordPress's own error handler catching it and printing readable text, while a classic WSOD is a completely blank page with nothing printed at all. Both are fixed the same way: find and isolate the plugin, theme, or code causing the fatal error.

I didn't get the "Technical Issue" recovery email — why not?

WordPress sends it to the admin email under Settings → General, and only once per distinct error to avoid spamming you. Check spam, check that the admin email address is actually valid and reachable, and if you already dismissed a previous recovery link for the same error, use File Manager or debug.log instead — you won't get a second one.

Can I just restore a backup instead of debugging this?

Yes, and if you have a recent backup and no urgent need to keep whatever change triggered the error, that's often faster. But if the same plugin update triggered the error and you restore without addressing it, running that update again will break the site the same way — so either skip that update or fix the underlying incompatibility first.

Will turning on WP_DEBUG on a live site expose errors to visitors?

Only if WP_DEBUG_DISPLAY is also set to true. Keep it false and set WP_DEBUG_LOG to true instead — errors get written quietly to wp-content/debug.log without ever appearing on the public page.

How do I know which plugin to blame if there are dozens?

The debug.log entry names the exact file path, which includes the plugin's folder name — that's the fastest route. If debug logging isn't showing anything useful, the folder-rename method (moving all plugins out, then back in one at a time) is slower but always works, since it doesn't depend on PHP producing a readable error message.