How to Fix a WordPress Critical Error (Without Losing Your Site)

Your site is down. Instead of your homepage, visitors see one line: “There has been a critical error on this website.” No details, no hint of what broke, just a dead page where your business used to be.

I’ve fixed this exact error more times than I can count across 950+ client projects, and here’s the first thing I need you to hear: deactivating every plugin and praying is not troubleshooting. It usually works, sure, but it tells you nothing about why it happened, and you’ll be back here in three weeks when it happens again. If you want to actually fix a WordPress critical error, and stop it from coming back, you need to find the cause, not just clear the symptom.

What Actually Causes This Error

In my experience, three things cause almost every critical error I’ve been called in to fix:

• A plugin update that changed a function name or dropped support for your PHP version
• A theme conflict, usually after switching themes or updating one without testing on staging first
• The site running out of memory, which looks identical to a plugin crash but has a completely different fix

Notice none of those are “WordPress broke.” WordPress core rarely causes this on its own. It’s almost always something you or a plugin author changed. That distinction matters, because it tells you where to look first.

Check Your Email Before You Touch Anything

Most people skip this step, and it’s the one that saves the most time. Since WordPress 5.2, the platform has a built-in recovery mode. When a fatal error happens, WordPress emails the site admin with a link that names the exact plugin or theme that broke and lets you disable just that one thing, without touching anything else.

Check the inbox tied to your WordPress admin account, including spam. If the email is there, click the recovery link, disable the flagged plugin, and you’re done in under two minutes. I’d say this resolves close to half the critical errors I get asked about. No file editing, no guesswork.

If There’s No Email: Turn on Debug Mode

No email, or the link already expired? Next step is turning on WordPress debug logging so the site tells you exactly what’s failing instead of showing a blank error. Connect to your site with FTP or your host’s file manager and open wp-config.php. Add this 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, then open /wp-content/debug.log. It’ll show the exact file and line number where the error happened, usually pointing straight to a specific plugin folder. That’s your culprit. Deactivate it through FTP by renaming its folder inside /wp-content/plugins/, and the site should come back immediately.

Once you’re done troubleshooting, turn WP_DEBUG back to false. Leaving it on exposes error details to anyone who knows where to look, which is a security risk, not just clutter.

When It’s a Memory Limit, Not a Plugin

If your debug log shows “Allowed memory size exhausted,” that’s not a broken plugin, it’s your host giving your site less memory than it needs to run everything installed on it. I see this constantly on cheap shared hosting once a site picks up a page builder, an SEO plugin, and a caching plugin at the same time.

You can raise the limit temporarily by adding this to wp-config.php:

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

But treat this as a patch, not a fix. If you’re regularly hitting memory limits, your hosting plan is undersized for what you’re running. I’d rather move a client to better hosting than have them raise the memory ceiling every few months.

Why This Keeps Happening to the Same Sites

After a decade of getting these emergency calls, I’ve noticed the sites that break repeatedly all share one habit: they update plugins directly on the live site with no safety net. Every time you click “update” on production, you’re gambling that the plugin author tested against your exact combination of theme, PHP version, and other plugins. Sometimes that bet doesn’t pay off.

The fix isn’t to stop updating, outdated plugins are a bigger security risk than a broken update. The fix is testing updates on a staging site first, so if something breaks, it breaks somewhere nobody’s watching. It also helps to keep a real backup running in the background. I’ve walked through exactly which plugin I use for that in my post on the best WordPress backup plugin, and having a recent backup turns a critical error from a crisis into a five-minute restore.

It’s also worth being deliberate about what you install in the first place. Every extra plugin is one more thing that can conflict during an update. I keep a short, tested list of what actually goes on new sites in this breakdown of the plugins I install on every new site, and trimming your plugin list down to what you actually use cuts your odds of hitting this error again.

The Bottom Line

A WordPress critical error looks scary, but it’s rarely catastrophic. Check your email for the recovery link first, turn on debug logging if that link isn’t there, and once you’re back up, fix the actual habit that caused it: testing on staging and keeping real backups. Do that, and this becomes a five-minute annoyance instead of a full day of panic.

Frequently Asked Questions