How to Fix 'There Has Been a Critical Error' in WordPress (2026 Recovery Guide)

The error: "There has been a critical error on this website" — WordPress's wrapper for a fatal PHP crash since 5.2. The fast path: check your admin email for the recovery-mode link WordPress sent — it lets you log in and disable the culprit directly. If no email: enable WP_DEBUG, find the crashing file, disable it via FTP. Here are the fixes in order.

Step 1: Check for the Recovery-Mode Email (Fastest Fix)

When WordPress catches a fatal error, it emails the address in Settings → General with subject "Your Site is Experiencing a Technical Issue" and a special recovery-mode login link. Click it → you're logged into a safe-mode dashboard showing which plugin or theme caused the crash → deactivate it. This resolves the majority of cases in under two minutes.

Check spam. If no email exists (mail disabled, wrong admin address, you're not admin on record), recovery mode is unavailable — move to the manual method below.

Step 2: Identify the Culprit with WP_DEBUG

Without the email, you need to know what's crashing. Enable debug logging — it won't show errors publicly, only writes them to a file:

// In wp-config.php, above "That's all, stop editing" define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );

Reload the site once, then check wp-content/debug.log. The fatal error line names the file — almost always a path under wp-content/plugins/plugin-name/ or wp-content/themes/theme-name/.

Step 3: Deactivate the Culprit via FTP

Once you know the offender, connect via FTP (FileZilla) or your host's File Manager:

• Plugin → rename wp-content/plugins/plugin-name to plugin-name-off
• Theme → rename wp-content/themes/theme-name (WordPress falls back to a default theme)

Renaming the folder deactivates it instantly — the site should come back. Then update the offending plugin/theme, or replace it if abandoned.

Step 4: If You Can't Identify a Single Plugin — Disable All

Rename the whole wp-content/plugins folder to plugins-off. If the site loads, a plugin caused it; rename back and disable them one at a time to isolate. If it still errors with plugins off, switch to a default theme (twentytwentyfour) — if that fixes it, your theme is the problem.

Step 5: Check Memory Limit and PHP Version

If no plugin/theme is the culprit, two common triggers remain:

• Memory exhausted — add define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php. If the host's PHP memory_limit is lower, contact them or see our memory limit guide.
• PHP version incompatibility — an old plugin may crash on PHP 8.x, or a new one may require newer PHP than your host runs. Check the plugin's requirements vs your host's PHP version.

Step 6: Restore From Backup if All Else Fails

If the crash is in core files or you can't isolate it, restore from your host's backup or a backup plugin. A recent restore beats hours of debugging corrupted core files.

Prevention: Make Updates Non-Fatal

• Update plugins one at a time — bulk updates hide which one breaks
• Staging first — test updates on a copy before production
• Automatic backups — a bad update is a 1-click restore, not a crisis
• Hosting that helps — Bluehost's managed WP includes automatic backups, staging, and update management that catches bad updates before they take you down

Related: white screen of death, database connection error, 500 internal server error, stuck in maintenance mode.