“There has been a critical error on this website”
It's the least informative sentence in WordPress and one of the most common. Here is what is actually happening, where the real message is hiding, and the order to work through it without destroying the evidence.
That sentence is WordPress being polite. Underneath it, PHP hit a fatal error and stopped, and WordPress caught the failure and put up a holding page rather than showing your visitors a stack trace. The page is deliberately vague because anything more specific would leak information about your server.
Which is reasonable, and also unhelpful when it's your site and you need to know what happened. The good news is that the real message almost always exists. It's just not on the screen.
First, do nothing
The most common way this gets worse is somebody immediately deleting plugins, reinstalling a theme, or restoring a backup from last week to make the error go away.
All three destroy the record of what happened. Worse, a backup restore rolls back your database too, so any orders, form submissions, comments or content created since that backup are gone. People routinely trade a two-hour problem for a permanent one in the first ten minutes.
Check the email WordPress already sent you
Since version 5.2, WordPress emails the site administrator when it catches a fatal error. That email frequently names the exact plugin or theme file that failed, and it includes a special recovery mode link that logs you in with the offending component disabled.
It goes to the administration email address in Settings, which on a lot of sites is an address nobody has checked since the site was built. Check it, and check the spam folder. On a meaningful number of the calls we get about this error, the answer is sitting unread in an inbox.
Then read the actual error
The real message is in a log file. Where it lives depends on the host, but the usual candidates are an error_log file in the site root or the wp-content directory, or a PHP error log available in your hosting control panel.
If nothing is being logged, you can turn logging on by editing wp-config.php. Add these lines above the comment that says to stop editing:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
That writes errors to wp-content/debug.log without showing them to visitors, which matters: WP_DEBUG_DISPLAY set to true on a live site prints file paths and sometimes database detail to anybody who loads the page. Reload the site once to generate the error, then read the log, then turn debugging back off.
What you're looking for is a line containing PHP Fatal error or PHP Parse error. Both matter: a broken edit to a PHP file produces the second, not the first, so searching only for the word fatal will miss the single most common cause. The line names a file and a line number, and the file path usually tells you immediately whether the culprit is a plugin, the theme or core.
What the common messages mean
| What the log says | What it usually means |
|---|---|
Allowed memory size | PHP ran out of memory. Often a plugin doing something large, sometimes a memory limit set too low by the host. Raising the limit is a valid step and isn't always the real fix. |
Call to undefined function | Code is calling something that no longer exists. Classic after a partial update, or when a plugin depends on another plugin that has been deactivated. |
Cannot redeclare | The same function is defined twice. Usually two plugins conflicting, or a plugin installed twice under different folder names. |
syntax error, unexpected | Somebody edited a PHP file and left it invalid. Very common after an edit made directly in the WordPress theme editor. Logged as a parse error rather than a fatal one. |
Uncaught Error: Class … not found | An autoloader or a dependency is missing. Frequently an interrupted update that left files half written. |
Maximum execution time | Something took too long. Often an import, a large query, or a call to a third party service that's not responding. |
Common fatal error messages in WordPress and their usual causes
Work out what changed
Fatal errors don't appear spontaneously. Something was different before it started, and it's usually one of a short list:
- A plugin, theme or core update, whether you clicked it or an automatic update did
- A PHP version change made by your host, often with notice nobody read
- A file edited directly, whether through the WordPress editor or over FTP
- A license that expired, which normally stops updates rather than the plugin, but occasionally disables something other code depended on
- A full disk, which causes failures that look nothing like disk problems
- A plugin deactivated by somebody else, breaking a dependency
Your host's update log, the WordPress update history and file modification timestamps will usually identify the change within a few minutes.
Isolating a plugin conflict, carefully
The standard advice is to deactivate all plugins and reactivate them one at a time. It works, and on a live site it means your visitors watch the debugging happen.
Better options, in order of preference:
- Use the recovery mode link from the fatal error email. It pauses the failing component for your session so you can get into the admin. Visitors still see the error page until you actually deactivate or fix it, but you're diagnosing from a working dashboard rather than from a broken site.
- Work on a staging copy, if you have one. Break things there instead.
- If you must work live, rename the single plugin directory named in the error log rather than disabling everything. That is a targeted change rather than taking the whole site's functionality offline.
When it's not the application at all
Two situations look identical from the browser and aren't WordPress problems.
If the site is genuinely unreachable rather than showing the WordPress error page, the problem may be DNS, an expired domain, an expired certificate or a server that's not responding. Those need checking before you touch anything inside WordPress, because no amount of plugin work will fix them.
And if the error is intermittent, appearing for some visitors and not others, look at caching before you look at code. A cached copy of a broken page will keep being served long after the underlying problem is fixed.
After it's fixed
The useful question isn't what broke, it's why it was able to. A site that throws a fatal error from a routine update is usually telling you something about how it's maintained rather than about the specific plugin involved.
The things that actually reduce the frequency of this are unglamorous: updates applied on a staging copy first, a backup you've actually tested restoring, fewer and better maintained plugins, a supported PHP version, and the file editor turned off. None of them are interesting and all of them work.
