A blank browser window with a warning sign, a cracked gear among plugin blocks and a green wrench

“There has been a critical error on this website”: how to get your WordPress site back

Your site only shows 'There has been a critical error'? How to use the recovery email and debug log to find the plugin or theme behind it.

You open your website and instead of your homepage there is one line of text: “There has been a critical error on this website.” Every visitor sees the same thing. Contact forms do not load, product pages do not load, and often the dashboard is gone too. While the message is up, you are losing every enquiry and sale that would have come in, and if it stays up long enough, Google’s crawler gets the same error when it visits your pages.

The message looks alarming, but it is WordPress protecting itself. Something on the site, almost always a plugin, the theme or a recent change to the server, triggered a fatal PHP error, and WordPress stopped loading rather than show a broken page. Your content is still there. This guide is for site owners who just saw the message, often right after an update, and want the site back without making things worse.

Before you start: two things not to do

  • Do not reinstall WordPress or delete folders to see if it helps. That can remove the very files you need to find the cause, or your uploads.
  • Do not restore an old backup straight away on a store. Restoring the database to yesterday removes every order, customer and change made since. Take a fresh backup of the current files and database first, even though the site is broken, so you can always get back to where you are now.

Step 1: Check your inbox for the recovery email

Since version 5.2, WordPress catches fatal errors and emails the site’s administrator address. The subject reads along the lines of “Your Site is Experiencing a Technical Issue”. On older versions the page message itself said “The site is experiencing technical difficulties” instead.

The email is the fastest route back, because it usually names the plugin or theme that caused the error and the file and line where it happened. It also contains a recovery mode link. That link lets you log in with the faulty plugin or theme paused, so you can reach the dashboard and deactivate it.

  1. Search the inbox of the address in Settings → General → Administration Email Address, including spam.
  2. Click the recovery mode link and log in.
  3. WordPress shows which extension was paused. Deactivate it from the Plugins page, or switch to another theme if the theme was the cause.
  4. Exit recovery mode and check the site in a private window.

Recovery mode pauses the plugin only for you. Visitors still see the error until you actually deactivate it. The link is also only valid for a limited time, and WordPress does not send a fresh email every time the error happens.

If no email arrived, the administrator address may be an old one nobody reads, or your site may not be able to send email at all. That is common, and it is worth fixing later: see why WordPress and WooCommerce emails do not arrive. For now, go to step 2.

Step 2: Think about what changed

Critical errors rarely appear out of nowhere. Before digging into files, ask what happened just before the site broke:

  • A plugin, theme or WordPress update, run by you or by an auto-update
  • A new plugin installed or activated
  • Code added to the theme’s functions.php or a code snippets plugin
  • Your host changing the PHP version, which old plugins and themes often do not survive

If you know the answer, you can usually go straight to step 4 and undo that one change. If not, the debug log will tell you.

Step 3: Turn on the debug log

WordPress can write every error to a log file instead of hiding it. Open wp-config.php in the root of your site through your host’s file manager or FTP. Look for a line that defines WP_DEBUG. If it exists, change it rather than adding a second one, because defining the same setting twice causes its own warning. Then make sure these three lines sit above the line that says “That’s all, stop editing!”:

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

The last line keeps the errors out of the page so visitors do not see them. Reload the broken page once, then open wp-content/debug.log. Look for the most recent line that starts with PHP Fatal error. It looks something like this:

PHP Fatal error:  Uncaught Error: Call to undefined function example_function()
in /home/user/public_html/wp-content/plugins/example-plugin/includes/class-example.php:42

The path is the important part. A path under wp-content/plugins/example-plugin/ points to that plugin. A path under wp-content/themes/ points to your theme. A few messages you are likely to meet:

  • Allowed memory size of … bytes exhausted: the site ran out of PHP memory. Adding define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php often helps, but your host’s own limit still applies, and a plugin that suddenly needs far more memory may have a bug of its own.
  • Call to undefined function or Class not found: a plugin depends on another plugin, or on a newer version of it, that is missing or deactivated.
  • syntax error, unexpected: a typo in code, very often in functions.php after someone pasted a snippet.
  • Cannot redeclare: two plugins, or a plugin and the theme, define the same function.

If your host offers its own PHP error log in the control panel, it shows the same errors and is worth a look when debug.log stays empty.

Step 4: Disable the plugin or theme without the dashboard

Once you know the culprit, you can switch it off even if you cannot log in:

  • One plugin: in the file manager or FTP, go to wp-content/plugins/ and rename the plugin’s folder, for example from example-plugin to example-plugin-off. WordPress can no longer find it and deactivates it.
  • All plugins: if the log does not point anywhere clear, rename the plugins folder itself to plugins-off. If the site comes back, rename it back and switch plugins on again one at a time from the dashboard until the error returns.
  • The theme: rename the active theme’s folder in wp-content/themes/. WordPress falls back to a default theme, such as one of the Twenty themes, if one is installed.
  • With WP-CLI: if your host gives you SSH access, wp plugin deactivate example-plugin --skip-plugins does the same job. The --skip-plugins flag stops the broken plugin from crashing the command too.

This is the step where a wrong move can take a working part of the site down with the broken one, especially on a WooCommerce store where payment and shipping plugins depend on each other. If the log is confusing or the site still does not load, we can find the cause and fix it for you, after taking a full backup.

Step 5: Check the PHP version

If the error started without any update on your side, check the PHP version in your hosting control panel. Hosts move sites to newer PHP versions, and code written for an old version can fail on a new one. Switching back to the previous version brings the site back quickly, but treat it as temporary: update or replace the plugin that failed, then move forward again, because old PHP versions stop receiving security fixes.

Step 6: Fix the cause, not just the symptom

A deactivated plugin is a working site, but it may also be a missing feature: a payment method, a booking form, the shipping rates. Decide what to do with it:

  • Check whether a newer version of the plugin fixes the error, and update it on a staging copy first.
  • If the error started with an update, roll back to the previous version until the developer releases a fix.
  • Send the plugin developer the exact fatal error line from the log. It tells them far more than “my site broke”.
  • If the plugin is abandoned, replace it with a maintained one that does the same job.

When it is not a plugin or the theme

  • A failed update left core files broken. If the log points to files in wp-admin or wp-includes, upload fresh copies of those two folders from the same WordPress version. Never overwrite wp-content or wp-config.php.
  • Files you do not recognise. If the log points to oddly named files, code that looks scrambled, or PHP files inside wp-content/uploads, the site may have been hacked. Cleaning that is a different job: see how to clean a hacked WordPress site.
  • A different message. “Briefly unavailable for scheduled maintenance” is not a critical error. It usually means an interrupted update left a .maintenance file in the site root, and deleting that file brings the site back.

After the fix

Set WP_DEBUG back to false and delete wp-content/debug.log. By default that file can be opened by anyone who knows its address, and it can reveal file paths and plugin details. Then make sure the administrator email address in Settings → General is one you read, so the next recovery email reaches you.

Quick checklist

  • Fresh backup taken before changing anything
  • Recovery email found, or debug log switched on
  • The fatal error line read, and the plugin, theme or file it points to identified
  • That plugin or theme disabled, then updated, rolled back or replaced
  • PHP version checked if nothing else changed
  • Debug log switched off and debug.log deleted
  • Administrator email address is one you read

The sooner the error page comes down, the fewer visitors leave for a competitor’s site and the less chance Google has of noticing anything was wrong.

Related Posts