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

Use the Recovery Mode email

WordPress sends it to the address in Settings → General, or to the RECOVERY_MODE_EMAIL constant if a developer set one. The subject reads “[Your Site] Your Site is Experiencing a Technical Issue.” Check spam.

The email names the plugin or theme that crashed and includes a login link for Recovery Mode. By default that link stays valid for one day, and WordPress won’t send a fresh one until that window passes.

No email? That’s common. Many hosts throttle PHP mail, and the message goes to whatever admin address was set up long ago. Don’t wait on it. Move to Step 2.

Turn on the debug log and read the real error

The browser tells you nothing. The log tells you everything. Open wp-config.php and add these lines above the comment 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 once, then open /wp-content/debug.log and search for “Fatal error.” The folder name after /plugins/ or /themes/ is your culprit. A line looks like this (illustrative example):

PHP Fatal error:  Uncaught Error: Call to undefined function
example_helper() in /home/site/public_html/wp-content/
plugins/example-plugin/includes/loader.php:48

Here the culprit is example-plugin. That’s the folder to disable in Step 3.

Can’t edit wp-config.php? Check your host’s PHP error log instead. In cPanel it’s under Metrics → Errors.

Disable the plugin causing the crash

If the log named a plugin, rename only that folder inside wp-content/plugins, for example example-plugin to example-plugin-off. If the log was no help, rename the whole plugins folder to plugins-off.

Reload the site. If it loads, log in to wp-admin. WordPress marks every plugin it can’t find as inactive. Rename the folder back to plugins, then reactivate plugins one at a time, reloading after each. Renaming the folder back does not reactivate anything.

Still broken with every plugin disabled? Check two more places:

• wp-content/mu-plugins: must-use plugins load automatically and never show a Deactivate link. Rename the folder to test.
• object-cache.php and advanced-cache.php in wp-content: drop-ins left behind by a caching plugin you removed can crash the site. Rename them to test.

With SSH access, wp plugin deactivate --all --skip-plugins --skip-themes does it in one line. The skip flags stop WP-CLI from tripping over the same fatal error.

Switch to a default theme

Rename the active theme’s folder inside wp-content/themes. WordPress then falls back to a default theme, but only if one is installed. If you deleted every “Twenty” theme, upload a fresh one from wordpress.org/themes first, or you’ll swap one error for another.

Also undo your most recent edit to functions.php. One missing semicolon in a pasted snippet is a classic way to take a site down.

Via WP-CLI: run wp theme list, then wp theme activate your-default-theme-slug.

Check your PHP version

Two things trigger this: your host changes the PHP version, or a plugin update raises its minimum PHP requirement. Either way, the plugin and PHP stop agreeing.

WordPress 7.0 raised the minimum PHP version from 7.2.24 to 7.4. WordPress’s recommended version is PHP 8.3 or higher. Here is where each branch stands today:

To change versions, use MultiPHP Manager in cPanel, the PHP settings in Plesk, or the PHP tools in your managed host’s dashboard. If the crash began right after a PHP switch, set the previous version back first, get the site up, then update the plugin that needs the newer one.

My pick: PHP 8.3 as the safe default, and 8.4 once every plugin you run lists support for it. Test on staging before touching production.

Raise the memory limit (only if the log says so)

Memory is the cause when the log shows “Allowed memory size of 41943040 bytes exhausted.” That number is exactly 40 MB, which is WordPress’s default WP_MEMORY_LIMIT on a single site (64 MB on multisite). The admin side gets a separate ceiling, WP_MAX_MEMORY_LIMIT, which defaults to 256 MB.

Add this above the “stop editing” line in wp-config.php:

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

256M is plenty for most sites. Going to 512M rarely helps and can hide a plugin that’s leaking memory.

Replace corrupted WordPress core files

Suspect this when the log points at files inside wp-admin or wp-includes. With SSH, check first:

wp core verify-checksums
wp core download --force --skip-content

The second command re-downloads core files and leaves wp-content alone. No SSH? Download WordPress from wordpress.org, then upload fresh copies of wp-admin, wp-includes and the root PHP files. Never overwrite wp-content or wp-config.php. Those hold your plugins, themes, uploads and database credentials.

Unfamiliar files in uploads or failed checksums on files you never touched point to a compromise, not a bad update. Treat that as a security incident.

Clear leftovers from a failed update

• Delete the .maintenance file in the site root. It’s hidden, so enable “Show Hidden Files” in File Manager.
• If a plugin folder is empty or half-written, delete it and reinstall a fresh copy.
• Check your hosting panel’s disk usage. A full disk truncates files mid-write.
• Confirm permissions: 755 for folders, 644 for files.

Restore a backup, after saving a copy of the broken site

If one update broke everything and debugging is eating your day, restore. First, copy the broken files and database somewhere safe so you can still investigate later.

After restoring, don’t repeat the same update on the live site. Test it on staging first. If you move sites with Kadence Central (formerly Solid Central), my Solid Central migration-failed fix covers a failure worth knowing about.