There has been a critical error on this website — how to actually fix it

This message replaced the old "white screen of death" starting in WordPress 5.2. It appears when PHP hits a fatal error — usually an incompatible plugin update, a corrupted theme file, or a PHP version mismatch — and WordPress refuses to render the page rather than exposing the stack trace publicly.

The message itself is intentionally vague. The real diagnostic information is in three places: the fatal-error email WordPress sends to the site admin address, the PHP error log on your host, and (if you enable it) the WP_DEBUG output.

WordPress sends an email to the admin address the moment this error fires. The subject line is "Your Site is Experiencing a Technical Issue" and the body contains the exact plugin or theme filename that crashed, plus a magic recovery link that logs you into wp-admin in safe mode.

Search your inbox (and spam folder) for "technical issue" over the last hour. If you find it, click the recovery link. WordPress boots into a mode where the broken plugin is disabled — deactivate it, replace it, done.

If the admin email is stale or the mail never arrives (common with hosts that don't send outbound mail properly), move to fix #2.

Open wp-config.php via SFTP, File Manager, or your host's control panel. Find the line 'define("WP_DEBUG", false);' and replace it with the four lines below.

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

Reload the broken page. WordPress will write the full PHP fatal error to /wp-content/debug.log — the file tells you the exact plugin file, line number, and error type. Nine times out of ten the fix is obvious from the log line ("Call to undefined function… in /wp-content/plugins/broken-plugin/loader.php on line 42").

Fix the underlying issue, then set WP_DEBUG back to false. Never leave debug on a live site.

If you can't access wp-admin at all and don't have log access, this is the sledgehammer that always works. Connect via SFTP or your host's File Manager. Navigate to /wp-content/. Rename the folder 'plugins' to 'plugins-off'.

Reload the site. It should now load — with every plugin deactivated. Log into wp-admin. Rename 'plugins-off' back to 'plugins'. In wp-admin the plugins are still listed but all inactive. Reactivate them one at a time, reloading the front-end after each. The one that reproduces the error is the culprit — update it, replace it, or roll it back.

Same technique works for themes: rename your active theme's folder, WordPress falls back to the default. If the site loads, the theme was the problem.

If disabling every plugin didn't fix it, the issue is server-side. Two things to check.

PHP version: In your host's control panel (cPanel, Plesk, MyKinsta, SiteGround Tools), check the active PHP version. WordPress 6.5+ needs PHP 7.4 minimum, ideally PHP 8.1 or 8.2. If you're on 7.0-7.3, upgrade — but test on staging first because older themes sometimes break on modern PHP.

Memory limit: Add 'define("WP_MEMORY_LIMIT", "256M");' to wp-config.php just above the '/* That's all, stop editing! */' line. If the fatal error was memory exhaustion, this fixes it immediately.

If the site's a checkout, if it's been down more than 30 minutes, if the debug log shows a database error rather than a plugin error, or if fixing the plugin means editing PHP you don't understand — stop. Every minute a store is down costs money, and one wrong wp-config edit can make it worse.

WebCare Studios runs emergency WordPress rescues from $149 with an 11-minute median first response. If you'd rather have an engineer take it from here, book the emergency slot below and forward the debug.log — we usually have the site back up inside an hour.