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.
After 10+ years building WordPress sites and 950+ Fiverr client projects, here’s the first thing worth hearing: deactivating every plugin and praying is not troubleshooting. It usually works, sure, but it tells you nothing about why it happened, and the same error tends to come back in a few weeks. Actually fixing a WordPress critical error, and stopping it from coming back, means finding the cause, not just clearing the symptom.
What Actually Causes This Error
Three things cause almost every critical error:
- 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 a plugin author or theme update 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. This single step resolves a large share of critical errors before you ever need to touch a file. 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. This shows up 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. Regularly hitting memory limits is a sign the hosting plan is undersized for what’s running on it. Moving to better hosting beats raising the memory ceiling every few months.
Why This Keeps Happening to the Same Sites
The sites that break repeatedly all share one habit: they update plugins directly on the live site with no safety net. Every time someone clicks “update” on production, that’s a bet that the plugin author tested against that 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. The best WordPress backup plugin post walks through exactly which plugin to use for that, 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 gets installed in the first place. Every extra plugin is one more thing that can conflict during an update. A short, focused list of what actually belongs on new sites lives in this breakdown of the plugins worth installing on every new site, and trimming a plugin list down to what’s actually used cuts the 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 the site’s 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
Almost always a plugin update, a theme conflict, or the server running out of memory. In rare cases it’s a corrupted core file, but that’s uncommon compared to plugin and theme issues.
Yes. Since WordPress 5.2, a fatal error triggers an automatic email to the site admin with a recovery mode link that identifies the plugin or theme responsible. Check spam if you don’t see it in your inbox.
Edit wp-config.php through FTP or your host’s file manager and add define('WP_DEBUG', true); along with WP_DEBUG_LOG set to true and WP_DEBUG_DISPLAY set to false. Reload the page, then check /wp-content/debug.log for the exact error.
Yes. Theme updates and theme conflicts are the second most common cause after plugins. If disabling plugins doesn’t fix it, switch to a default theme like Twenty Twenty-Six temporarily to test whether your theme is the problem.
Test plugin and theme updates on a staging site before applying them to production, keep a real backup plugin running, and trim your plugin list to only what you actually use. Most repeat critical errors come from updating live sites with no safety net.
Leave a Reply