How to Fix There Has Been a Critical Error on This Website

"There has been a critical error on this website" is the message modern WordPress shows when it catches a fatal PHP error instead of leaving you a blank page. On Ultra Web Hosting shared, VPS, and dedicated plans it is almost always a plugin, a theme, exhausted memory, or a PHP version mismatch. The good news is that since WordPress 5.2 the platform emails your site administrator a special Recovery Mode link that lets you log in and pause the exact thing that broke. This guide shows you how to use that email first, and how to fix it by hand when the email never arrives.

01. What the Critical Error Message Means

When PHP hits a fatal error, the script stops dead. In older WordPress that left a pure blank page, the White Screen of Death. Since WordPress 5.2 the platform installs a shutdown handler that catches most fatal errors and shows a friendly page instead: "There has been a critical error on this website." Logged-in administrators sometimes see a slightly longer version that adds "There has been a critical error on this website. Please check your site admin email inbox for instructions."

That second sentence is the important part. WordPress did not just show you a nicer error page. It also tried to email your site administrator with the details and a way back in. So the message is not a dead end, it is a starting point. The underlying problem is a real PHP fatal error, the same class of fault that used to cause a blank screen, but now WordPress is helping you find it.

02. First: Check Your Admin Email Inbox

Before anything else, open the inbox for your WordPress administrator email address. This is the address set under Settings > General > Administration Email Address in wp-admin, which is not always the same as the address you log in with. When the critical error fired, WordPress attempted to send a message there.

1. Open the mailbox for your site's admin email address, including the spam and junk folders.
2. Look for a message with the subject "Your Site is Experiencing a Technical Issue" sent from your own site.
3. Open it. The email names the exact plugin or theme that caused the crash, often with the specific file and line number.
4. Near the bottom is a Recovery Mode login link. That link is your fastest route back into the dashboard. Section 03 walks through using it.

03. Using WordPress Recovery Mode

Recovery Mode is a special login state that WordPress enters through the link in that email. When you log in this way, WordPress pauses the plugin or theme it identified as the cause, so the fatal error no longer fires and you can reach a working /wp-admin dashboard.

1. Click the Recovery Mode link in the technical-issue email. It opens the WordPress login screen.
2. Log in with your normal administrator username and password.
3. WordPress loads the dashboard with a notice at the top telling you which plugin or theme has been paused. A paused component is loaded in a safe, deactivated-for-you state.
4. Go to Plugins (or Appearance > Themes) and act on the flagged item. Deactivate it, update it if an update is waiting, or delete and reinstall it.
5. Once the offending component is dealt with, click Exit Recovery Mode in the admin bar. Reload your public site to confirm it loads normally.

04. No Email? Fall Back to Manual Fixes

Plenty of sites never receive the Recovery Mode email. That is not a WordPress bug, it usually means one of these:

• The admin email address is wrong or abandoned. Check what is set under Settings > General if you can reach the dashboard, or in the wp_options table under admin_email if you cannot.
• The site cannot send mail. Shared hosting PHP mail is unreliable and often filtered. If your WordPress notifications generally do not arrive, the site's mail is the real issue, and configuring proper SMTP is the long-term fix.
• The error is too severe for the handler. Some fatal errors happen so early that WordPress cannot catch them or send anything, and you get a blank page instead of the friendly message.

When the email is not coming, you diagnose and fix the crash directly through cPanel File Manager or FTP. The next two sections do exactly that: make the error visible, read it, then apply the matching fix.

05. Turn On WP_DEBUG and Read the Log

The critical error page hides the actual PHP error from visitors by design. To see it, switch on WordPress debug logging so the exact fault is written to a file you can read. This is the single most useful step when the email did not arrive.

Open wp-config.php in cPanel File Manager (right-click, Edit). Find the line that reads /* That's all, stop editing! Happy publishing. */ and add the following above it. If a define('WP_DEBUG', false); line already exists, replace it rather than adding a duplicate.

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

Save the file, reload your site once to trigger the error, then open wp-content/debug.log in File Manager and read the last few lines. A caught fatal error names the exact file and line:

PHP Fatal error:  Uncaught Error: Call to undefined function
  some_plugin_function() in
  /home/user/public_html/wp-content/plugins/bad-plugin/bad-plugin.php:212

06. The Usual Causes and Quick Fixes

The critical error page and the classic white screen share the same root causes, so the fixes are the same. Rather than repeat every step here, this section names each cause, gives the quick fix, and points to the guide with the full walk-through where one exists.

1. Plugin conflict. The most common cause by far, and usually right after a plugin update. If you can reach wp-admin, deactivate plugins from the Plugins screen. If not, in File Manager rename wp-content/plugins to plugins-off to deactivate them all at once, reload, then rename it back and reactivate one at a time to find the bad one.
2. Theme fault. Common after a theme update or a direct edit to functions.php. From wp-admin, switch to a default theme under Appearance > Themes. If the dashboard is down, rename the active theme's folder under wp-content/themes so WordPress falls back to a bundled default like Twenty Twenty-Four.
3. PHP memory exhaustion. If the log shows Allowed memory size ... exhausted, the request ran out of memory. Raise it in wp-config.php and, if needed, in cPanel MultiPHP INI Editor. Our "WordPress Memory Exhausted" guide covers the exact limits and where to set them.
4. PHP version mismatch after an update. A plugin or WordPress update that needs newer PHP throws fatal errors on an old version, and occasionally a new PHP version breaks an old plugin. Switch the version in cPanel MultiPHP Manager; our guide on changing your PHP version (ID 425) walks through it.
5. Corrupted core files. An interrupted update can damage a core file. Upload fresh wp-admin and wp-includes folders from a clean WordPress download, overwriting the old ones. Never touch wp-content or wp-config.php. If an extraction fails with a PCLZIP error, see ID 429.
6. A broken functions.php edit. A stray character or unclosed brace pasted into the theme's functions.php is a classic trigger. The debug log points right at the line. Paste back a known-good copy, or remove the snippet you just added. Our "How to Fix the WordPress White Screen of Death" guide covers safe theme editing with a child theme.

07. How This Differs From the White Screen and Database Errors

Three WordPress failures look similar from the outside but need different guides. Match what you actually see on screen to the right one so you are not applying database fixes to a plugin crash.

08. When It Is Malware, Not a Bug

Most critical errors are ordinary faults, a plugin update gone wrong or a bad edit. But a critical error that appears with no change on your side, especially alongside files you do not recognize, can be the aftermath of a compromise. Injected code that half-broke, or a malicious file with a syntax error, throws the same fatal error as a legitimate bug.

• The error appeared without any update, edit, or install on your part.
• The debug log points at a file with an odd name, or one full of obfuscated code, base64 strings, or eval( calls.
• You find plugin folders, PHP files, or admin users you did not create.
• Fixing one error only surfaces another, as if something is actively rewriting files.

09. Restoring From a Backup as a Last Resort

If you have checked the admin email, tried Recovery Mode, read the debug log, and worked through the causes without success, the cleanest path back is to restore the last known-good backup. This undoes whatever change broke the site in one move, rather than chasing the error further.

1. Identify the last point in time the site was working, ideally before the update or edit that triggered the error.
2. In cPanel, use the backup or restore tool to roll the account (or just the affected files and database) back to that point.
3. Reload your site to confirm it loads on the restored version.
4. Re-apply the update or change more carefully, one item at a time, so you can catch the fault if it returns.

Quick Recap: The Critical Error in Six Steps

If you only remember six things from this guide, remember these:

1. Check your admin email inbox for the "Your Site is Experiencing a Technical Issue" message, which names what broke.
2. Use the Recovery Mode link in that email to log in with the offending plugin or theme paused, then fix it from wp-admin.
3. No email? Turn on WP_DEBUG and WP_DEBUG_LOG in wp-config.php and read wp-content/debug.log for the exact file and line.
4. Work the usual causes: plugin conflict, theme fault, memory, PHP version (ID 425), corrupted core, or a broken functions.php edit.
5. Tell it apart from a blank white screen and from a database-connection error, and follow the right guide for what you actually see.
6. If it looks like a hack (ID 478) or nothing else works, clean it or restore a backup and re-apply changes carefully.

Last updated July 2026 · Browse all WordPress articles