There has been a critical error on this website: how to diagnose it and regain access

Updated 2 days 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 cannot log in and did not receive the email, you can review the affected component through your hosting files.

The notice indicates that WordPress could not complete an operation, usually because of a fatal PHP error. The message alone does not identify the cause: a plugin, theme, custom code, or incompatibility with the PHP version may be involved.

Before changing anything

Testing one thing at a time lets you determine what restored the site and go back if it did not work. You need administrator access to WordPress or the 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 of the first error, 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 copy from before the problem and also preserve the current state before modifying files. You can review our backup and restoration 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 it completely.

Choose the path based on the access you still have

The recovery email and the 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 with the component that failed and a special link. Also check Spam; not all errors generate this email, and a delivery problem may prevent it from arriving.

Open the recovery link from the email after verifying that it points to your own domain.
Log in with your WordPress administrator user.
Review 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 that you already have installed from Appearance > Themes, keeping in mind that this will change the design.
Exit recovery mode from the administration 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 does not mean that visitors can already see the site working: you need to fix or deactivate the component and verify normal access.

Keep the recovery link private. Do not include it in public screenshots.

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

If the problem started after modifying a specific plugin, test that component first and repeat the same action that produces 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 is no clear suspect, perform the compatibility tests on a WordPress clone. Deactivating many plugins at once on the live website can interrupt features and make it harder to identify the cause.

I cannot access the dashboard and did not receive the recovery email

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

Open the cPanel File Manager.
Locate the affected installation, where wp-admin, wp-content, and wp-includes are located. Do not assume that all your sites are in public_html.
Open wp-content/plugins and locate the folder for the identified plugin.
Use the option to rename it and add -desactivado at 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. You can then restore the folder’s original name; confirm that the plugin remains deactivated and do not reactivate it until you resolve the cause. If the test does not change the result, restore the previous name and continue with the error log.

Do not rename wp-content or delete folders. Must-use plugins in mu-plugins, some special cache files, and the theme are not isolated with this procedure; if the error points there, send it to us so we can review the case.

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 provides a more useful clue than an old warning.

The recovery email may include this information. If you do not have it, ask us for 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 within `wp-content/plugins/`	The indicated plugin, its latest update, and its compatibility. The path is a clue; there may also be a conflict with another component.
A path within `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; do not delete lines at random.
`Allowed memory size exhausted`	The task that exhausted memory and the component involved. Increasing a limit without investigating may conceal an abnormal operation.

I maintain the site: I need to enable a debugging 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 indicates you should stop editing; do not 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 finished, restore the previous debugging configuration and remove the generated log after saving a private copy if you need it.

The log file may contain paths and other site data. Do not publish it or leave it downloadable. If it is not generated, do not assume there is no error: the failure may occur before WordPress logs it, or there may be a permissions problem.

If the error started when changing PHP

Check the compatibility of WordPress, the theme, and the plugins with the selected version, as well as the extensions used by the application.

You can learn how to change the PHP version and configuration. If the failure began immediately after the change, consider temporarily returning to the previous compatible version while you fix the component; do not keep an unsupported version as a permanent solution.

When to restore and how to verify recovery

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

Choose the backup and the scope of the restoration while keeping the current backup preserved.
Verify the page that was failing and normal dashboard access, outside recovery mode.
Test the affected features: forms, user access, or the shopping cart, depending on your site.
Check that the same test does not generate a new fatal error.

If an earlier copy 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 case more effectively with the exact URL, the time of the error, 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.
Last known change and the versions of WordPress, PHP, and the component involved, if you have them.
Error message and a snippet of the log near the failure.
Tests performed and whether the site records orders or other data that must be preserved.

Do not attach the complete wp-config.php file: it contains credentials. Also, do not send the recovery link in a public screenshot.

Was this helpful?