"There has been a critical error on this website"

You load your website and instead of your homepage you get a short white page reading "There has been a critical error on this website." Sometimes it adds "Learn more about troubleshooting WordPress." That is the whole message. No detail, no clue, nothing to act on.

It is alarming, but it is also one of the more recoverable WordPress failures. In most cases nothing has been lost: your content is still in the database and your files are still on the server. Something in the PHP code stopped execution, and WordPress is showing you a polite wall instead of a raw error. Here is how to work back to the cause.

What the message actually means

It means a fatal PHP error. Some piece of code, almost always a plugin or theme, tried to do something impossible and PHP halted. Since WordPress 5.2 there is a "fatal error protection" layer that catches this and shows the generic notice instead of exposing error details to the public. That is good for security and unhelpful for you.

The three overwhelmingly common triggers:

• A plugin or theme update that is incompatible with your WordPress version, your PHP version, or another plugin.
• A PHP version change at your host. Hosts upgrade PHP, and older plugins using removed functions die immediately.
• Exhausted memory. The site outgrew its PHP memory limit, often after adding a heavy plugin.

Less common but worth knowing: a corrupted file from a failed update, an edit to a theme file with a syntax error in it, or a compromised site where injected code is broken.

Step 1: check your email

WordPress emails the site administrator address when this happens, and that email is the single most useful thing you have. It usually names the plugin or file responsible, and it contains a recovery mode link.

Recovery mode logs you into wp-admin with the offending plugin paused, so you can deactivate or update it normally. Check the inbox for the admin email address on the site, and check spam. If that email arrived, you may be done in two minutes.

Step 2: turn on the error log

If there is no email, get the real error yourself. Using your host's file manager or FTP, edit wp-config.php and find the line mentioning WP_DEBUG. Set up logging like this, above the "That's all, stop editing" comment:

• Set WP_DEBUG to true.
• Set WP_DEBUG_LOG to true, which writes errors to wp-content/debug.log.
• Set WP_DEBUG_DISPLAY to false, so visitors do not see the errors.

Reload the site, then open wp-content/debug.log. The last entries will name a file path. That path tells you which plugin or theme is responsible, which is the whole battle. Turn WP_DEBUG back off when you are finished, because leaving it on is a security and performance problem.

Step 3: rule out plugins

If you cannot get into wp-admin at all, you can still deactivate plugins from outside WordPress. Over FTP or your host's file manager, go to wp-content and rename the plugins folder to something like plugins-off. WordPress will not find any plugins and will deactivate them all.

1. Rename wp-content/plugins to plugins-off, then load your site.
2. If the site comes back, a plugin is your culprit. Rename the folder back to plugins.
3. Now go into wp-content/plugins and rename individual plugin folders one at a time, checking the site after each, until the site recovers. The last one you renamed is the problem.
4. If the site is still broken with all plugins disabled, move on to the theme.

Step 4: rule out the theme

The equivalent trick works for themes. In wp-content/themes, rename your active theme's folder. WordPress will fall back to a default theme such as Twenty Twenty-Four if one is present. If the site loads, the theme, or more often a customization in the theme, is the cause.

This is also where badly done edits show up. If someone recently pasted a snippet into functions.php, that is a prime suspect. A single missing semicolon or brace there will take down the entire site.

Step 5: check PHP version and memory

If plugins and theme are both clear, look at the environment.

• PHP version. In your hosting control panel, see whether PHP was recently changed. If it jumped to a much newer version, an old plugin or theme may not survive it. Reverting temporarily gets you online while you plan a proper update.
• Memory limit. "Allowed memory size exhausted" in your debug log means exactly what it says. The memory limit can be raised in wp-config.php or by your host, though a site that suddenly needs far more memory is usually telling you something else is wrong.
• Disk space. A full account causes failures that look like everything else. Worth thirty seconds to check.

Step 6: restore, if it comes to that

If you have a recent backup and the site has been down long enough to be costing you real business, restoring is a legitimate and often the fastest answer. Restore to the most recent point before the failure, then work out the cause on a copy rather than on your live site.

This is also the moment when people discover that the backup they were counting on does not exist, or has never been tested. If that is you, fix that first once the site is back.

What not to do

• Do not reinstall WordPress over the top hoping it heals itself. Core files are rarely the problem, and you can make recovery harder.
• Do not delete wp-content. Your uploads, themes, and plugins all live there.
• Do not update everything at once as a fix. If an update caused this, more updates are more variables.
• Do not leave debug display on. Public PHP errors leak file paths and are useful to attackers.

How to not be here again

• Automated offsite backups, tested. A backup you have never restored from is a hope, not a plan.
• A staging site. Apply updates to a copy first and look at it before it reaches customers. This is the exact problem our own WordPress plugin, Migro, was built to handle.
• Deliberate updates. Automatic updates of everything, unattended, is how sites break at 3am on a Saturday.
• Fewer plugins. Every plugin is code from a stranger with permission to halt your website.

If you would rather not do any of this

All of the above is doable, and none of it is fun while your site is down and the phone is not ringing. If you would rather hand it over, that is what we do. We read the logs, find the actual cause, fix it, and tell you in plain English what happened and how to stop it recurring.