WordPress Plugin Update Gone Wrong? Here's What to Do

If a plugin update just broke your WordPress site, stop. Do not make any more changes. Every action you take in the next few minutes either helps or makes recovery harder — and the order matters.

This guide walks you through exactly what to do, in the right sequence, to get back online as fast as possible.

Why Plugin Updates Break WordPress Sites

Plugin updates are the most common cause of WordPress site breakage — not hacks, not hosting failures, not user error. When a plugin developer releases a new version, it may conflict with your current theme, with another plugin, or with your version of WordPress core. These conflicts can cause anything from a minor visual glitch to a full white screen of death where your site is completely inaccessible.

The frustrating part is that this happens even with reputable, well-maintained plugins. A WooCommerce update conflicts with a payment gateway. A page builder update breaks a custom shortcode. A security plugin update locks you out of your own admin panel. None of these are edge cases — they happen to maintained, well-built sites regularly.

The solution is not to avoid updates — outdated plugins are the leading cause of WordPress hacks. The solution is to test updates before they reach your live site. More on that at the end of this guide.

Step 1 — Check if Your Whole Site Is Down or Just Part of It

Knowing which you are dealing with tells you how urgent the fix is and which approach to take first.

• White screen of death — a completely blank white page. This usually means a PHP fatal error caused by a plugin conflict. The site is effectively offline for all visitors.

• 500 Internal Server Error — similar to the above but with an error message. Also likely a plugin conflict or memory limit issue triggered by the update.

• Partial breakage — the site loads but something specific is broken. A checkout button stopped working, a contact form disappeared, a layout section is misaligned. The update caused a conflict but did not take the whole site down.

Step 2 — Deactivate the Plugin That Caused It

If you know which plugin you just updated, deactivate it immediately. This is the fastest path to getting back online.

If you can still access your WordPress admin panel, go to Plugins, find the plugin, and click Deactivate. Then check if your site is back to normal. If it is, you have confirmed the plugin is the cause.

If you cannot access your admin panel because the site is completely down, you need to deactivate via FTP or your hosting file manager. Navigate to wp-content/plugins/ and rename the folder of the problem plugin — for example, change woocommerce to woocommerce-disabled. WordPress will automatically deactivate it on next load because the folder name no longer matches. Rename it back once you have restored access.

If you updated multiple plugins at once and are not sure which caused the problem, rename the entire plugins folder to plugins-disabled. This deactivates all plugins at once and will get your site loading. Then rename it back to plugins, go into your admin panel, and reactivate plugins one at a time until the problem recurs — that is your culprit.

Step 3 — Restore From Backup if Deactivation Does Not Fix It

If deactivating the plugin does not resolve the issue — or if the update caused database changes that need rolling back — you need to restore from a recent backup.

This is where backup quality matters enormously. If your backup is from yesterday and stored off-site, restoration takes minutes and you lose at most 24 hours of changes. If your backup is from last week and stored on the same server that is now experiencing issues, you have a much bigger problem.

To restore from backup, access your backup tool (UpdraftPlus, Jetpack, your hosting panel, or your maintenance provider's backup system) and restore to the most recent backup taken before the update was applied. Most quality backup tools allow you to restore specific components — files only, database only, or both. If the plugin update only changed plugin files and did not touch the database, a files-only restore is faster.

After restoration, verify your site is fully functional before doing anything else.

Step 4 — Check Your Error Logs

If you want to understand exactly what went wrong — either for your own records or to report the issue to the plugin developer — check your PHP error logs.

In your hosting control panel, look for Error Logs under the PHP or Advanced section. Alternatively, add the following to your wp-config.php file temporarily to enable debug logging:

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

This writes errors to wp-content/debug.log where you can read them via FTP. Look for the most recent fatal error — it will tell you exactly which file caused the problem and what the conflict is.

This step is optional for recovery but useful if you want to report the bug or understand whether the plugin is safe to update again once a patched version is released.

Step 5 — Report the Bug and Wait for a Patch

Once your site is back online, report the conflict to the plugin developer. Go to the plugin's page on WordPress.org and open a support thread describing exactly what happened — your WordPress version, the plugin version you updated to, any other plugins that may be involved, and the error message from your logs.

Most reputable plugin developers release a patch within 24-72 hours of a confirmed conflict report. Check the plugin's changelog for an update before reactivating it. When a patched version is available, test it in a staging environment before applying to your live site.

In the meantime, keep the plugin deactivated. Assess whether the functionality it provides is critical — if it is, look for a temporary alternative. If it is not, leaving it deactivated until a patch is available is the safest approach.

How to Prevent This From Happening Again

Every step above is a recovery process. Recovery means your site was already down. The only way to prevent this scenario entirely is to test plugin updates before they reach your live site.

A staging environment is a copy of your site running on a separate URL where updates are applied first. You test the update on staging, confirm everything works, then apply it to live. If the update causes a problem on staging, your live site never goes down. Your visitors never see an error. You fix the issue on staging, wait for a patch, and apply the tested version when it is ready.

This is not a luxury feature reserved for enterprise sites. WPOPS includes staged update testing on the Perform plan from $59/month — every plugin update is applied to a staging copy first, tested, and only pushed live once confirmed working. It is the single most effective change you can make to eliminate update-related downtime.

Without staging, every plugin update is a small gamble. With staging, updates are a controlled, tested process.

What to Do Right Now if Your Site Is Still Down

WPOPS provides emergency WordPress support with under one hour response time on all plans. If your site is down and you need it fixed fast, get in touch via the emergency support page. See our WordPress emergency support guide.

• Try deactivating the most recently updated plugin via your admin panel or FTP

• If that does not work, rename your entire plugins folder via FTP to deactivate all plugins

• If your site is still down after that, restore from your most recent backup

• If you do not have a recent backup or cannot access your hosting, contact your hosting provider or a WordPress emergency support service

Frequently Asked Questions

Why did a WordPress plugin update break my site?

Plugin updates break WordPress sites when the new version conflicts with your theme, another plugin, or your current version of WordPress core. These conflicts cause PHP fatal errors that can result in a white screen of death or 500 error. It happens even with reputable plugins — the only reliable prevention is testing updates on a staging environment before applying them to your live site.

How do I fix a white screen of death after a plugin update?

The fastest fix is to deactivate the plugin that caused the problem. If you can access your WordPress admin panel, go to Plugins and deactivate it there. If your admin panel is inaccessible, connect via FTP, navigate to wp-content/plugins/, and rename the problem plugin's folder. WordPress will automatically deactivate it on next load, restoring your site.

What if I updated multiple plugins and don't know which one broke my site?

Rename your entire wp-content/plugins/ folder to plugins-disabled via FTP. This deactivates all plugins at once and should restore your site. Then rename it back to plugins, go to your admin panel, and reactivate plugins one at a time until the problem recurs — that plugin is the cause.

How do I restore my WordPress site from a backup after a plugin update?

Access your backup tool (UpdraftPlus, Jetpack, your hosting panel, or your maintenance provider's system) and restore to the most recent backup taken before the update was applied. If the update only affected plugin files and not the database, a files-only restore is faster. Always verify your site is fully functional after restoration before making any further changes.

How can I prevent plugin updates from breaking my site in the future?

Set up a staging environment — a copy of your site where updates are tested before being applied to your live site. If an update causes a problem on staging, your live site is never affected. WPOPS includes staged update testing on the Perform plan from $59/month, meaning every plugin update is tested before it reaches your live site.

What should I do if I don't have a backup and my site is down?

Contact your hosting provider first — most hosts keep server-level backups even if you have not configured your own. If your host cannot help, contact a WordPress emergency support service. Going forward, daily off-site backups should be a non-negotiable part of your WordPress maintenance setup. WPOPS includes daily backups on all plans.

Summary

A plugin update breaking your WordPress site is one of the most common technical emergencies site owners face — but it is also one of the most preventable. Deactivate the problem plugin, restore from backup if needed, report the bug, and wait for a patch. Then set up staged update testing so the next update never reaches your live site untested.

The difference between a site that goes down for four hours and one that never goes down is not luck — it is process. staged update testing, daily backups, and a maintenance provider who tests before deploying are the three things that make the difference.

By Manny — Founder, WPOPS