WordPress

There Has Been a Critical Error on This Website (WordPress Fix)

Reviewed Difficulty: Intermediate Risk: Low

This guide has been written and checked for accuracy but not yet re-verified in a single named environment. The steps are standard and safe; where a step carries risk it is flagged inline.

Quick answer: “There has been a critical error on this website” means a PHP fatal error stopped the page from finishing. WordPress hides the detail for security. To see what actually broke, turn on the debug log, reload the page, and read the last error. Nine times out of ten it names a specific plugin or theme file. Deactivate that one thing and the site comes back.

What this error actually means

WordPress runs on PHP. When PHP hits something it cannot recover from — a missing function, a call to code that no longer exists, memory running out mid-request — it stops. Rather than show a visitor a wall of code, WordPress catches the failure and prints a single generic sentence instead. Since WordPress 5.2 that sentence is “There has been a critical error on this website.”

The message is deliberately vague. It is the same sentence whether a plugin update went wrong, your theme calls a function that PHP 8 removed, or the server ran out of memory. That is why the fix is never “click here” — it is “find out which of those happened, then undo that one thing.”

If you have access to the site’s admin email, check your inbox. WordPress usually sends a message titled “Your Site is Experiencing a Technical Issue” that often names the exact plugin and line of code. That email also contains a special recovery-mode link that logs you in even when the front end is down. If you have it, start there.

Before you change anything: back up

Take a backup first. Every step below is reversible, but only if you can get back to where you started. If you can reach your hosting file manager or FTP, copy the wp-content folder and export the database before touching anything. If the site is completely down and you cannot back up, at minimum note every change you make so you can undo it in order.

Step 1: Turn on the debug log so you can see the real error

This is the step most guides skip, and it is the one that actually solves the problem. You are going to ask WordPress to write the hidden error to a file instead of swallowing it.

Open wp-config.php in your site’s root folder, using your host’s file manager or FTP. Find this line:

/* That's all, stop editing! Happy publishing. */

Directly above it, add:

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

Save the file, then reload the broken page once. WordPress will write the error to wp-content/debug.log. Open that file and scroll to the very bottom — the last PHP Fatal error: line is your culprit. It looks something like this:

PHP Fatal error:  Uncaught Error: Call to undefined function acf_get_field()
in /wp-content/themes/yourtheme/functions.php:214

That line tells you the file and often the plugin or theme responsible. In the example above, the theme is calling an Advanced Custom Fields function while ACF is inactive or missing. Keep that filename — it drives every step from here.

Set WP_DEBUG_DISPLAY to false, as shown. Without it, the raw error prints on your live pages for every visitor to see, which can leak file paths. Log to the file, not the screen.

Step 2: Match the error to its cause

The fatal error line points at a file path. Where it points tells you what to do:

  • Path contains /plugins/some-plugin/ — that plugin is the problem. Go to Step 3.
  • Path contains /themes/your-theme/ — your theme, or code you added to it, is the problem. Go to Step 4.
  • Message says Allowed memory size exhausted — you ran out of PHP memory. Go to Step 5.
  • Message mentions a function and PHP version, or you just changed PHP versions — a compatibility break. Go to Step 6.

Step 3: A plugin caused it

If you can still reach wp-admin, go to Plugins, deactivate the plugin named in the log, and reload the site. If it comes back, that plugin is the cause — leave it off, then look for an update, an alternative, or a support ticket with its developer.

If the error locks you out of the admin too, deactivate the plugin manually:

  1. Open your host’s file manager or FTP and go to wp-content/plugins/.
  2. Rename the offending plugin’s folder — for example woocommerce to woocommerce-off.
  3. Reload the site. Renaming the folder forces WordPress to deactivate it.

If you do not know which plugin, rename the entire plugins folder to plugins-off, which disables all of them at once. If the site returns, rename it back, then disable plugins one at a time until the error reappears. The last one you disabled is the cause.

Step 4: The theme caused it

If the log points at your theme, the quickest test is to switch to a default theme. From the admin, activate Twenty Twenty-Four (or any default). If the error clears, the problem is in your theme.

Locked out? Do it over FTP: go to wp-content/themes/ and rename your active theme’s folder. WordPress falls back to any available default theme automatically. If no default theme is installed, upload one first, or the site will simply show a different error.

If the error only started after you pasted code into functions.php or a code-snippets plugin, that snippet is the cause. Remove it. A single stray character in custom PHP is the most common self-inflicted version of this error.

Step 5: The site ran out of memory

If the log says Allowed memory size of NNN bytes exhausted, PHP hit its memory ceiling. Raise it in wp-config.php, again above the “stop editing” line:

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

If that does not hold, your host caps memory at the server level and you will need to raise it in php.ini or ask your host to. Be aware, though: a plugin that exhausts 256 MB rendering one page usually has a deeper problem. Raising the limit is a valid fix for a genuinely heavy site, but if memory use climbs without end, treat it as a symptom and find the plugin behind it rather than raising the ceiling forever.

Step 6: It broke after a PHP version change

If your host upgraded PHP, or you changed it in your hosting panel, older code can suddenly fatal. Functions that were merely discouraged in PHP 7 were removed in PHP 8, and a plugin or theme that has not been updated in a few years will call one and crash.

The safe move is to switch PHP back to the previous version in your hosting panel — most hosts let you do this in one click — which brings the site straight back up. That is a breathing space, not a cure: PHP 7 is end-of-life and unsupported. Use the working site to update every plugin and theme, then move PHP forward again and retest.

What to do when it still will not come back

If you have worked through the steps and the error persists, check these in order:

  • The debug log is empty or missing. Your host may store logs elsewhere, or file writing may be blocked. Look for an error log in your hosting panel instead — cPanel, hPanel, and most managed hosts expose one.
  • Renaming the plugins folder changed nothing. The fault is more likely the theme, the WordPress core files, or the database. Re-upload fresh copies of wp-admin and wp-includes from a clean WordPress download — this never touches your content.
  • Two plugins conflict. Occasionally no single plugin is at fault; two of them clash. If disabling everything fixes it but no single reactivation reproduces it, reactivate in pairs to find the combination.

Rollback: undoing the debug changes

Once the site is healthy, reverse the diagnostic changes so you are not logging errors forever. Remove the four debug lines you added to wp-config.php, and delete wp-content/debug.log since it can contain file paths you would rather not leave readable. Any plugin folders you renamed to test can be renamed back or left off, as you decided.

How to stop it happening again

  • Update on staging, not live. Most of these errors arrive with an update. A staging copy catches them before your visitors do.
  • Keep a recent backup. The difference between a five-minute rollback and a lost day is whether last night’s backup exists.
  • Stay on a supported PHP version and keep plugins current, so a future PHP bump does not fatal on abandoned code.
  • Know where your host’s error log lives before you need it. Finding it mid-outage costs time you do not have.

Frequently asked questions

Will I lose my content fixing this?

No. Every step here — debug logging, deactivating plugins, switching themes, re-uploading core files — leaves your posts, pages, and uploads untouched. Your content lives in the database and the uploads folder, neither of which these steps modify. The one rule is to back up first anyway, because “should be safe” and “is safe” are different when a site is already broken.

Why does WordPress not just tell me the error?

Showing a raw PHP error to every visitor would leak your server’s file paths and structure, which is useful to an attacker. Hiding it is a security decision. The debug log is how you, the owner, see the detail that visitors should not.

The error only shows on wp-admin, not the front end. Why?

The admin loads different code than the front end — different plugins hook in, and admin-only features run. An error that only appears in the dashboard usually points at a plugin’s admin-side code or a permissions problem, but the debug-log method finds it the same way.

I do not have FTP or file manager access. What now?

Check for the WordPress recovery-mode email described at the top — it can log you in without file access. Failing that, this is the point to ask your host’s support to enable debugging or restore a backup, or to send the details to a developer who can.