“There has been a critical error on this website” is WordPress telling you that PHP hit a fatal error before the page could finish rendering. Since WordPress 5.2 it replaces the old blank white screen, so the message is actually an improvement: something specific broke, and the site is still alive enough to say so.
The three things that fix it, in order: read the error, disable the thing that caused it, then fix the cause. Most people skip step one and start deactivating plugins at random, which is why a five-minute job turns into an hour.
Step 1: check the admin email first
WordPress emails the site admin address when a fatal error occurs, and that email contains a recovery-mode link. Open it and you get a stripped-down admin session with the offending plugin or theme disabled — no FTP, no database access. This works even when the front end is completely dead.
If the inbox is empty, the message may have been filtered as spam, or the site cannot send mail at all. In that case move to the log.
Step 2: turn on the error log
Add these three lines to wp-config.php, above the line that says That’s all, stop editing:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reload the broken page, then open wp-content/debug.log through your host’s file manager. The last entry before the crash is your answer — it names the file and usually the line. Something like PHP Fatal error: Uncaught Error: Call to undefined function followed by a path under wp-content/plugins/ tells you exactly which plugin to disable.
Keep WP_DEBUG_DISPLAY set to false so errors are logged rather than printed to visitors, and remember to set WP_DEBUG back to false once the site is fixed.
Step 3: match the symptom to the cause
| Symptom | Most likely cause | First move |
|---|---|---|
| Started right after an update | Plugin or theme incompatibility | Deactivate the last-updated plugin |
| Started after editing a file | PHP syntax error | Restore that file from backup |
| Blank page on every URL, including wp-admin | Fatal in a must-use plugin or theme | Rename the plugin folder via file manager |
| Works on some pages only | Single plugin feature or a shortcode | Disable that plugin, test the page |
| Says “allowed memory size exhausted” | PHP memory limit | Raise the limit in wp-config or php.ini |
| Every page, after a host migration | PHP version or missing extension | Switch PHP version in the hosting panel |
Step 4: bisect the plugins
With no error log available, the fastest reliable method is to disable everything and re-enable in halves. Over WP-CLI that is two commands:
wp plugin deactivate --all
wp plugin list --status=inactiveLoad the site. If it comes back, reactivate plugins in batches of five until it breaks again — the batch that breaks it contains your culprit. If the site is still broken with every plugin off, the problem is the theme: switch to a default theme by renaming the active theme’s folder, which forces WordPress to fall back.
Do this on a copy of the site if you can. On a live site, work fast and keep the file manager open: renaming a plugin folder is instant and reversible, while clicking through the dashboard may be impossible if the fatal error is in an admin-facing plugin.
Step 5: the causes that get missed
- PHP version. A host upgrading from PHP 8.1 to 8.3 overnight breaks plugins written for an older version. Site Health (Tools → Site Health → Info → Server) shows what you are running; switch it in the hosting panel and retest.
- Memory. A page builder plus a heavy plugin can exceed a 128MB limit. Raise it to 256M for testing:
define( 'WP_MEMORY_LIMIT', '256M' ); - Corrupted core files. Reinstall WordPress from Dashboard → Updates → Re-install version. This never touches your content.
- A plugin that is fine on its own. Two plugins that each work can still collide; the error log names one of them, the other is the trigger.
Prevention, briefly
Fatal errors are cheap to recover from when you have two things: a backup you have actually restored once, and a staging site for updates. Without them, every update is a gamble on a live audience.
Updates are also where most of these errors originate — a plugin update tested on staging, then pushed, never takes a site down. Our WordPress care plans exist for exactly that: updates tested before they reach the live site, with a restore point if one goes wrong.
FAQ
Does the critical error message mean I lost data?
Almost never. A fatal error stops execution; it does not delete posts or settings. Content loss comes from a failed restore or a broken migration, not from the error itself.
How long does it take to fix?
Fifteen minutes if the log names the plugin. Hours if you are bisecting blind on a site that receives orders, which is why the recovery email matters more than the error text.
Can I fix it without file access?
Only through the recovery-mode link in the admin email. If that email never arrived and you have no file manager or FTP, you need your host’s support to disable the plugin for you.
Is it safe to just delete the plugin folder?
Rename it instead. Deleting removes the plugin’s files permanently; renaming disables it and lets you restore it in ten seconds if it turns out not to be the cause.
