How to Fix the WordPress “There Has Been a Critical Error” Message

The quickest safe response is to check the site administrator’s email for a Recovery Mode link. If no email arrives, use your hosting error logs to identify the failing plugin or theme before disabling anything.

Before changing files or settings, make a backup or confirm that your host has a recent restore point. Avoid updating WordPress, PHP, themes, and every plugin at once. Multiple changes make the original fault harder to identify and reverse.

Try WordPress Recovery Mode

A critical error usually means PHP stopped while WordPress was processing a request. When WordPress detects certain fatal errors, it may email the site administrator a special login link.

Check the inbox and spam folder for an email with a subject similar to “Your Site is Experiencing a Technical Issue.” The message may name the plugin or theme involved.

Open the Recovery Mode link and sign in. WordPress will pause the faulty component for your administrator session, allowing you to reach the dashboard without immediately changing what visitors see.

In the dashboard:

1. Open Plugins or Appearance > Themes.
2. Look for the component named in the notice.
3. Deactivate the plugin or switch away from the faulty theme.
4. Leave Recovery Mode and test both the homepage and /wp-admin/.

The recovery link expires, but WordPress can send another one if the fatal error continues. The official Recovery Mode documentation explains how these links and paused components work.

If deactivating the component restores the site, do not immediately reactivate it. Roll back the recent update, replace the changed code, or ask the vendor whether the current release supports your WordPress and PHP versions.

Check the server error log

If the email does not identify the cause, inspect the PHP or web-server error log in your hosting control panel. Search entries recorded at the time the critical error appeared.

A useful fatal-error entry normally includes a file path and line number, for example:

PHP Fatal error: Uncaught Error ... /wp-content/plugins/example-plugin/example.php:123

The path often identifies the responsible component:

• /wp-content/plugins/plugin-name/ points to a plugin.
• /wp-content/themes/theme-name/ points to a theme or child theme.
• /wp-admin/ or /wp-includes/ may indicate a core file problem, but the call stack can still show that a plugin triggered it.
• A custom path can point to hosting middleware or manually added PHP code.

Use the log to choose the next action. Do not post the complete log publicly because it can contain server paths, account names, request data, or other sensitive information.

If no log is available, ask your host for the PHP fatal error recorded for the affected URL and timestamp.

Disable a faulty plugin without wp-admin

When the error names a plugin and you cannot open the dashboard, disable that plugin through SFTP or your host’s file manager.

1. Open the site’s wp-content/plugins directory.
2. Find the folder named in the fatal-error path.
3. Rename it by adding .disabled, such as example-plugin.disabled.
4. Reload the site and try /wp-admin/ again.

WordPress will be unable to load the renamed plugin directory. If the site recovers, leave the plugin disabled while you investigate the update, compatibility problem, or custom modification that caused the error.

To roll back this test, restore the original folder name. Renaming the folder does not automatically reactivate the plugin.

If the log does not identify one plugin, WordPress documents how to deactivate all plugins when the administration menus are unavailable. Rename the entire plugins directory only as a temporary diagnostic step. Restore its original name afterward, then reactivate plugins individually until the error returns.

Must-use plugins are stored separately in wp-content/mu-plugins and are not disabled by renaming the normal plugins directory. Check that location if the error persists.

Check active components with WP-CLI

If SSH and WP-CLI are available, list the active plugins and theme before making changes:

wp plugin list --status=active
wp theme list --status=active

Compare the results with recent updates, deployments, or configuration changes. A plugin appearing in the list proves only that it is active; use the fatal-error log to determine whether it caused the failure.

Once you have identified the faulty plugin, use the documented wp plugin deactivate command to disable only that component:

wp plugin deactivate plugin-slug

Replace plugin-slug with the plugin’s directory name. Test the affected page and the dashboard immediately after the change.

If normal WP-CLI commands also trigger the fatal error, ask your host to inspect the server log or use SFTP to rename the component identified there.

Handle a theme-related critical error

When the error path points to the active theme or child theme, first preserve any custom code that was recently added to functions.php or another template file. Then reverse that specific change if possible.

If you cannot identify the edit, use WP-CLI to see which theme is active:

wp theme list --status=active

Switching themes is appropriate only when another known-good theme is already installed. On a live site, changing the theme can alter layouts, menus, widgets, and template behavior. Create a backup first and be prepared to reactivate the original theme.

If you use SFTP, renaming the active theme folder works only when WordPress has an installed fallback theme it can load. Without one, the site may remain unavailable. Ask your host to restore the theme from backup when you are unsure.

Restore the smallest possible change

After access returns, identify what happened immediately before the error:

• A plugin or theme was updated.
• PHP was upgraded by the host.
• Custom code was added or deployed.
• WordPress core was updated.
• Files were restored or permissions were changed.

Reverse the most recent relevant change rather than applying several speculative fixes. For a failed plugin or theme update, restore the previous known-good release from a trusted backup or obtain the correct package from its official source.

Do not edit WordPress core files to suppress a fatal error. If logs point to missing or altered core files, restore from backup or replace them with clean files from the matching official WordPress release while preserving wp-content and wp-config.php.

Contact your host or a developer when the error persists with normal plugins disabled, follows a PHP version change, involves database failures, or returns immediately after a rollback. Provide the timestamp, affected URL, and the relevant fatal-error entry without sharing credentials or the entire server log.