If your site is showing the message “There has been a critical error on this website” in WordPress, take a breath — it’s rarely as bad as it sounds. This is WordPress’s polite way of saying a plugin, theme, or bit of code hit a fatal error and it stopped loading the page rather than show a broken half-site. Your content is still in the database, untouched. Something just needs to be switched off or fixed. This guide walks through it in order, starting with the easiest route WordPress hands you for free.
You may also see a longer version: “There has been a critical error on this website. Please check your site admin email inbox for instructions.” That extra sentence is the important clue, and it’s the reason this problem is different from a plain white screen of death — the blank page gives you nothing, while this one is actively trying to help you.
Step 1: Check the admin email inbox
Since WordPress 5.2, when a fatal error happens WordPress emails the site’s admin address automatically. That email tells you exactly which plugin or theme caused the crash — no guessing — and includes a special link into “Recovery Mode.” Open the inbox for the email address set under Settings, General (it’s the one you used when the site was built), and look for a message with a subject like “Your Site is Experiencing a Technical Issue.”
If you find it, you’ve likely just found your culprit named in plain English. Click the recovery link and skip to the next step.
Step 2: Use Recovery Mode to disable the culprit
The recovery link logs you into a special version of your dashboard that loads even though the front end is broken. In Recovery Mode, WordPress flags the exact plugin or theme that failed. Go to it, deactivate it, and your site should come straight back. From there you can find a replacement, roll back the plugin to an earlier version, or wait for its developer to ship a fix. When you’re done, click “Exit Recovery Mode.”
Recovery Mode is genuinely the fastest fix here, which is why it’s worth checking that inbox before touching a single file.
Step 3: No email? Turn on the error log
If the email never arrives — often because the site was never set up to send mail reliably, a problem in its own right — you’ll need to read the error yourself. Open your wp-config.php file (WordPress’s main settings file) over SFTP (a secure way to connect to your site’s files) or your host’s file manager and find define('WP_DEBUG', false);. Replace it with:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Reload the page, then open wp-content/debug.log. The last few lines will usually name the exact file that failed — something like “Fatal error… in /wp-content/plugins/some-plugin/file.php.” That one line points straight at the problem. Set WP_DEBUG back to false when you’re finished so errors aren’t logged forever.
Step 4: Deactivate plugins
Plugins are the most common cause of a fatal error, especially right after an update. If you can reach your dashboard, deactivate all of them, then reactivate one at a time, reloading the site after each until the error returns — that’s your bad plugin.
If the critical error has locked you out of the dashboard entirely, do it over SFTP: rename the wp-content/plugins folder to plugins-off. That switches off every plugin at once. If the site loads, rename the folder back to plugins (your plugins are all still there, just deactivated) and re-enable them one by one to find the offender.
Step 5: Switch to a default theme
If plugins aren’t to blame, a theme is the next suspect — particularly if someone recently edited functions.php, where a single misplaced character will crash the whole site. Switch temporarily to a stock theme like Twenty Twenty-Four. Locked out? Rename your active theme’s folder in wp-content/themes over SFTP and WordPress falls back to a default theme on its own. If the site returns, the theme was it.
Step 6: Give it more memory
Some fatal errors are really “out of memory” errors in disguise — the page tried to do more than its memory allowance permitted and PHP (the programming language WordPress runs on) killed it. Add this to wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
If that clears it, take note: a site that keeps bumping the ceiling is being squeezed by an underpowered plan. Our guide on how to increase the PHP memory limit covers the details and the other places the limit can be set.
Step 7: Rule out a PHP version mismatch
A critical error that appears “out of nowhere” sometimes follows a PHP version change on the server, which can break older plugins or themes that weren’t written for it. If the error started after a host-side PHP update, check the log for a version-related message. This overlaps with the wider 500 internal server error, which has the same family of causes.
When the fix is really the host
Notice how many of these paths — a fatal update, a low memory ceiling, a PHP version bumped without warning, an admin email that never sends — trace back to how a site is hosted, not to anything you did wrong. On bargain shared hosting, updates run unsupervised, memory is capped low to pack more sites onto one server, and nobody is watching when a plugin update takes the site down at 2am.
That’s the everyday difference with managed WordPress hosting. Every time we update your site, we verify it still looks and works right, so a bad plugin update gets caught and rolled back before it ever throws a critical error on your live site. Plans include generous memory so the ceiling isn’t a daily fight, and there’s a real US-based team on the other end when something does go sideways — predictable, straightforward pricing whether your site is a five-page brochure or a growing store, because the care is the point, not a meter.
If you’re stuck: restore a working copy
If you can’t find the cause, or an edit made things worse, stop and restore. A recent clean backup returns your whole site to the last moment it worked — no detective work. Our guide on how to restore WordPress from a backup walks through it, and every plan we run keeps off-site backups 3 times a day that are monitored and locked for 90 days against changes or deletion, even by ransomware, so a clean copy is always within reach.
The short version
- Check the admin email inbox for the Recovery Mode link.
- Use Recovery Mode to disable the named plugin or theme.
- No email? Turn on
WP_DEBUG_LOGand readdebug.log. - Deactivate plugins (rename the folder if you’re locked out).
- Switch to a default theme.
- Raise the memory limit; rule out a PHP version change.
- Still stuck? Restore from a clean backup.
If the critical error won’t clear — or you’d rather not be editing live config files while your business is offline — hand it over. This is routine work for our US-based team, and if it keeps recurring, moving to hosting with real resources and verified updates usually ends it. For the neighboring symptoms, see our 500 internal server error fix and our guide to the white screen of death.