WordPress Update Broke Your Site? Fix It Step by Step

You clicked Update. Now the homepage says, “There has been a critical error on this website,” and your first customer of the morning may be looking at the same thing.

If you’re searching “WordPress update broke my site,” start with recovery, not another round of updates. I’ll walk you through getting access back, finding what failed, and checking the bits of your site that can break without showing an error.

WordPress update broke my site - what to do first

Stop clicking Update. Note what you just updated and when. If you updated several plugins together, write down which ones. More changes will make the cause harder to spot.
Check the admin email, including spam. Since WordPress 5.2, its fatal error protection can send a special recovery link. That link lets you log in while the broken plugin or theme is paused. If you get in, look at what WordPress paused before changing anything else.
Match the symptom to the likely fix. A white screen or critical error calls for the debug log and a plugin or theme check. If “Briefly unavailable for scheduled maintenance” won’t go away, connect through SFTP or your host’s file manager and delete the .maintenance file in the WordPress root. Don’t delete a folder with a similar name.
Disable the likely culprit. Use the recovery screen if you have it. If you’re locked out, rename the plugin’s folder as described below. If the trouble started with a theme update, switch to a default theme instead.
Roll back the change. Restore the working plugin or theme version from a backup, or install a previous plugin version if you know which version worked. Check with your host before restoring a whole shop: a full-site restore could replace orders placed since the backup.
Clear the cache and test again. An old cached stylesheet can make a successful update look broken. Clear your site’s cache, plus any hosting or CDN cache you use, then reload the affected page.

Don’t assume the site is fixed just because the homepage loads. A form that stops sending or a checkout that won’t finish can be worse for a small shop than an obvious error.

Find the plugin that broke it

Maybe your search was “plugin update broke my site,” but you can’t get into wp-admin to disable anything. First, check for the recovery email. If there’s no useful email, turn on WordPress debugging through SFTP or your hosting file manager. Open wp-config.php and add or adjust these settings before the line that says to stop editing:

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

Don’t leave duplicate definitions in the file. Reload the broken page, then read wp-content/debug.log. Look at the newest entries for a plugin or theme folder name and the file causing the fatal error. The log is a clue, not a verdict: a conflict can surface inside the plugin that happened to run last.

If you can identify the plugin, rename its folder under wp-content/plugins, for example from plugin-name to plugin-name-off. WordPress won’t find it at its old path, so you can try logging in again. Prefer the command line? With WP-CLI, you can deactivate it:

wp plugin deactivate plugin-name

Once you’re back in, check the version you had before the update. For a plugin available through WP-CLI, a known working version can be installed with:

wp plugin install plugin-name --version=X.Y.Z --force

Replace the placeholder with the actual plugin slug and version. A backup is the other route. Contact Form 7 6.2, for example, caused critical errors on some sites; our Contact Form 7 6.2 recovery guide covers that specific case.

After testing, turn debugging back off: set WP_DEBUG and WP_DEBUG_LOG to false, and remove the generated log when you no longer need it. Error logs can contain details you don’t want left lying around.

When a full backup restore makes sense

If the update changed several things and you can’t isolate the failure, restoring the backup taken just before it may be quicker than guessing. But ask what happened after that backup. New orders? Form submissions? Content edits? Preserve that data before restoring, or get help with a targeted restore. I wouldn’t trade today’s orders for a working homepage without checking first.

Why WordPress updates break sites

Updates usually break a connection between pieces of the site, rather than breaking WordPress in isolation. Common culprits include:

Plugin conflicts: two plugins expect different behaviour from the same feature.
PHP changes: a plugin now needs a newer PHP version, or your host changed PHP and older code can’t run on it.
Theme overrides: a child theme or an outdated WooCommerce template override no longer matches the updated plugin.
Page builder changes: a major version changes how parts of a page are rendered.
Custom code: a snippet in functions.php depends on behaviour that changed.
Long gaps between updates: jumping several versions at once makes conflicts tougher to trace. Old cached CSS or JavaScript can add a broken-looking layout even when the update itself finished.

That last case is why I clear caches before undoing a page builder update. Sometimes the fresh code is fine; visitors are just being served yesterday’s files.

Built-in safety nets and what they miss

WordPress does have guardrails. Version 6.3 added automatic rollback when a manual plugin or theme update fails during installation. Version 6.6 added rollback for plugin auto-updates that cause a fatal error right after updating. Recovery mode can also let an admin back in with the offending plugin or theme paused.

Useful? Yes. A complete test of your business site? No. Those protections won’t spot a mangled layout, a JavaScript error that stops a booking form, or a checkout that lets shoppers browse but won’t take an order.

The WordPress.org plugin update security review checks releases for malicious code, not whether an update works with your theme, PHP version, and other plugins.

Preventing update failures in WordPress

My preferred routine is less dramatic than an emergency repair. Take a backup right before updating, and make sure you know how to restore it. A backup you’ve never tested is a promise you haven’t checked.

For a major page builder, WooCommerce, or theme update, try it on a staging copy first. Read the changelog for major versions and check the plugin’s PHP requirements against your host’s PHP version. Then update one item at a time, not “Update all.” If something goes wrong, you’ll know which change to inspect.

Choose the time, too. Friday evening and the hour before a sale are lousy update windows for a shop. Small plugins and security-focused plugins can be reasonable candidates for auto-updates. I’d handle page builders, WooCommerce, and the theme manually so there’s time to check the result.

If you don’t have time to do that regularly, WordPress maintenance is a practical job to hand off. The point isn’t to avoid updates. Leaving them untouched for months just makes the eventual version jump bigger.

A 10-minute post-update check

Open the site as a visitor, then check the paths that actually matter to your business:

Load the homepage and a page built with your page builder. Look for missing styling or odd spacing.
Send a test form and confirm it arrives where you expect.
For a shop, place a test order and confirm checkout completes.
Log in, open wp-admin, and check that the pages you edit still work.
Check the site again after clearing caches, preferrably in a private browser window.

A 24/7 uptime monitor with a keyword check can flag a white screen quickly. It won’t replace that test order, though. An online checkout page can still be a broken checkout page.

What I’d do today

If your site is broken now, check the recovery email before touching anything else. Once it’s working, put a backup-and-test window on the calendar for the next update. Ten minutes spent checking checkout beats discovering the problem from a customer who couldn’t pay.

WordPress Update Broke Your Site? How to Fix It and Prevent Update Failures