Introduction
You open your site and instead of your homepage there’s a single, unhelpful sentence: “There has been a critical error on this website. Please check your site admin email inbox for instructions.” No details, no button, and often wp-admin shows the same message. It looks catastrophic — but your content is safe, and in most cases the fix takes just a few minutes.
Here’s what the error actually means, and five ways to fix it — starting with the easiest.
What This Error Actually Means
Behind the friendly wording, a PHP fatal error crashed your site. Some piece of code — almost always a plugin, your theme, or code that’s incompatible with your PHP version — failed in a way WordPress couldn’t recover from, so it stopped everything and showed this message instead. The vast majority of cases trace back to one of three triggers: a plugin or theme you just installed or updated, a PHP version change on your server, or an exhausted memory limit.
The message mentions your inbox for a good reason — and that’s where the easiest fix lives.
Fix 1: Use the Recovery Mode Email
When a fatal error happens, WordPress emails the site admin address with the subject “Your Site is Experiencing a Technical Issue.” That email contains two valuable things:
- The name of the plugin or theme that caused the crash — WordPress identifies it for you.
- A special Recovery Mode link. Click it, log in, and WordPress loads with the broken component paused, so you can deactivate it normally from the dashboard.
Check spam too. If you found the email, deactivate the culprit, and you’re done. If there’s no email (or you can’t receive mail from your site — a common problem of its own), continue below.
Fix 2: Find the Exact Cause with the Debug Log
Instead of guessing, you can make WordPress tell you exactly which file crashed. Open wp-config.php in your site’s root folder (via FTP or your host’s File Manager) and add these lines just above /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reload your broken site once, then open wp-content/debug.log. The last lines show the fatal error and the file path that produced it — if the path contains /plugins/some-plugin/ or /themes/your-theme/, you’ve found your culprit. Remember to set WP_DEBUG back to false when you’re done.
Fix 3: Deactivate All Plugins Manually
If you can’t get into wp-admin at all, deactivate plugins from the outside:
- Connect via FTP or your host’s File Manager.
- Go to
wp-contentand rename thepluginsfolder toplugins-old. - Reload your site. If it comes back, a plugin caused the crash.
- Rename the folder back to
plugins— all plugins will now be deactivated but still installed. - Log in to wp-admin and reactivate them one at a time, reloading the site after each, until you find the one that breaks it.
Fix 4: Switch to a Default Theme
If plugins weren’t the cause, test the theme the same way: in wp-content/themes, rename your active theme’s folder. WordPress automatically falls back to a default theme (like Twenty Twenty-Five) if one is installed. If the site comes back, the crash lives in your theme — often in functions.php after a recent edit.
Fix 5: Check PHP Version and Memory
If the debug log mentions Allowed memory size exhausted, follow our guide to raising the WordPress memory limit. If it mentions syntax or function errors right after a hosting change, your PHP version may have jumped — most hosts let you switch PHP versions in the control panel; try stepping back to the previous version and updating the incompatible plugin before switching forward again.
How to Avoid It Next Time
- Back up before every update. A before-update backup turns a broken site into a one-click rollback instead of an afternoon of debugging.
- Update in small batches, so you always know which change broke things.
- Test big changes on staging. PHP version jumps and major plugin upgrades are safest rehearsed on a staging site.
Frequently Asked Questions
Is my content gone?
No. Your posts, pages, and media are stored in the database and untouched. The error only means PHP code crashed while rendering the site.
I never received the recovery email — why?
Either your site can’t send mail (see why WordPress isn’t sending emails), or the admin email on file is outdated. The manual fixes above work without the email.
The error appeared without me changing anything — how?
Automatic plugin updates, a PHP version change by your host, or a plugin conflict triggered by new data can all crash a site nobody touched. The debug log will still point to the culprit.
What if wp-admin works but the front end shows the error?
That usually points at the theme or a front-end-only plugin (like a page builder). Fix 4 is the fastest test.
Conclusion
“There has been a critical error on this website” is WordPress’s polite way of saying a plugin, theme, or PHP setting crashed — not that your site is lost. Check the recovery email first, use the debug log to identify the exact cause, and deactivate the culprit via FTP if you’re locked out. With a recent backup on hand, even the worst case is a rollback, not a rebuild.
Never debug at midnight again
Nota Backup & Restore takes an automatic snapshot before every update and can restore your site even when wp-admin is unreachable. Start your 14-day free trial — no credit card required.
