How to Fix “There Has Been a Critical Error on This Website” in WordPress

“There has been a critical error on this website” means WordPress hit a fatal PHP error it could not recover from, almost always caused by a plugin, a theme, or a PHP version or memory problem. The fix is usually a matter of finding which piece of code failed and disabling it, and most sites are back within 15 to 30 minutes. This guide walks through the causes in order of likelihood, how to read the error, and the exact steps to recover, including what to do when you cannot log in to wp-admin at all.

What the Error Actually Means

Since WordPress 5.2, a fatal PHP error no longer produces a blank white page. WordPress catches it and shows the visitor a plain message: “There has been a critical error on this website. Please check your site admin email inbox for instructions.” Behind that message is a real PHP fatal error: a function that does not exist, a syntax error in a file, an out-of-memory condition, or a conflict between two pieces of code.

The instructions it refers to are an email to the site’s admin address with the subject “Your Site is Experiencing a Technical Issue.” That email names the plugin or theme that caused the problem and contains a recovery mode link. If you can find that email, you have already done most of the diagnosis.

First: Check for the Recovery Mode Email

Search the admin inbox (Settings → General → Administration Email Address, or whoever set up the site) for the subject line above. The email will say something like “WordPress has a built-in feature that detects when a plugin or theme causes a fatal error on your site… In this case, WordPress caught an error with one of your plugins, [Plugin Name].” Click the recovery mode link, log in, and WordPress will load with the faulty plugin or theme paused. Deactivate it from the Plugins screen, exit recovery mode, and the site is back.

The link expires after 24 hours and the email is sometimes filtered as spam or sent to an address nobody checks. If you cannot find it, move on to the manual steps.

The Most Common Causes

A plugin update or new plugin. By far the most frequent cause. A plugin update introduces a bug, requires a newer PHP version than the server runs, or conflicts with another plugin. If the error appeared right after you updated or installed something, that is almost certainly it.

A theme update or a code edit. A missing semicolon in functions.php, a pasted snippet that calls a function that does not exist, or a theme update that drops support for something a child theme relies on.

PHP version mismatch. Hosts periodically upgrade PHP. Old plugins that use removed functions break; conversely, new plugins may require PHP 8.1 or later while the site still runs 7.4.

Memory exhausted. The error log reads “Allowed memory size of 134217728 bytes exhausted.” A heavy plugin, a large import, or an image-processing task exceeds the PHP memory limit.

Corrupted or missing core files. Rarer, but an interrupted update or a hosting migration can leave WordPress core files incomplete.

Database connection or corruption. Usually shows as “Error establishing a database connection” instead, but a corrupted options table can surface as a critical error too.

How to Find the Exact Error

Guessing is slower than looking. Two ways to see the real message:

Enable debug logging. Connect by SFTP or your host’s file manager, open wp-config.php, and above the line that says “That’s all, stop editing!” add:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the broken page, then open wp-content/debug.log. The last “PHP Fatal error” line names the file and line number, and the file path tells you which plugin or theme is responsible. Remove those lines from wp-config.php when you are done; you do not want debug logging running permanently on a production site.

Read the server error log. On WP Engine, the User Portal has an Error Logs section for each environment. Other hosts expose logs in cPanel or their own dashboard. The same fatal error line will be there without touching any files.

How to Fix It Step by Step

1. Deactivate the faulty plugin

If you can reach wp-admin (via recovery mode or because the error is only on the front end), deactivate the plugin named in the log. If you cannot log in, connect by SFTP, go to wp-content/plugins, and rename the plugin’s folder (for example, from “plugin-name” to “plugin-name-off”). WordPress treats a missing folder as a deactivated plugin. If you do not know which plugin, rename the entire plugins folder to “plugins-off”, confirm the site loads, rename it back, and then rename individual plugin folders one at a time until you find the culprit.

2. Switch to a default theme

If the log points to the theme, rename its folder in wp-content/themes. WordPress falls back to a default theme (Twenty Twenty-Four or similar) if one is installed. Fix the offending file, or restore the previous version of the theme from a backup, then rename the folder back.

3. Raise the PHP memory limit

For memory-exhausted errors, add to wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

Some hosts cap this at the server level; if 256M does not take effect, ask your host to raise it. Treat this as a bridge, not a cure: find out which plugin needed that much memory and why.

4. Check the PHP version

In your hosting dashboard, check which PHP version the site runs. WordPress currently recommends PHP 8.1 or later. If a plugin update requires a newer version, upgrade PHP (test on staging first). If an old plugin broke after a PHP upgrade, you can temporarily roll PHP back while you find a replacement plugin, but do not stay on an unsupported version.

5. Re-upload WordPress core

If the log points to a file in wp-admin or wp-includes rather than a plugin or theme, download a fresh copy of WordPress from wordpress.org, and upload the wp-admin and wp-includes folders over the existing ones. Do not overwrite wp-content or wp-config.php.

6. Restore a backup

When the cause is unclear and the site is down, restoring the most recent backup is faster than debugging. WP Engine keeps daily restore points and lets you restore with one click; most managed hosts have an equivalent. Restore, then reapply any legitimate changes carefully.

How to Keep It From Happening Again

Almost every critical error we are called in to fix follows the same pattern: an update was applied directly on the live site, with no staging test and no recent backup. The fixes are procedural, not technical:

• Update plugins and themes on a staging copy first, then push to production.
• Keep automatic daily backups and know how to restore them before you need to.
• Run a supported PHP version and check plugin compatibility before upgrading it.
• Keep the plugin count low. Every plugin is code you did not write running on your site; the fewer there are, the fewer things can break. This is one reason we build custom WordPress themes with functionality coded in rather than bolted on.
• Make sure the admin email address is one a real person reads, so recovery mode emails arrive.

If you would rather never see this error again, that is what a maintenance plan is for. Our WordPress care plans include managed WP Engine hosting, daily backups, monthly updates, free restoration after a hack, and a developer who fixes this kind of problem before you notice it. If your site is down right now and you are stuck, get in touch and we will help you get it back.