There has been a critical error on this website: find and fix the WordPress error

Short answer: “There has been a critical error on this website” is WordPress hiding a PHP fatal error, almost always from a plugin, a theme, a PHP version change or the memory limit. Read the real error in the debug log, switch off the plugin or theme it names over SFTP or WP-CLI, then update or replace it.

# 1. The real error (once logging is on, see below)
tail -n 20 wp-content/debug.log

# 2. Switch off the plugin the error names, without loading any plugin or theme
wp plugin deactivate old-slider --skip-plugins --skip-themes

# No idea which one? Note the active ones, switch them all off, re-enable one by one
wp plugin list --status=active --field=name --skip-plugins --skip-themes > active-plugins.txt
wp plugin deactivate --all --skip-plugins --skip-themes

--skip-plugins and --skip-themes matter: WP-CLI loads WordPress, so without them the broken plugin crashes WP-CLI too. Run it as the user that owns the site (sudo -u www-data wp … on a plain Debian or Ubuntu server); WP-CLI refuses to run as root unless you add --allow-root. The WP-CLI commands on this page follow the command reference on developer.wordpress.org.

What the message means

Since WordPress 5.2, a built-in fatal error handler catches PHP errors that stop a page (fatal errors, parse errors, uncaught exceptions) and shows a short page instead of a blank one, with HTTP status 500. The wording depends on where it happened, per WordPress’s class-wp-fatal-error-handler.php (read 21 October 2026):

All of them end with “Learn more about troubleshooting WordPress.” The handler swallows the error message, so the page itself never tells you the cause. It is a 500 Internal Server Error with a WordPress face, and the cause is always in a log.

The recovery mode e-mail

When the error comes from a plugin or a theme, WordPress e-mails a recovery link with the subject [Your Site] Your Site is Experiencing a Technical Issue. It goes to the address in the RECOVERY_MODE_EMAIL constant, or to the site’s admin e-mail. The message names the plugin or theme and the error, including the file and line. The link opens the login page; after you log in, the faulty extension is paused for your session, so you can deactivate it from the Plugins screen. Three details from WordPress’s source explain most missing e-mails:

• It is only sent from the admin side. A fatal error on the public site alone triggers nothing. Open /wp-admin/ or /wp-login.php once, and the e-mail goes out if the error happens there too.
• One e-mail per day. The default rate limit is 24 hours, and the link stays valid at least as long.
• Only for plugins and themes. An error in WordPress core, in wp-config.php, in a must-use plugin or in a network-activated plugin sends nothing.

The pause applies only to your recovery session. Visitors keep seeing the error until you deactivate, update or remove the plugin. And if the server cannot send mail at all, which is common on a fresh VPS without a mail setup, skip the e-mail and read the log.

Find the real error

Turn on WordPress’s own log. Add these lines to wp-config.php, above the line /* That's all, stop editing! Happy publishing. */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );          // writes wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );     // never show errors to visitors
@ini_set( 'display_errors', 0 );

Reload the broken page once, then read the end of wp-content/debug.log. The line you want starts with PHP Fatal error:

[21-Oct-2026 08:14:07 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /var/www/example.com/wp-content/plugins/old-slider/old-slider.php:42

The path names the culprit: wp-content/plugins/<name>/ is a plugin, wp-content/themes/<name>/ a theme, wp-content/mu-plugins/ a must-use plugin, and wp-includes or wp-admin point at core or at whatever called it (read the stack trace lines below the error).

If debug.log stays empty, the error happens before WordPress reads its config, or PHP cannot write the file. Read the server’s logs instead:

sudo grep -h 'PHP Fatal' /var/log/nginx/error.log /var/log/apache2/error.log 2>/dev/null | tail -n 5
ls /var/log/ | grep -i php        # the PHP-FPM log, named after the version

On a hosting panel without a shell, the log viewer of the domain shows the same lines.

What the error line tells you

Cause 1: a plugin

Most critical errors start right after a plugin was installed or updated, or after PHP was upgraded under it. Without WP-CLI, rename the plugin’s folder over SFTP: WordPress no longer finds it and treats it as deactivated.

sftp alice@203.0.113.10
sftp> cd /var/www/example.com/wp-content/plugins
sftp> rename old-slider old-slider.off
sftp> bye

Not sure which plugin it is? Rename the whole plugins folder to plugins.off and check that the site loads. Then open the Plugins screen in wp-admin once: WordPress deactivates every plugin whose files it cannot find. Only now rename the folder back (before that visit, all plugins would still be active and the error would return at once), and re-activate them one at a time until the error comes back. The sftp command guide covers connecting and the other commands; on Plesk hosting the site’s files sit under httpdocs. If all you have is phpMyAdmin, the active_plugins row in the wp_options table holds the list: copy its value somewhere safe, then set it to a:0:{} to deactivate everything. Your table prefix may differ from wp_.

Must-use plugins in wp-content/mu-plugins cannot be deactivated at all; move the file out of the folder.

Cause 2: the theme

When the path in the error points into wp-content/themes, often a functions.php that someone edited, switch to a default theme:

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

# no default theme installed? install one and activate it
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

Any default theme that wp theme list shows will do. Then fix the edit or update the theme. Put custom code in a child theme or a small plugin, so the next theme update does not wipe it and a typo does not take the site down.

Cause 3: the PHP version

A PHP upgrade breaks old plugins, and a plugin update can require a newer PHP than the site has. Check the version the site actually runs in wp-admin under Tools, Site Health, Info, Server, or in your hosting panel; php -v on the command line may show a different version than the web server uses. WordPress.org recommends PHP 8.3 or newer and says WordPress still works on 7.4 and later, which is out of support (as of October 2026, per wordpress.org/about/requirements). Switch back to the previous version to get the site up, update the plugin, then switch forward again.

Extensions are packaged per PHP version on Debian and Ubuntu, so an upgrade to a new version can leave mbstring, gd, intl or zip behind. The 500 error guide shows how to list and install them for the version PHP-FPM runs.

Cause 4: the memory limit

Page builders, imports and image processing can exceed PHP’s memory_limit, which ends in the same critical error. WordPress raises the limit on its own up to WP_MEMORY_LIMIT where PHP allows it, so a line in wp-config.php is often enough:

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

If the error still shows the old number, PHP itself caps it. The PHP memory limit guide explains which file sets it on your server and how high it should go.

Cause 5: damaged WordPress core files

An update that stopped half-way, a full disk during an update or a hacked site can leave core files missing or changed. WP-CLI compares every file with the checksums WordPress.org publishes:

wp core verify-checksums --skip-plugins --skip-themes
wp plugin verify-checksums --all --skip-plugins --skip-themes   # plugins from wordpress.org

Warning: File doesn't verify against checksum: wp-includes/version.php
Error: WordPress installation doesn't verify against checksums.

A clean install answers Success: WordPress installation verifies against checksums. To repair, download the same version again over the existing files. --skip-content leaves out the bundled themes and plugins, and the package has no wp-config.php, so your config and wp-content stay as they are:

wp core download --version="$(wp core version)" --skip-content --force

Without WP-CLI, download the same version from wordpress.org and upload its wp-admin and wp-includes folders and the files in its root over the old ones; the package has no wp-config.php, so yours stays. Never upload a wp-content folder over yours. If verify-checksums reports changed files or files that should not exist and nobody edited core, treat the site as compromised, not just broken.

Cause 6: a failed or automatic update

• Rollback is built in, but limited. Since WordPress 6.3 a failed manual plugin or theme update restores the previous version from a temporary backup in wp-content/upgrade-temp-backup. Since 6.6, a plugin auto-update that causes a fatal error on the home page is rolled back too. An error that only shows on other pages, or in wp-admin, can still get through.
• A leftover .maintenance file in the WordPress root shows “Briefly unavailable for scheduled maintenance. Check back in a minute.” rather than the critical error. WordPress ignores the file once it is ten minutes old; delete it with rm .maintenance or in your SFTP client to end it at once.
• Half-copied plugins after an interrupted update produce Failed opening required errors. Delete the plugin’s folder and install it fresh.

How to keep it from happening again

• Update in a copy first. On our Plesk hosting, the WordPress Toolkit clones a live site into staging, so you can run the update on the copy and push the result back when it works. Daily backups keep up to ten restore points.
• Back up before PHP or plugin updates. On a VPS, take a backup in the panel first, so a bad update is a rollback rather than a rebuild.
• Update one plugin at a time and load the site in between, so the culprit is obvious.
• Make sure the server can send mail and that the admin e-mail is one you read, so the recovery e-mail reaches you.
• Keep the log switched off in normal operation. Turn WP_DEBUG on for a fix, then off again.

Frequently asked