There Has Been a Critical Error on This Website: What It Means and How to Fix It

That message means PHP hit a fatal error while building your page, and WordPress caught it before it turned into a blank white screen. The error is real, specific, and recorded — WordPress is just refusing to print it in the browser, because a stack trace on a public page leaks file paths and code to anyone who visits.

So the fix is never guesswork. It is: read the actual error, then act on what it says.

What is actually happening

Since WordPress 5.2 there has been a fatal error handler built into core. When PHP dies mid-request, the handler steps in, replaces the crash output with the polite generic sentence, and — if it can work out which plugin or theme caused it — tries to email the site administrator with a link into recovery mode.

That is why you see this instead of the old white screen of death. It is an improvement, but it also means the diagnostic information is hidden by default. Two versions of the message exist:

What you see	Where	What it tells you
”There has been a critical error on this website.”	Front end, logged out	Fatal error occurred, no further detail exposed
The same line plus “Learn more about troubleshooting WordPress”	Front end or wp-admin	Same error, WordPress is offering you the handbook page
”…Please check your site admin email inbox for instructions.”	Front end	The handler believed it sent a recovery email

That third variant is the useful one. It means WordPress attributed the crash to a specific plugin or theme and tried to hand you a way in.

Step 1: check the recovery mode email

WordPress sends the recovery link to the site admin email address — the one in Settings, General — which is often not the address you log in with. Check that inbox, and check spam.

The email contains a long link ending in something like ?action=enter_recovery_mode. Opening it logs you into wp-admin in recovery mode, where the offending plugin or theme is paused and flagged in a red notice at the top. From there you can deactivate it normally.

Two honest caveats. First, the email is generated by the same PHP process that just crashed, on a host that may have no working mail transport at all — non-delivery is common, and its absence tells you nothing about the error. Second, the recovery link expires (roughly a day by default), so an old email in your inbox may simply no longer work; trigger a fresh crash by reloading the site and wait for a new one.

If you want the email to go somewhere you actually read, set it explicitly in wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Step 2: read the real error

This is the step that turns a broken site into a five-minute fix. Add these lines to wp-config.php, above the line that says to stop editing:

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

WP_DEBUG_DISPLAY set to false matters — it keeps the error out of the browser while still writing it to disk, so you are not exposing paths to visitors while you debug.

Reload the broken page once, then open wp-content/debug.log. The last entry will look roughly like this:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

The file path is the answer. If it points into wp-content/plugins/, that plugin is the cause. If it points into wp-content/themes/, it is the theme — very often something recently pasted into functions.php.

If debug.log does not appear, the directory may not be writable, or a security plugin may have moved logging elsewhere. Fall back to your host’s PHP error log — most control panels have an “Error Log” or “Logs” section, and the same fatal error will be there with a timestamp.

Paste the entry into the WordPress error log decoder to translate the PHP wording into what it means in practice and which file to look at first.

Delete these debug lines when you are done. Leaving WP_DEBUG on in production fills the disk and, if WP_DEBUG_DISPLAY ever gets flipped back, prints server paths publicly.

Step 3: get back into wp-admin

If wp-admin is also dead and no recovery email arrived, disable every plugin at the filesystem level. Connect over SFTP (or your host’s file manager) and rename one folder:

mv wp-content/plugins wp-content/plugins-off

WordPress cannot find the plugins, so it deactivates all of them and admin access almost always returns. Then:

1. Rename the folder back to plugins. Everything stays deactivated — WordPress recorded them as inactive.
2. Reactivate plugins one at a time, loading the front end after each.
3. The one that brings the error back is your culprit.

If the site is still broken with every plugin off, the theme is the suspect. Rename the active theme’s folder in wp-content/themes/ and WordPress falls back to a default theme if one is installed.

The three causes worth knowing

A plugin or theme update that fatals. By far the most common. The log names the file directly. Roll that one plugin back to its previous version, or leave it deactivated and contact the developer with the log line.

A PHP version mismatch. Hosts upgrade PHP on a schedule, sometimes without much warning. Code written for older PHP can stop parsing entirely on a newer version. The tell is that nothing changed on your side and everything broke at once. Rolling PHP back one minor version in your hosting panel is a valid diagnostic — but treat it as buying time, not a fix. Old PHP versions stop receiving security patches.

Memory exhaustion. The log says “Allowed memory size of X bytes exhausted”. Raising the limit in wp-config.php is reasonable:

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

Be honest about what that does: it removes the ceiling, it does not fix whatever consumed 256MB rendering one page. If the limit keeps needing to go up, something — usually an import, a page builder, or a badly written query — is the actual problem.

Advice you can safely ignore

“Just increase the memory limit.” Only relevant if the log actually says memory exhausted. Otherwise it changes nothing and hides that you never read the error.

“Reinstall WordPress core.” Core files are rarely the cause, and replacing them wastes time you could spend reading one log line.

“Turn off the fatal error handler.” A constant exists to disable it, and the result is that you get the raw error printed on your public site instead of a caught one. That exposes file paths to visitors. Use WP_DEBUG_LOG with WP_DEBUG_DISPLAY off instead — same information, none of the exposure.

“Clear your cache.” A fatal error happens in PHP before a cache plugin can serve anything. If a cached copy of the error page is being served, clearing helps after you fix the cause — never instead of it.

Still stuck?

If the log points at a core file rather than something in wp-content, the more likely explanation is a plugin loaded earlier that broke the state core relies on, not corrupted core. Turn everything off with the folder rename, confirm the site loads clean, then reintroduce plugins one by one — the last one you enable before the error returns is the one to report, with the log line attached.