There has been a critical error on this website
WordPress's own fatal error handler. It caught a crash, replaced the page with this sentence, and told nobody except the admin email.
There has been a critical error on this website. Please check your site admin email inbox for instructions.
Check the admin email first - WordPress sends the file and line that failed, plus a recovery-mode link that lets you into wp-admin with the broken plugin paused. If that mailbox is unreachable, the same detail is in the debug log.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| A plugin fatal after an update | The error started with an update. The recovery email names the plugin outright. | Use the recovery link, deactivate the named plugin, and roll it back until its author ships a fix. |
| A PHP version the code does not support | The error arrived with a PHP switch rather than with a plugin update, and mentions a removed function or changed syntax. | Move back to the previous PHP version, update the offending code, then switch forward again. |
| A theme function calling something that is gone | Switching to a default theme restores the site. The named file lives under the theme directory. | Update the theme, or replace the call. Child themes carrying old snippets are the usual reason. |
| The admin email does not reach anybody | The error appears and no email arrives. The address is stale, or the site cannot send mail at all. | Read the debug log instead, and fix mail delivery separately - a site that cannot email you cannot tell you it is broken. |
| Two plugins that conflict only together | Each works alone; the site fatals with both active. Recovery mode names whichever loaded second. | Keep one, or find the version that resolves the conflict. Naming the second to load does not make it the guilty one. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Look in the admin mailbox first
WordPress sends the file, the line and a recovery-mode link. It is the fastest route back in.
wp option get admin_email
If no email arrived, read the log
The same detail, without depending on mail working.
wp config set WP_DEBUG_LOG true --raw tail -n 30 wp-content/debug.log
Get into wp-admin with the broken plugin paused
Recovery mode loads the dashboard with the offender disabled for your session only.
wp plugin list --status=active --field=name
Deactivate the plugin the log names
Confirm the site returns before deciding what to do about the plugin itself.
wp plugin deactivate the-named-plugin && wp option get siteurl
If PHP was switched recently, put it back
Restoring the version proves whether the switch caused it, which is worth knowing before editing code.
php -v
What the platform takes off the list.
Outgoing mail goes through a real provider rather than the server's own sendmail, so the recovery email actually arrives - which is the difference between a two-minute fix and an afternoon. PHP versions switch per site and switch back, cloning lets an update be tried on a copy first, and daily backups mean the version before the fatal is one restore away.
Questions, answered.
Why does the message not say what broke?
The recovery email never arrives.
What is recovery mode?
How is this different from a white screen?
If that was not it.
These fail in ways that look similar from the browser.