WordPress 'There has been a critical error on this website'? Why it happens and the fix

First: what changed just before it broke?

Most critical errors appear straight after a change. The answer to this question usually tells you where to look, so you don't have to try every fix.

• You updated or installed a plugin: start with step 2 and that plugin.
• You switched or updated the theme, or edited functions.php: start with step 3.
• Your host moved you to a newer PHP version, or you changed it yourself: see step 5.
• Nothing changed that you know of: automatic updates may have run overnight. Use the recovery email (step 1) or the debug log (step 4) to see which component failed.

Step 1: Use the recovery mode email

Since version 5.2, WordPress has a built-in Recovery Mode. When it catches a fatal error during a normal page load, it emails the site's administrator. The subject reads '[Your site name] Your Site is Experiencing a Technical Issue', and the email names the plugin or theme involved and includes a special login link. It goes to the 'Administration Email Address' set in Settings, unless a developer has set a different recovery address in wp-config.php.

WordPress's documentation describes the steps:

• Click the link in the email. The login screen shows 'Recovery Mode Initialized. Please log in to continue.'
• Log in. The broken plugin or theme is paused only for your session, so you can use the dashboard while visitors still see the error.
• Read the notices that say which plugin or theme failed, then go to 'Plugins' or 'Appearance' then 'Themes' and deactivate it. This is a temporary fix, but the site will load again.
• If you edited code, such as functions.php, correct it before you continue.
• Click 'Exit Recovery Mode' in the admin toolbar and check the site works for everyone.

Step 2: No email? Deactivate plugins from the file manager or FTP

The recovery email often doesn't arrive. WordPress's documentation explains that if the error happens before an email plugin loads, the message is sent straight from your web server, and it may be filtered to spam or blocked if the server's email isn't trusted. By default WordPress also sends at most one recovery email a day, so if you deleted one earlier, another may not come until a day has passed. Check the spam folder of the administration email address, which is often an old address nobody reads.

If there is nothing, you can do the same job by hand. Log in to your hosting control panel and open the file manager, or connect with an FTP program, and go to the wp-content folder of your site.

• If you know which plugin is at fault, rename just its folder. WordPress's documentation gives the example of renaming wp-content/plugins/hello-dolly to hello-dolly-1. That plugin is now switched off.
• If you don't know, rename the whole wp-content/plugins folder to plugins_old. That deactivates every plugin at once.
• Reload your site. If it works, a plugin was the cause.
• Rename the folder back to plugins, log in, and go to 'Plugins'. Reactivate them one at a time, reloading the site after each one. When the error comes back, you have found the culprit.
• Leave that plugin off, then check for an update, a newer version, or contact its developer with the error from step 4.

Step 3: Switch the theme

If turning off plugins didn't help, the theme is next, especially if the error started after a theme update or an edit to functions.php. In the file manager, go to /wp-content/themes/ and rename the folder of the active theme. WordPress then falls back to a default theme, so make sure one of the default 'Twenty' themes is still in that folder. If the site loads, the problem is in the theme. If you edited functions.php, undoing that edit is often the whole fix.

Step 4: Turn on WP_DEBUG and read the actual error

When you can't guess the cause, ask WordPress. Open wp-config.php in the root folder of your site and add these lines above the line that says 'That's all, stop editing!':

• define( 'WP_DEBUG', true ); turns on debug mode.
• define( 'WP_DEBUG_LOG', true ); saves errors to a file called debug.log in the wp-content folder.
• define( 'WP_DEBUG_DISPLAY', false ); and @ini_set( 'display_errors', 0 ); keep the errors off the screen, so visitors don't see them.
• Reload the broken page, then open wp-content/debug.log. Look at the last 'PHP Fatal error' line. The file path in it, such as wp-content/plugins/some-plugin/..., tells you which plugin or theme failed.
• WordPress's handbook says debugging is not recommended on live sites, so remove these lines or set WP_DEBUG back to false once you have what you need.

Step 5: Check the PHP version, memory limit and core files

WordPress currently recommends PHP 8.3 or greater. It still works on PHP 7.4 and up, but those older versions have reached end of life and may expose your site to security problems. Trouble comes from both directions: an old plugin can crash on new PHP, and a new plugin can crash on old PHP. To see your version, go to 'Tools', then 'Site Health', open the 'Info' tab and expand 'Server'.

You change PHP in your hosting control panel, or by asking your host. WordPress's advice is to back up first and update WordPress, themes and plugins before switching. If the critical error started right after a PHP change, switch back, then update the plugin that failed before trying again.

If the debug log says 'Allowed memory size of ... bytes exhausted', the site ran out of memory. WordPress's handbook shows how to raise it in wp-config.php, for example define( 'WP_MEMORY_LIMIT', '96M' );. It also notes that some hosts don't allow this, in which case ask your host to raise the PHP memory limit.

If plugins, theme, PHP and memory all check out, the core files themselves may be damaged, for example by an update that was interrupted. WordPress's handbook suggests re-uploading the wp-admin and wp-includes folders from a fresh download of WordPress. Leave wp-content and wp-config.php alone, because they hold your themes, plugins, uploads and settings. If you are on managed hosting, their support can also read the server's error logs for you.

Prevent it next time

Most critical errors follow an update or a change, so a few habits make them rare and quick to undo.

• Take a backup before updating anything, so a bad update can be undone quickly.
• Update plugins one at a time rather than all at once, and check the site after each.
• Keep the 'Administration Email Address' in Settings pointed at an inbox someone reads, so the recovery email reaches you.
• Before your host changes PHP, update your plugins and theme and test them on a staging copy if your host offers one.
• Remove plugins you don't use. Fewer plugins means fewer things that can conflict.

If you'd rather not maintain WordPress

The steps above are the right fix for now, and often deactivating a single plugin is enough to get the site back. If you'd rather not be the one updating plugins and reading debug logs, OneSol's Max plan ($1 for the first month, then $29/month) builds a small-business website with you on your own domain, with CRM and SEO set up, and we keep it running, so there are no plugins for you to update.