Fix the WordPress Critical Error Message Step by Step

What actually triggers the WordPress critical error?

The first time I saw the “There has been a critical error on this website” message was back in 2019, right after WordPress 5.2 shipped its new fatal error handler. Before that release, a PHP fatal error produced a blank white screen with no explanation. WordPress 5.2 changed that by wrapping page loads in a try-catch mechanism that intercepts fatal errors and displays an actual message instead of nothing.

Every wordpress critical error fix starts with understanding what caused the crash. The message itself is generic. It tells you something broke but not what. The real error lives in your PHP error log or WordPress debug log, and finding it is the first step toward a fix.

Here are the causes I encounter most often, ranked by frequency from years of troubleshooting WordPress sites:

Cause	How Often I See It	What Happens
Plugin conflict or fatal error	About 60-65% of cases	A plugin update introduces incompatible code or conflicts with another plugin
Theme PHP error	About 15-20% of cases	Theme code calls a removed function, has a syntax error, or breaks on a newer PHP version
PHP memory exhaustion	About 10% of cases	A process exceeds the server memory limit, killing execution mid-page
PHP version incompatibility	About 5-8% of cases	Server PHP upgrade breaks old plugin or theme code that relied on deprecated functions
Corrupted WordPress core files	About 3-5% of cases	A failed auto-update or file permission issue damages core files

This is not the same problem as the WordPress white screen of death. The white screen is a blank page with zero output. The critical error message means WordPress loaded enough of its core to detect the crash and show you a notice. They share root causes (PHP fatal errors), but the critical error message only appears on WordPress 5.2 and later. If you see a pure blank screen on a modern WordPress install, the error is happening so early that even the fatal error handler cannot load.

How WordPress Recovery Mode Works

WordPress 5.2 introduced recovery mode alongside the critical error message. When WordPress detects a fatal error during a normal page load, it does three things:

1. Pauses the extension (plugin or theme) that caused the crash
2. Sends an email to the admin email address with a recovery mode link
3. Displays the critical error message to visitors

The recovery email subject line reads “Your Site is Experiencing a Technical Issue.” Inside, you get a one-time link that places a cookie in your browser, allowing you to access wp-admin while the broken extension stays paused.

The recovery link expires after 24 hours. If you miss it, you can manually enter recovery mode by navigating to:

https://yoursite.com/wp-login.php?action=entered_recovery_mode

Once inside recovery mode, WordPress shows you which plugin or theme caused the crash. You can deactivate it from the Plugins or Themes screen. Recovery mode only pauses the extension for your browser session. Other visitors still see the critical error until you deactivate or fix the broken code.

When recovery mode does not kick in

Recovery mode does not always work. I have seen it fail in these situations:

• The fatal error occurs in wp-config.php or a must-use plugin (mu-plugin), which loads before the recovery handler
• The error happens in WordPress core files themselves
• The hosting environment blocks the recovery email (common on shared hosts with aggressive email filtering)
• A custom error handler from a security plugin overrides WordPress’s native handler
• The RECOVERY_MODE_EMAIL constant is set to an invalid address

If recovery mode did not trigger, you need to diagnose manually using debug mode and file access.

Enable WP_DEBUG to Find the Exact Error

The critical error message is intentionally vague for security reasons. The actual PHP error with the file path, line number, and error type lives in the debug log. Enabling debug logging is the single most important wordpress critical error fix step because everything else depends on knowing what actually broke.

Access wp-config.php via SFTP, SSH, or your hosting file manager. Find the debug constants and set them:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Setting WP_DEBUG_DISPLAY to false keeps errors out of the frontend. The errors get written to wp-content/debug.log instead. Load the broken page once, then open that log file.

What to look for in the log:

The fatal error entry contains the cause, the file path, and the line number. Pattern examples:

• Fatal error: Uncaught Error: Call to undefined function followed by a plugin path means that plugin calls a function that does not exist (removed in a PHP or WordPress update)
• Fatal error: Allowed memory size of X bytes exhausted means the PHP memory limit was hit
• Parse error: syntax error, unexpected followed by a theme path means broken PHP syntax in a theme file
• Fatal error: Cannot redeclare means two plugins define the same function name

The file path tells you whether the problem is in a plugin (wp-content/plugins/), theme (wp-content/themes/), or WordPress core (wp-includes/ or wp-admin/).

How to Fix a Critical Error Caused by a Plugin

Plugins cause the majority of critical errors. If the debug log points to a file inside wp-content/plugins/, here is the fix process.

If you have recovery mode access:

Log in through the recovery link, go to Plugins, and deactivate the flagged plugin. Test the site. If it loads, the plugin was the problem.

If you have FTP or SSH access but no recovery mode:

Navigate to wp-content/plugins/ and rename the offending plugin folder. For example, rename contact-form-7 to contact-form-7-disabled. WordPress cannot load a plugin it cannot find, so it deactivates automatically.

If you are not sure which plugin is the culprit, rename the entire plugins folder to plugins-disabled. If the site loads, one of those plugins is the problem. Create a fresh plugins folder and move plugins back one at a time, testing after each one.

Using WP-CLI (fastest method if you have SSH):

wp plugin deactivate --all

Then reactivate one at a time:

wp plugin activate plugin-name

After finding the broken plugin:

• Check the plugin’s changelog for a patch that fixes the issue
• Search the plugin’s support forum on wordpress.org for the same error message
• If the plugin has not been updated in over 12 months, start looking for an alternative
• If the error appeared after a WordPress core update, the plugin may need a compatibility patch from its developer

How to Fix a Critical Error From Your Theme

Theme-related critical errors follow the same pattern as plugin errors but affect different files. The debug log will point to a file inside wp-content/themes/your-theme/.

Switch to a default theme to confirm:

Via WP-CLI:

wp theme activate twentytwentyfour

Via SFTP: rename your active theme folder (e.g., my-theme to my-theme-disabled). WordPress falls back to the latest default theme installed.

Via database (if nothing else works):

UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';

If the site loads with a default theme, your theme has the problem. Common theme-related causes I keep running into:

• functions.php syntax errors after a manual code edit (missing semicolon, unclosed bracket, mismatched quotes)
• Calling a plugin function without checking if it exists (e.g., calling a WooCommerce function in a theme that runs even when WooCommerce is deactivated)
• PHP version incompatibility where the theme uses syntax or functions not available in the server’s PHP version
• Child theme conflicts where the child theme overrides a parent theme file that changed structure in an update

WordPress Critical Error Fix for Memory Exhaustion

When PHP runs out of memory mid-execution, WordPress crashes with a critical error. The debug log shows: Fatal error: Allowed memory size of X bytes exhausted.

The default WordPress memory limit is 40MB for frontend and 256MB for admin. Many hosts set PHP memory limits between 64MB and 128MB, which is often too low for plugin-heavy sites.

Increase memory in wp-config.php:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Or in php.ini:

memory_limit = 256M

Or in .htaccess (Apache servers):

php_value memory_limit 256M

Increasing memory is a quick fix, but recurring memory exhaustion points to a deeper problem. One plugin consuming 200MB+ on every page load usually means a bug, an infinite loop, or an unoptimized database query. Profile with Query Monitor or New Relic to find the real offender. Throwing more memory at a leaky plugin only delays the next crash.

Fix a Critical Error from PHP Version Incompatibility

PHP version mismatches have become more common as hosts push upgrades to PHP 8.1, 8.2, and 8.3. Older plugins that worked fine on PHP 7.4 can throw fatal errors on PHP 8.x because of stricter type handling, removed functions, and changed default behaviors.

Common PHP 8.x breaking changes that trigger critical errors:

• Passing null to non-nullable internal functions throws a TypeError in PHP 8.1+ (was silently accepted in PHP 7.x)
• Named arguments can conflict with plugins that use call_user_func_array with string keys
• each() function removed in PHP 8.0, breaking plugins that used it for array iteration
• Dynamic properties deprecated in PHP 8.2, generating deprecation notices that can cascade into fatal errors when combined with strict error reporting

How to check your PHP version:

wp cli info

Or create a temporary phpinfo.php file in your root directory:

<?php phpinfo(); ?>

Delete it immediately after checking. Leaving a phpinfo file public exposes server configuration details.

If a PHP upgrade caused the critical error:

Contact your host to temporarily downgrade PHP to the previous version. Then update plugins and themes to versions that support the newer PHP version before upgrading again. This is a safer approach than trying to fix compatibility issues on a crashed site.

How to Restore Corrupted Core Files

If the debug log points to files in wp-includes/ or wp-admin/, WordPress core files are damaged. This happens after failed auto-updates, file permission problems, or sometimes after malware cleanup that accidentally removed core files.

Reinstall core via WP-CLI:

wp core download --force --skip-content

This replaces all core files without touching your wp-content directory. Your plugins, themes, uploads, and configuration stay intact.

Verify file integrity after reinstalling:

wp core verify-checksums

Any file that does not match the official WordPress release checksums is modified or corrupted. If checksums still fail after reinstalling, check file permissions and ownership. The web server user needs read access to all core files.

Preventing Critical Errors Before They Happen

Every wordpress critical error fix teaches the same lesson: the crash was preventable. After resolving hundreds of these across different sites, the pattern is clear. Sites that crash have one thing in common: updates were either neglected or applied without a safety net.

The preventive approach that actually works:

• Take a full snapshot before every update. If something breaks, roll back in under 60 seconds instead of spending hours debugging. This single practice eliminates most emergency situations.
• Update regularly instead of batching. Sites that go months between updates accumulate compatibility gaps. When you finally update 15 plugins at once, the odds of a conflict multiply.
• Monitor error logs continuously. PHP warnings and deprecation notices are the precursors to fatal errors. A warning today becomes a critical error when the next PHP version promotes it to fatal.
• Test PHP version compatibility before upgrading. Check the WordPress PHP compatibility checker or your plugins’ listed requirements before your host upgrades PHP.
• Keep plugin count reasonable. Every active plugin is a potential failure point. Audit quarterly and remove plugins you no longer use.

A solid WordPress maintenance checklist covers all of these items on a regular schedule. The goal is not to prevent all errors forever but to catch problems early and have a rollback plan when they do occur.

When to Stop Troubleshooting and Get Help

Handle the critical error yourself if: you can access the server via SFTP or SSH, the debug log clearly identifies a single plugin or theme, and the fix is straightforward (deactivate, update, or replace).

Get professional help if you are dealing with any of these situations:

• The debug log shows errors in multiple plugins or core files simultaneously
• You fixed one error but another appeared immediately after (cascading failures)
• The critical error appeared without any recent updates or changes (possible security breach)
• Recovery mode does not activate and you cannot access the server
• The site is an emergency situation losing revenue every minute it stays down
• Database errors appear alongside the PHP fatal errors

A critical error with a clear cause in the debug log takes minutes to fix. A critical error with no obvious cause, multiple error sources, or signs of file tampering needs someone who has seen the pattern before and knows where to look next.

Your immediate next step: Enable WP_DEBUG_LOG, load the broken page once, and read the fatal error message in wp-content/debug.log. That single line of text tells you whether this is a five-minute plugin deactivation or something that needs deeper investigation.