How to fix “There has been a critical error on this website”, step by step

Every few weeks someone lands on this site with the same screenshot: a white page, one line of grey text, and a business that has just gone offline. The screen looks final. It isn’t. It means PHP crashed while building the page, almost always because a plugin or theme threw a fatal error after an update, and WordPress chose to show you a polite box instead of the raw error. Here is the order I work through, easiest first, and the point where I’d stop and hand it over.

Step 01 Open the recovery-mode email

Since WordPress 5.2, every fatal error triggers an email to the site’s admin address with the subject Your Site is Experiencing a Technical Issue. It names the plugin or theme that crashed and includes a link that logs you into wp-admin in recovery mode, with the broken plugin paused. Search your inbox (and spam) for that subject line.

Click the link, go to Plugins, and you’ll see the culprit flagged. Deactivate it. Your site is back. Then decide whether to update it, replace it, or ask its developer what went wrong.

Plain English The email is WordPress saying “this one broke, here’s a side door”. If you have it, you rarely need the rest of this post.

Step 02 Turn on debug logging to read the error

The screen hides the actual error on purpose. To see it, open wp-config.php in your host’s file manager (cPanel, Plesk, or your host’s own dashboard) or over FTP, and above the line that says /* That's all, stop editing! */ add:

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

Reload the broken page once, then open wp-content/debug.log. The last lines will read something like PHP Fatal error: Uncaught Error … in /wp-content/plugins/some-plugin/includes/file.php on line 212. The folder name after plugins/ or themes/ is your answer.

Before you move on Set WP_DEBUG back to false when you’re done. Leaving it on writes to disk on every request and can leak file paths to visitors.

Step 03 Deactivate all plugins via FTP

You can’t reach wp-admin, so we do it from the file system. In wp-content/, rename the plugins folder to plugins-off. WordPress treats every plugin as deactivated. Reload the site.

1. If the site comes back, rename the folder to plugins again. Nothing is lost; every plugin is now simply inactive.
2. In wp-admin, activate plugins one at a time, reloading the front end after each. The one that brings the error back is the culprit.
3. Delete it or update it. If it’s essential, its changelog or support forum usually already has the fix, because you are rarely the first.

If step 02 gave you a name, rename only that plugin’s folder (some-plugin to some-plugin-off) and skip the elimination round.

Step 04 Switch to a default theme

Same trick, one folder deeper. In wp-content/themes/, rename your active theme’s folder. WordPress falls back to the newest default theme it can find (Twenty Twenty-Five, for example). If no default theme is installed, upload one from wordpress.org first, or the fallback has nothing to fall back to.

If the site loads on the default theme, the crash is inside your theme: usually functions.php after an edit, or a theme that never got updated for the PHP version your host quietly moved you to.

Step 05 Raise the PHP memory limit

If debug.log said Allowed memory size of 134217728 bytes exhausted, this is your step. In wp-config.php, above the “stop editing” line:

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

Hosts cap this. If 256M doesn’t take, the change has to be made in php.ini or your hosting panel. It’s a patch, not a cure: something is eating that memory, and step 03 usually tells you what.

Step 06 Re-upload WordPress core

A failed automatic update or a partial hack can leave core files corrupted. Download the same WordPress version from wordpress.org, unzip it, and upload only the wp-admin and wp-includes folders, overwriting what’s there. Do not upload wp-content; that’s your site. Do not overwrite wp-config.php; that’s your database connection.

Plain English You’re replacing the engine, not the furniture. If you feel unsure about which folder is which, stop and take a full backup first.

Step 07 Check the PHP version and the database

Two things left. First, PHP: hosts move sites between PHP versions, and an old theme on PHP 8.3 fatals on the first deprecated function it hits. Your hosting panel has a PHP version selector; try one version down, load the site, and note it as a debt to pay later, not a fix. Second, the database: if debug.log mentions Table … is marked as crashed, add define( 'WP_ALLOW_REPAIR', true ); to wp-config.php, visit /wp-admin/maint/repair.php, run the repair, then remove the line.

If you’re still reading, the error is somewhere a post can’t see from here: a server-level issue, a compromised site, or a chain of plugins that only fails together. That is where I’d stop trying and get someone to look at the actual logs. It is also, not by coincidence, the fatal-error rescue I do most weeks.