What the message actually means
Since WordPress 5.2 there's a fatal error handler. When PHP crashes, WordPress catches it, shows this message instead of an empty page, and emails the administrator a recovery link. So this error is genuinely better news than the white screen — the information you need has already been collected for you.
Check your email first
Search your inbox and spam folder for "Your Site is Experiencing a Technical Issue". That email contains a login link that works even when the site is down, and it names the exact plugin or theme that crashed. If it's there, you're ninety percent done.
1. Use recovery mode
Click the link in that email. It logs you into wp-admin in recovery mode with the failing component paused, so you can deactivate it, update it, or replace it normally. Once you've fixed things, click "Exit Recovery Mode".
No email? The admin address may be wrong, or your server may not be sending mail at all — which is very common on cheap hosting. Move to the debug log.
2. Read the actual error
Add to wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Reload the site, then open wp-content/debug.log and find the last
PHP Fatal error: line. It gives you the message, the file, and the line number.
3. Interpret what you're reading
| Error message contains | What it means | Fix |
|---|---|---|
Call to undefined function | Code calling something that doesn't exist — usually a missing PHP extension or a removed function | Enable the extension, or update the plugin |
Class "X" not found | Missing dependency, or an incomplete update left files behind | Reinstall the plugin cleanly |
Allowed memory size exhausted | PHP ran out of memory | Raise WP_MEMORY_LIMIT, then find what's consuming it |
syntax error, unexpected | Code invalid for this PHP version — or someone edited a file badly | Check PHP version compatibility; restore the file |
Cannot redeclare | Two plugins defining the same function name | Deactivate one of them |
Maximum execution time exceeded | A process is hanging, often an external API call | Raise the limit temporarily, then fix the slow call |
4. The PHP version trap
This deserves its own section because it causes so many "I changed nothing" cases. Hosts upgrade PHP automatically. If a plugin or theme uses syntax or functions removed in the new version, it fatals the instant the upgrade lands — and from your side, nothing changed.
Check your host's control panel for the current PHP version and whether it changed recently. If it did, roll back to the previous version to get the site up, then update the incompatible component properly before switching forward again. Rolling back is a temporary measure, not a solution — old PHP versions stop receiving security patches.
5. Disable the failing component
If you can't reach wp-admin at all, do it over SFTP. Rename the plugin's folder inside
wp-content/plugins/, or rename your theme's folder to force a default theme. The site comes
back, and you can work on the real fix without being under outage pressure.
Error message you can't decode?
Send me the line from debug.log. Most critical errors resolve in well under two hours — and you don't pay if I can't fix it.
FAQ
What does the critical error actually mean?
PHP hit a fatal error and stopped. Since WordPress 5.2 the failure is caught and displayed as a friendly message instead of a blank page, with a recovery link emailed to the admin.
I never got the recovery email. What now?
The admin address may be wrong, or the server isn't sending mail. Enable WP_DEBUG_LOG, reload the page, and read the fatal error straight from wp-content/debug.log.
Can a PHP version change cause this?
Yes — it's one of the most common causes. Hosts upgrade PHP automatically, and any plugin using syntax or functions removed in the newer version fatals immediately.
Critical error only in wp-admin, front end fine?
An admin-only code path is failing — a dashboard widget, an admin-side plugin hook, or a settings page. The debug log still names it.