If you saw "There has been a critical error on this website" immediately after updating WordPress, a plugin, or a theme, you are in one of two situations: fully locked out of both the front end and wp-admin, or partially broken, where the admin loads but the site doesn't (or the reverse). Both are almost always caused by the update itself, most often a plugin that isn't compatible with the new version. WordPress's built-in Recovery Mode exists precisely for this, and this walkthrough covers both situations separately, because they need different first steps.
This guide covers the after-an-update scenario specifically, not every possible cause of a critical error. Because an update just changed something, the suspect list is short and ordered: check the thing that just changed first.
Which situation are you actually in?
Thirty seconds of triage saves you from following the wrong track:
- Track A, fully locked out. Both the front end and wp-admin show the critical error message. No amount of refreshing changes it.
- Track B, partially broken. wp-admin loads fine and you can log in, but the front end shows the error (or, less commonly, the reverse). This is the easier case, because you already have a working diagnostic surface.
Track A: fully locked out, step by step
1. Check your admin email for the recovery link. WordPress's Recovery Mode, part of core since version 5.2, automatically emails the site administrator a special link the moment a fatal error is detected. That email usually names the specific plugin or theme responsible, which saves you the isolation step entirely.
2. Click the link to enter Recovery Mode. This logs you into a special admin session where the plugin or theme that caused the error is automatically paused, without deactivating it permanently or touching any other plugin. From here you can see the affected plugin/theme, deactivate it properly, or switch back to a default theme, then exit Recovery Mode and confirm the site loads.
3. If the email never arrives, there is a manual fallback. Add /wp-login.php?action=entered_recovery_mode to your domain to reach the recovery mode entry screen directly, without waiting on the email. This is worth knowing in advance, because recovery emails can be delayed, filtered as spam, or sent to an inbox you no longer check.
4. If neither the email nor the manual URL gets you in, you'll need your host's file manager or FTP. Navigate to /wp-content/plugins/, and rename the folder of the plugin you suspect (or, if you're not sure which one, rename the entire plugins folder temporarily). WordPress deactivates any plugin whose folder it can't find, which clears the error without deleting anything; renaming it back reactivates it later. This is a files-only change and does not touch your database or your content.
Track B: admin works, front end doesn't (or the reverse)
1. Turn on debug logging, temporarily and safely. Adding define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG', true ); to wp-config.php, alongside define( 'WP_DEBUG_DISPLAY', false ); so errors log to a file instead of appearing on the live page, lets you capture the real error without exposing it to visitors. Back up wp-config.php before editing it; it is a small file, but a single typo in it can cause the exact critical error you're trying to fix. Turn debug logging back off once you've found the answer; leaving it on is not a permanent setting.
2. Read the log at /wp-content/debug.log. Reload the page that's failing, then open the log and look at the newest entries. Look for a plugin folder name, a theme file path, or a specific PHP function in the error text; that is almost always your culprit, named directly.
3. Deactivate the named plugin (or the most recently updated ones, if the log is inconclusive). Deactivating a plugin never deletes its data, so this step is reversible while you confirm which one is responsible.
4. If deactivating plugins doesn't resolve it, the theme is a real second suspect. Switching temporarily to a default WordPress theme isolates whether the problem is plugin-side or theme-side.
Why an update triggers this in the first place
Three causes account for most post-update critical errors: a plugin's code is genuinely incompatible with the new WordPress or PHP version; a half-finished update, often caused by a timeout or a lost connection mid-update, leaves files in an inconsistent state; or a plugin conflicts with another plugin in a way that only surfaces once one of them changes. Checking a plugin's "Tested up to" version on its WordPress.org page before updating is the cheapest way to catch the first cause in advance; our guide to plugins breaking after the WordPress 7.0 update covers that check, along with the wider update-triage process, in more depth.
Turn this fix into prevention
The single habit that prevents most of this: take a full backup, files and database both, before any update, not after something breaks. Update plugins one at a time rather than in a batch, so that if something does go wrong, you already know which change caused it. This applies to the next release too; WordPress 7.1 is scheduled for 2026-08-19, and our rundown of what's changing in 7.1 covers what to check before it lands. If your admin still looks unfamiliar because you recently updated to WordPress 7.0, our walkthrough of the redesigned admin covers where Site Health and the plugin screens now live, which speeds up every step above.
FAQ
Is my content gone if I see a critical error? No. A critical error means a PHP fatal error stopped a page from rendering; it is not a data-loss event on its own, and your posts, pages, and media remain in the database untouched. The fix is almost always deactivating whatever caused the fatal error, not restoring lost content.
How long does recovery mode access last? The recovery mode link in the email is a one-time-use, time-limited link. Once you've used it to log in and resolved the issue, that specific link expires; if you need another one, WordPress sends a new email the next time the same fatal error is detected.
What if I'm still locked out after trying all of Track A? At that point the fault is more likely a corrupted core file than a single plugin. Downloading a fresh copy of WordPress core from WordPress.org and replacing the wp-admin and wp-includes folders plus the loose files in the root, without touching wp-content, replaces damaged core files while leaving your content, plugins, and theme untouched.
Why does this keep happening after every update? If the same critical error recurs across multiple updates, the common cause is usually one specific plugin or a theme that has fallen behind, rather than WordPress itself. Reviewing each plugin's last-updated date and "Tested up to" flag, and retiring anything genuinely abandoned, breaks the cycle more reliably than repeating the same recovery steps each time.
Written against WordPress 7.0.1. Last verified 2026-07-30.
