WordPress "There Has Been a Critical Error": Causes and the Fix

You load your WordPress site and instead of your homepage you get one blank sentence: "There has been a critical error on this website. Please check your site admin email inbox for instructions." No stack trace, no line number — just that. Here's what's actually happening and how to get the site back up.

Symptom

The front end shows the critical error message. Often wp-admin shows the same thing, or a slightly friendlier version with a "Learn more about troubleshooting WordPress" link. If you're logged in as an administrator, you might see a bit more detail than a visitor does — WordPress deliberately hides the raw PHP error from anonymous users for security reasons.

This is different from a blank white screen (nothing renders at all) and different from a server-level 500 Internal Server Error (that one comes from Apache/Nginx before WordPress even loads). This message specifically comes from WordPress's own fatal-error handler, introduced in WordPress 5.2 as part of the "fatal error protection" feature.

Cause

Since WP 5.2, WordPress wraps page rendering in error handling. When PHP throws a fatal error — an undefined function, a memory exhaustion, a syntax error in a file that got included — instead of a blank page or a raw PHP error dump, WordPress catches it and shows this message. It also usually emails the site admin address with a one-time "recovery mode" link.

The fatal error itself is almost always one of these:

• A plugin or theme update that isn't compatible with your current PHP version
• A plugin calling a function from another plugin that's been deactivated or removed
• A corrupted plugin/theme file from an interrupted update or a bad FTP transfer
• PHP memory limit exhausted by a plugin doing heavy work (imports, PDF generation, image processing)
• A manual edit to functions.php or a custom snippet with a typo

Fix

1. Check your admin email for the recovery mode link

WordPress sends this automatically the first time the error occurs. Search your inbox for a subject like "Your Site is Experiencing a Technical Issue." The email contains a one-time link that logs you into a special Recovery Mode — WordPress runs with the broken plugin or theme paused so you can see exactly which one failed and deactivate it from the dashboard, no file access needed. This is the fastest fix if the email actually arrives (check spam, and confirm the site's admin email in Settings → General is one you actually check).

2. No email, or can't get into wp-admin? Find the real error in the log

Don't guess — check the PHP error log first.

• cPanel: Metrics → Errors, or look for error_log inside public_html via File Manager.
• SSH/VPS: tail -n 50 /home/USER/public_html/error_log or your PHP-FPM log, e.g. /var/log/php8.2-fpm.log.

If nothing useful shows up, turn on WordPress debug logging. Add these 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 site once, then open wp-content/debug.log. The last entry will name the exact plugin file and line that threw the fatal error. Turn these three lines back off once you're done — leaving debug logging on a live site is a habit worth breaking early.

3. Deactivate the offending plugin without wp-admin

Once you know which plugin (or the log points to wp-content/plugins/some-plugin/file.php), you have three ways in:

• SFTP or File Manager: rename the plugin's folder, e.g. some-plugin → some-plugin-off. WordPress treats a renamed folder as a deactivated plugin.
• WP-CLI (if you have SSH access): wp plugin deactivate some-plugin --allow-root
• phpMyAdmin: open the wp_options table, find the row where option_name = 'active_plugins', and edit the serialized value to an empty array: a:0:{}. This deactivates everything at once — use it when you can't tell which plugin is guilty and just need the site back.

If the whole plugins folder is suspect (after a bulk update, for example), rename the entire folder:

mv wp-content/plugins wp-content/plugins-disabled
mkdir wp-content/plugins

Confirm the site loads, then move plugins back into the new folder one at a time, reloading after each, until the error returns. That last one is your culprit.

4. If it's the theme, not a plugin

Rename the active theme's folder over SFTP. WordPress will fall back to a default theme (or show a "broken theme" notice) instead of the critical error, confirming the theme was the cause. If you need the site looking right immediately, switch to a default theme like Twenty Twenty-Four temporarily via wp theme activate twentytwentyfour while you fix the real theme.

5. Rule out PHP version mismatches

A common trigger is a PHP upgrade (say, cPanel auto-bumped you from 8.0 to 8.2) that breaks an old plugin using deprecated syntax. If the error started right after a PHP version change, go to MultiPHP Manager in cPanel and roll back one version to confirm. If that fixes it, the plugin needs updating — don't stay on an old PHP version long-term, it's a security liability.

Prevention

• Set the admin email in Settings → General to an address someone actually checks — the recovery mode email is useless if it lands in a dead inbox.
• Test plugin and PHP updates on a staging copy first (cPanel's Staging tool or a subdomain clone) instead of updating everything live at once.
• Keep WP-CLI or SSH access handy on sites where you manage plugins directly — it turns a 20-minute FTP fumble into a 30-second fix.
• Take a backup before major plugin or PHP version changes so you can roll back instantly if something breaks.
• Update plugins one or two at a time on important sites rather than bulk-updating everything in one click.