"There has been a critical error on this website": how to fix it

If your site shows "There has been a critical error on this website", PHP has hit a fatal error and WordPress has stopped rendering the page. The message is generic on purpose, but the cause almost never is: it is nearly always one plugin, one theme file, a PHP version mismatch or a memory limit. The fastest fix is to read the actual error from the recovery mode email or from wp-content/debug.log, disable whatever it points at, and then deal with the root cause. Below is the exact order I work in when a client sends me this screen.

What the critical error message actually means

Since WordPress 5.2, core has a fatal error handler. Before that, a fatal error gave you a blank page, the famous WordPress white screen of death. Now WordPress catches the error, shows the "critical error" message to visitors, and emails the site admin address with details and a special login link. On older installs, or when the error happens before the handler loads, you can still get a pure white screen or a bare HTTP 500. The diagnosis is the same either way.

A fatal error means PHP could not continue. Warnings and notices do not cause this screen; something has to be genuinely broken. The usual suspects, roughly in the order I find them:

• A plugin updated and now calls a function or class that does not exist, or conflicts with another plugin.
• A theme or child theme was edited by hand and has a syntax error or a duplicate function.
• The host upgraded PHP (say from 7.4 to 8.2) and old code uses something PHP 8 removed.
• PHP ran out of memory on a heavy admin page, import or page builder screen.
• A half-finished update left files missing, often after a timeout.
• Occasionally, injected malicious code that is badly written and crashes the site.

Step 1: use the WordPress recovery mode email

Check the inbox for the address under Settings → General (the admin email, which is not always your own user's email). Look for a message with a subject like "Your Site is Experiencing a Technical Issue". It tells you which plugin or theme caused the error and includes a link to WordPress recovery mode.

Recovery mode lets you log in to wp-admin with the faulty extension paused for your session only. Visitors still see the error, but you can go to Plugins, deactivate the culprit, and the site comes back. The link expires, and the email is rate-limited (by default WordPress will not resend it for the same issue more than about once a day), so if it went to spam or an old mailbox you may not get another. If the site never sends email reliably in the first place, that is a separate problem worth fixing; my SPF, DKIM and DMARC guide covers why WordPress mail disappears.

Step 2: enable WP_DEBUG_LOG and read debug.log

No email? Go straight to the logs. Connect by SFTP or your host's file manager, open wp-config.php and add these lines above the "That's all, stop editing!" comment:

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

This writes errors to wp-content/debug.log without printing them to visitors. Reload the broken page once, then open the log. You are looking for the most recent line containing PHP Fatal error. Everything above it is usually noise.

Reading the WordPress debug log

Here are the fatal errors I see most often and what each one tells you:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /var/www/html/wp-content/plugins/old-slider/inc/widget.php:42

The path names the plugin (old-slider). create_function() was removed in PHP 8.0, so this is old code on a new PHP version.

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-includes/class-wpdb.php on line 2349

A memory limit problem. The file in the message is just where PHP happened to be when memory ran out, so do not blame wp-includes. 268435456 bytes is 256 MB.

PHP Fatal error:  Cannot redeclare my_custom_function() (previously declared in /wp-content/themes/child/functions.php:15) in /wp-content/plugins/some-plugin/helpers.php on line 8

Two pieces of code define the same function, usually a snippet pasted into functions.php that a plugin later added too.

PHP Parse error:  syntax error, unexpected token "}" in /wp-content/themes/child/functions.php on line 88

A hand edit broke the file. Fix line 88 or restore the file from a backup.

If debug.log stays empty, the error may be logged at server level instead. Check the PHP-FPM or Apache error log (on many servers /var/log/php8.2-fpm.log or /var/log/apache2/error.log), or the "Errors" section of your hosting panel. Remember to set WP_DEBUG back to false when you are done, and delete the log, because it can reveal file paths.

Step 3: deactivate plugins via FTP or WP-CLI

Once you know the culprit, disable it without needing wp-admin. Over SFTP, rename the plugin folder:

wp-content/plugins/old-slider  →  wp-content/plugins/old-slider.off

WordPress cannot find the plugin, deactivates it, and the site loads. If the log is unclear, rename the whole plugins folder to plugins.off, confirm the site loads, rename it back, then disable plugins one at a time.

With SSH access, WP-CLI is faster and cleaner. The --skip-plugins and --skip-themes flags stop WP-CLI itself from loading the broken code:

wp plugin list --skip-plugins --skip-themes
wp plugin deactivate old-slider --skip-plugins --skip-themes
# or, if you do not know which one yet:
wp plugin deactivate --all --skip-plugins --skip-themes

After deactivating everything, reactivate plugins one by one with wp plugin activate name and reload the site after each. The one that brings the error back is your answer. If it is a plugin you cannot live without, the fix is a patch or an update rather than leaving it off; that is routine WordPress plugin and theme bug fixing work. On a WooCommerce store, reactivate WooCommerce first, since so many extensions depend on it.

Step 4: rule out the theme

If the path in the error points into wp-content/themes/, or plugins are all off and the error remains, switch to a default theme:

wp theme list --skip-plugins --skip-themes
wp theme activate twentytwentyfive --skip-plugins --skip-themes

Without SSH, rename the active theme's folder; WordPress falls back to an installed default theme if one exists. That last part matters: if you deleted all the Twenty-something themes to "clean up", upload one first. For a child theme, check functions.php first. In my experience that is where most theme-caused fatal errors live.

Step 5: fix PHP version and memory limit problems

If the error came right after a hosting change, compare your PHP version against what your plugins support. PHP 8 removed or changed plenty that older plugins relied on: create_function(), each(), curly-brace string offsets, and stricter type handling that turns old warnings into fatal TypeErrors. You have two options: update or replace the plugin (the right fix), or temporarily drop to an older PHP version in the hosting panel to get the site up while you do. Do not leave it on an end-of-life PHP version; check the currently recommended version on the WordPress requirements page.

For memory errors, raise the WordPress limit in wp-config.php:

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

WP_MEMORY_LIMIT applies to the front end (WordPress defaults to 40M, 64M on multisite) and WP_MAX_MEMORY_LIMIT to admin screens (default 256M). These cannot exceed the server's own PHP memory_limit, which you set in php.ini or your host's PHP settings. If a site genuinely needs more than 512 MB for a normal page view, raising the limit is hiding a problem: a runaway query, a huge autoloaded option, or a plugin loading far more than it should. That is a performance issue, and it is the kind of thing I dig into on a WordPress speed optimization job.

When the cause is not a plugin or theme

A few less obvious causes I check when the log does not point at an extension:

• Incomplete core update. Run wp core verify-checksums. Missing or modified files in wp-admin or wp-includes mean you should reinstall core with wp core download --force --skip-content.
• A stuck .maintenance file. That shows a different message ("Briefly unavailable for scheduled maintenance"), but it often accompanies a failed update. Delete it from the site root.
• Must-use plugins. Code in wp-content/mu-plugins/ loads regardless of what you deactivate. Hosts put things there, and so do attackers.
• Drop-ins. object-cache.php or advanced-cache.php in wp-content can fatal if the Redis or caching extension they expect is gone after a server move.

If you find obfuscated code, strange files named like wp-conf1g.php, or admin users you did not create, stop treating it as a bug. The site is compromised and needs a proper cleanup; read what to do when your WordPress site is hacked or look at my WordPress malware removal service.

How to stop it happening again

• Test plugin and PHP updates on a staging copy before production, especially on stores and membership sites.
• Keep a restorable backup from before every update round, stored off the server.
• Never edit theme or plugin files in production. Use a child theme and version control.
• Remove plugins that have not been updated in a year or more. They are the ones that break on the next PHP version.
• Make sure the admin email is a real, monitored inbox so the recovery mode email reaches someone.

Most critical errors take ten minutes to fix once you have read the log. If you cannot get SSH or SFTP access, the log points at something you do not understand, or the fix is "rewrite this plugin for PHP 8", that is when it is worth handing over. My WordPress bug fixing service covers exactly this: I find the fatal error, get the site back up, and fix the underlying cause rather than just switching things off. Small jobs like this are billed at $20/hour, and larger fixes get a fixed price agreed in writing before I start.

Frequently asked questions