“There has been a critical error on this website.” If that sentence replaced your home page right after you clicked Update, the site is not gone. WordPress hit a fatal PHP error and stopped loading the page so it would not show broken output. The fix is to find which piece of code caused it.
What the error actually means
WordPress runs on PHP. When a plugin, theme, or WordPress core calls a function that doesn’t exist, runs out of memory, or uses syntax the server’s PHP version doesn’t support, PHP stops with a fatal error. Since WordPress 5.2, instead of a blank white screen you see the “critical error” message, and the site administrator is sent an email with details.
After an update, the cause is almost always one of these:
- A plugin update that conflicts with another plugin or with your theme.
- A theme or plugin that needs a newer (or older) PHP version than your hosting runs.
- An update that only partly finished, leaving mismatched files.
- Custom code in the theme’s
functions.phpthat relied on something the update changed.
Step 1: check the admin email
Open the inbox for the site’s admin email address and look for a message titled “Your Site is Experiencing a Technical Issue.” It names the plugin or theme that caused the error and includes a recovery mode link. Recovery mode lets you log in to the dashboard with the faulty plugin paused, so you can deactivate it or roll it back.
If the email arrived, this is often the whole fix: log in through the link, deactivate the named plugin, and confirm the site loads.
Step 2: turn on the debug log
If there is no email, find the error yourself. Using your host’s file manager or SFTP, open wp-config.php and add these lines above the line that says “That’s all, stop editing”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reload the broken page, then open wp-content/debug.log. The last “PHP Fatal error” line names the file and line number, and the folder path tells you which plugin or theme it belongs to. Many hosts also show the same error in their PHP error log.
When you are done, set WP_DEBUG back to false. Leaving debug mode on in production can expose file paths to visitors.
Step 3: disable the plugin or theme without the dashboard
If you can’t reach the dashboard, rename the plugin’s folder in wp-content/plugins/ (for example, add -off to the end). WordPress deactivates a plugin it can’t find. If you don’t know which plugin it is, rename the whole plugins folder, confirm the site loads, rename it back, and re-enable plugins one at a time.
For a theme, rename its folder in wp-content/themes/ and WordPress falls back to a default theme, as long as one is installed.
Step 4: check the PHP version
If the log mentions syntax errors or undefined functions in code that hasn’t changed, compare the plugin’s required PHP version (on its WordPress.org page or changelog) with the version in your hosting control panel. Older plugins can break on PHP 8, and some new plugins require it. Change the PHP version only after taking a backup, and test the whole site afterwards.
Step 5: restore a backup if you need to
If the site is a store or takes bookings and every minute counts, restoring the most recent backup is a legitimate first move. Then repeat the update on a staging copy to find the conflict without customers watching.
How to avoid this next time
- Take a full backup (files and database) before updating anything.
- Update plugins one at a time, or in small groups, so you know which one caused a problem.
- Test major updates on a staging copy first, especially WooCommerce, page builders, and anything that touches checkout.
- Keep PHP on a version your plugins and theme support.
- Remove plugins you no longer use. Fewer plugins means fewer conflicts.
If you would rather not do this yourself, this is one of the most common fixes DR3 handles: find the cause in the logs, fix it properly, and check the rest of the site before handing it back.