There Has Been a Critical Error on This Website: How to Diagnose It and Regain Access

Updated 2 months ago

If WordPress displays “There has been a critical error on this website,” check the administrator’s email and try recovery mode. If you can still access the dashboard, investigate the latest change; if you can’t log in and didn’t receive the email, you can check the affected component in your hosting files.

This notice means WordPress couldn’t complete an operation, usually because of a fatal PHP error. The message alone doesn’t identify the cause: it could be a plugin, the theme, custom code, or an incompatibility with the PHP version.

Before you change anything

Testing one thing at a time lets you see what restored the site and roll back if it didn’t work. You’ll need administrator access to WordPress or your hosting account; if you only have an editor account, ask the person who manages the site for help.

Note what you were doing and the time the error first appeared, including your time zone.
Check whether the entire site is failing, just one page, or /wp-admin/ as well.
Identify the latest change: an update, plugin installation, code edit, PHP change, or restoration.
Confirm that you have a backup from before the problem and also keep the current state before modifying files. You can review our backup and restore options.

Restoring a store’s database to an earlier date may remove orders, users, or changes recorded after that backup. If your site is still receiving transactions, coordinate the recovery with us before restoring the entire site.

Choose a path based on the access you still have

The recovery email and WordPress dashboard let you isolate the problem without starting with a full restoration.

I received an email with a link to recovery mode

WordPress may send the administrator an email identifying the component that failed and providing a special link. Check Spam too; not all errors trigger this email, and a sending problem may prevent it from arriving.

Open the recovery link in the email after verifying that it points to your own domain.
Log in with your WordPress administrator account.
Check the notice identifying the affected plugin or theme.
If it identifies a plugin, deactivate it from Plugins. If it identifies the theme, activate another compatible theme you already have installed from Appearance > Themes, keeping in mind that the design will change.
Exit recovery mode from the admin bar after applying the fix.
Test the page that was failing in a private window.

In recovery mode, the problematic component is paused for your session. Being able to access the dashboard doesn’t mean visitors can see a working site yet: you need to fix or deactivate the component and check that normal access works.

Keep the recovery link private. Don’t include it in public screenshots.

I can access the dashboard, but a page or feature shows the error

If the problem started after you modified a specific plugin, try that component first and repeat the same action that triggers the error.

Note the name and version of the plugin you changed.
Deactivate it from Plugins.
Test the affected page or feature again.

If it works again, leave the component deactivated until you fix its incompatibility or install a version that resolves the problem. Deactivating it also suspends its function: if it handles payments, forms, or memberships, check which parts of the site are affected.

If there’s no clear suspect, run compatibility tests on a WordPress clone. Deactivating many plugins at once on the live site can interrupt features and make it harder to identify the cause.

I can’t access the dashboard and didn’t receive the recovery email

If the error log or the latest change points to a plugin, you can prevent WordPress from loading it by renaming only its folder. This test preserves the plugin’s files and database.

Go to the cPanel File Manager.
Locate the affected installation, where wp-admin, wp-content, and wp-includes are found. Don’t assume all your sites are in public_html.
Open wp-content/plugins and locate the folder for the identified plugin.
Use the rename option and add -desactivado to the end. Note its original name.
Test the affected page and access to /wp-admin/ again.

If you regain access, open /wp-admin/plugins.php so WordPress detects that the plugin is missing and deactivates it. Then you can restore the folder’s original name; check that the plugin is still deactivated, and don’t reactivate it until you’ve resolved the cause. If the test doesn’t change the result, restore the previous name and continue by checking the error log.

Don’t rename wp-content or delete folders. Must-use plugins in mu-plugins, some special cache files, and the theme can’t be isolated with this procedure; if the error points there, send it to us so we can investigate.

How to find the error that explains the problem

Look for a recent entry that matches the time and the action that failed. A Fatal error, Uncaught Error, or Parse error message is a more useful clue than an old warning.

The recovery email may include this information. If you don’t have it, ask us about your site’s PHP error log; if a wp-content/debug.log file already exists, check its date before attributing the current problem to it.

What appears in the log	What to check
A path inside `wp-content/plugins/`	The specified plugin, its latest update, and its compatibility. The path is a clue; there may also be a conflict with another component.
A path inside `wp-content/themes/`	The theme or child theme, especially if `functions.php` was edited.
`Parse error` or `syntax error`	The recent code edit or an incomplete file. Restore a known-good copy of that file; don’t delete lines at random.
`Allowed memory size exhausted`	The task that exhausted memory and the component involved. Increasing a limit without investigating may hide an abnormal operation.

I maintain the site: I need to enable a debug log

Use this option preferably on a test clone. WordPress recommends its debugging tools for development; in production, coordinate a temporary capture with us to avoid exposing information or accumulating logs.

Download a copy of wp-config.php before editing it.
Check whether the WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY constants already exist. Modify the existing ones or add any that are missing, before the line that says to stop editing; don’t duplicate them.
Use this configuration in the test environment:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reproduce the action that fails once.
Read the new entries in wp-content/debug.log.
When you’re done, restore the previous debug configuration and remove the generated log after saving a private copy if you need one.

The log file may contain paths and other site information. Don’t publish it or leave it downloadable. If it isn’t generated, don’t assume there’s no error: the failure may happen before WordPress logs it, or there may be a permissions problem.

If the error started after changing PHP

Check that WordPress, the theme, and the plugins are compatible with the selected version, as well as the extensions the application uses.

You can find out how to change the PHP version and configuration. If the problem started immediately after the change, consider temporarily switching back to the previous compatible version while you fix the component; don’t keep an unsupported version as a permanent solution.

When to restore and how to check that recovery worked

Restoring is useful when you have a backup from before the failure and know what data it will replace. If restoring a file or component is enough, avoid rolling back the entire account.

Choose the backup and restoration scope while keeping the current backup safe.
Check the page that was failing and confirm you can access the dashboard normally, outside recovery mode.
Test the affected features: forms, user access, or the cart, depending on your site.
Check that repeating the same test doesn’t generate a new fatal error.

If an earlier backup restores the site, investigate which change caused the failure before repeating the update.

What to send us if you need help

We can investigate the issue more effectively with the exact URL, when the error occurred, and the action that reproduces it. Contact us through the support area with the following information:

Domain and affected URL, date, time, and time zone.
Whether you can access the dashboard and whether you received the recovery email.
The latest known change and the versions of WordPress, PHP, and the component involved, if you have them.
The error message and an excerpt from the log around the time of the failure.
Tests performed and whether the site records orders or other data that must be preserved.

Don’t attach the entire wp-config.php file: it contains credentials. Also, don’t send the recovery link in a public screenshot.

Was this helpful?