WordPress "There has been a critical error on this website" Fix

"There has been a critical error on this website. Learn more about troubleshooting WordPress." is what WordPress shows when PHP hits a fatal error while loading a page. Since WordPress 5.2 the fatal error handler catches the crash and prints this friendly message instead of a blank page. Before 5.2 the same failure looked like the white screen of death.

The message tells you nothing about the cause, but WordPress knows it. It records the failing file and usually emails the site administrator. Your job is to get that detail.

Causes, most likely first

1. A plugin or theme update that is incompatible with your PHP version or another plugin.
2. A PHP version change at the host, so older code calls functions that no longer exist.
3. Exhausted PHP memory, covered in WordPress memory limit exhausted.
4. A syntax error from a code snippet or file edit.
5. A failed or partial update that left core, plugin or theme files half replaced.
6. A missing PHP extension after a server migration.

Step 1: read the recovery mode email

WordPress sends a message titled "Your Site is Experiencing a Technical Issue" to the address in Settings, General (the admin_email option). It names the plugin or theme that caused the fatal error and includes a recovery mode link. The link signs you in to a special session where the broken plugin or theme is paused, so you can deactivate it from the dashboard. Links are time limited, and WordPress rate limits these emails, so a second crash soon after the first may not send another. Check spam, and note that a broken mail setup (see WordPress email not sending) means it may never arrive.

Step 2: get the real error message

Turn on logging in wp-config.php, above the line 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, then read wp-content/debug.log:

PHP Fatal error:  Uncaught Error: Call to undefined function mb_strlen() in /var/www/html/wp-content/plugins/some-plugin/inc/helpers.php:42

The path tells you the culprit: plugins/some-plugin is the plugin, themes/some-theme is the theme. Also check your host's PHP error log (often /var/log/php-fpm/ or the control panel). Turn debug logging off when you finish, and do not leave debug.log publicly readable.

Step 3: disable the failing code

If you can reach the dashboard through recovery mode, deactivate the plugin there. If not, use SFTP, SSH or the host's file manager and rename the folder:

cd wp-content/plugins
mv some-plugin some-plugin.disabled

WordPress treats a missing plugin as deactivated. If you do not know which plugin, rename the whole plugins folder to plugins.off, load the site, then restore the name and move plugins back one by one. For a theme, rename its folder in wp-content/themes; WordPress falls back to a default theme if one is installed. A systematic approach is in plugin conflict troubleshooting.

With WP-CLI you can do the same without touching files:

wp plugin deactivate some-plugin
wp plugin deactivate --all
wp theme activate twentytwentyfour

If WP-CLI itself crashes, add --skip-plugins --skip-themes.

Step 4: match the error to a fix

• Call to undefined function in a plugin: a PHP extension is missing or the plugin needs a different PHP version. See call to undefined function.
• Allowed memory size exhausted: raise the limit or find the leak. See Allowed memory size exhausted.
• Parse error or unexpected token: a code edit broke syntax. See PHP parse error.
• Class not found: a missing file from a partial update. Reinstall the plugin from a fresh download; see class not found.
• Uncaught TypeError after a PHP upgrade: the plugin predates PHP 8. Update it, replace it, or roll PHP back; see Uncaught TypeError.

For a failed update, reinstall core with wp core download --force --skip-content (this replaces core files and leaves wp-content and wp-config.php alone). Back up first.

Step 5: check whether it is only part of the site

The critical error may affect only certain URLs, such as the admin or one template. The HTTP स्टेटस चेकर shows the status code for several URLs; a fatal error returns HTTP 500. Compare /, /wp-login.php and a post. See fix 500 internal server error for the general method. The वेबसाइट हेल्थ चेक gives a quick outside view.

How to verify

Load the home page, a post and /wp-admin/ in a private window. Check Tools, Site Health for new issues, and confirm debug.log stays quiet. Then turn logging back off.

अगले कदम

• Follow the white screen of death guide if you see no message at all.
• Run the Site Health Report after recovering.
• Add an अपटाइम मॉनिटर with a keyword check on your home page, so a fatal error pages you before customers notice.
• Read the HTTP 500 reference.

सामान्य प्रश्न

Will I lose my content?

No. A critical error is a code problem, not a database problem. Posts and settings stay in the database while you disable the failing plugin or theme.

I did not get the recovery email. What now?

Use the debug log or SFTP method. Check that the admin email is correct, check spam, and remember WordPress limits how often it sends these.

Can I bring back the old white screen?

Yes. Defining WP_DISABLE_FATAL_ERROR_HANDLER as true in wp-config.php turns the handler off. It is a debugging aid only, and not recommended on production.

Is this always caused by a plugin?

No, but plugins and themes are the majority of cases. The file path in the log tells you for certain.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.