A plugin update broke my site. Here is how to fix it

Step 1: Work out what you are actually looking at

The symptom tells you where to start.

• White screen, no text: a PHP fatal error with error display turned off. Most common outcome of a bad plugin update.
• "There has been a critical error on this website": the same thing, with WordPress recovery mode engaged. Check the site's admin email inbox, WordPress may have sent a recovery link that logs you in with the offending plugin paused.
• Site loads but is visually broken: usually a CSS or JavaScript conflict rather than a fatal error. Less urgent, and often fixable by clearing caches first.
• Admin works but the front end is broken, or the reverse: narrows the problem to code loading in only one context.
• 500 error: could be PHP, could be a server configuration issue, could be a memory limit. Check the server error log.

Step 2: Get access back

If you can still reach wp-admin, go to step 3. If you cannot, you need file access via SFTP, your host's file manager, or SSH.

Rename the plugin folder. Navigate to /wp-content/plugins/, find the folder for the plugin you just updated, and rename it, for example from plugin-name to plugin-name-off. WordPress cannot find the plugin, deactivates it automatically, and the site usually comes back immediately.

If you are not sure which plugin caused it, rename the entire plugins folder to plugins-off. That disables everything. Create a new empty folder named plugins, and the site should load. Then move plugins back one at a time to find the culprit.

Step 3: Confirm the WordPress plugin update broke site behaviour

Turn on error logging rather than guessing. In wp-config.php, above the line that says stop editing:

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

Reload the site, then read /wp-content/debug.log. The fatal error names the file and line number, which usually identifies both the plugin and the reason. Turn debugging off again afterwards.

Common causes, roughly in order of frequency: a PHP version requirement the host does not meet, a conflict between two plugins competing for the same hook, a plugin that requires a newer WordPress core version, a memory limit exhausted by a heavier release, and a plugin whose update assumed a premium add-on that has not been updated.

Step 4: Roll back the plugin version

Once you know which plugin, the fastest fix is going back to the version that worked.

1. Download the previous version. For plugins in the WordPress repository, go to the plugin page, open Advanced View, and download an earlier release from the developer section. For premium plugins, check your account area.
2. Deactivate and delete the broken version through wp-admin, or via SFTP if you cannot reach the admin.
3. Upload and activate the older version.
4. Disable automatic updates for that plugin, otherwise WordPress will helpfully reapply the broken version and you will do this again.

Then tell the developer. A clear report with the error log, PHP version and conflicting plugin is genuinely useful to them, and the fix usually appears in the next release.

Step 5: If the site is still broken

Switch to a default theme temporarily to rule out a theme conflict. Rename your theme folder and WordPress falls back to a bundled default. If the site recovers, the conflict is between the plugin update and your theme.

If nothing works, restore from backup. A restore is not a defeat, it is the correct action when diagnosis is taking longer than the outage justifies. Restore, verify the site works, then investigate on a staging copy where nobody is watching.

Step 6: Make sure it does not happen again

Everything above is recovery. This is the part that matters, and it is the same five things every time:

1. Take a restore point immediately before every update, not last night's scheduled backup. Rollback should lose nothing.
2. Test risky updates on staging first. Major version jumps, page builders, anything touching checkout or payment.
3. Check the result afterwards. A site returning HTTP 200 can still be displaying a broken layout. Something has to actually look at the page.
4. Do not update everything at once on a live site. If you must batch, batch by risk, and never on a Friday.
5. Never turn automatic updates off entirely. The alternative failure mode, running a known-vulnerable plugin version for six months, is considerably worse than a broken layout.

That list is difficult to follow consistently by hand across even a handful of sites, which is precisely why it does not get followed. Automating the sequence is what makes it actually happen every time rather than when there is time.