Skip to content
Website Rescue Rescue

Plugin Errors

WordPress Plugin Update Broke My Website

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

A plugin update introduced incompatible or broken PHP code. Disable that plugin (from wp-admin if possible, otherwise by renaming its folder via FTP), restore the site, then roll back or replace the plugin before updating anything else.

When a WordPress plugin update takes the site down, you usually see a critical error, white screen, or HTTP 500 right after the update finishes. The posts and settings are still in the database—the immediate job is to stop loading the new plugin code. This guide covers safe isolation, rollback, cache clearing, and how to update plugins next time without another outage.

Intermediate

What the error means

Plugin updates replace PHP and assets under wp-content/plugins/plugin-slug/. If the new version fatals on your PHP or WordPress version, conflicts with another active plugin or the theme, ships a bad release, or leaves mixed old/new files after a partial update, WordPress may stop loading entirely. Auto-updates and bulk “Update plugins” runs make it harder to know which slug broke first. Until that plugin is deactivated or rolled back, recovery mode, FTP renames, and error logs are the reliable path—not installing more plugins on a live outage.

Common symptoms

  • Site broke immediately after clicking Update on one plugin or a bulk plugin update
  • Critical error message, white screen of death, or HTTP 500 on the front end and/or wp-admin
  • Only certain features fail (checkout, forms, page builder, login) while other pages still load
  • Admin recovery email names the plugin you just updated
  • wp-content/debug.log or the host PHP log points to a file inside the updated plugin folder
  • Plugin list shows the new version number, but the site only recovers when that plugin is off

Most likely causes

  1. 01 New plugin version incompatible with current PHP (especially PHP 8.0+ type and dynamic-property fatals)
  2. 02 Conflict between the updated plugin and another active plugin or the active theme
  3. 03 Incomplete update leaving a mix of old and new files in the plugin directory
  4. 04 Plugin now requires a newer WordPress (or companion add-on) version than you are running
  5. 05 License check, remote API call, or database migration step in the update failed mid-way
  6. 06 Page/object/opcode cache still serving broken bytecode or cached error pages after a partial update

What changed before the problem started

  • Manual plugin update from Plugins or Dashboard → Updates
  • Automatic background plugin updates overnight
  • Bulk update of several plugins in one click
  • Update paired with a WordPress core or PHP change the same day
  • Staging sync or deploy that pushed newer plugin files to production

Troubleshooting steps

  1. 01

    Deactivate the updated plugin from wp-admin if you still have access

    Go to Plugins → Installed Plugins, find the plugin you just updated, and click Deactivate. Reload the front end in a private window. If the site recovers, leave it inactive for now. Purge any page-cache plugin and CDN cache so visitors are not still served the broken state. Success signal: homepage and key templates load with that plugin off.

  2. 02

    Rename the plugin folder via FTP or file manager

    If wp-admin is down, open wp-content/plugins/ in SFTP/FTP or the host File Manager. Locate the plugin’s directory (match the slug from the update screen or error log) and rename it to plugin-slug.disabled. WordPress will stop loading it. Confirm / and /wp-login.php work again. Success signal: critical error/WSOD/500 is gone after the rename alone.

  3. 03

    If multiple plugins updated, disable newest first by timestamp

    Sort plugin folders by modified time in the file manager, or note which plugins updated in the same batch. Disable (rename) the most recently changed plugin first, reload, then the next, until the site loads. Re-enable the safe ones one at a time with a front-end check after each. Success signal: you can name the single plugin whose disable restores the site.

  4. 04

    Confirm the culprit in the error log before reactivating anything

    Open the PHP error log or enable WP_DEBUG_LOG briefly and match “Fatal error” lines to a path under wp-content/plugins/. Do not reactivate that plugin until you have a previous zip, vendor hotfix, or confirmed compatible version. Success signal: log path and the folder you renamed agree on the same slug.

  5. 05

    Roll back to the last known-good plugin version

    Restore the previous plugin folder from a backup, or upload the prior version zip from the vendor’s archive / wordpress.org older releases when available. Avoid deleting the folder until you have that zip. Test forms, checkout, login, and any builder you rely on. Success signal: site stable on the older version with no fatals in the log after a few page loads.

  6. 06

    Pause further updates until staging is ready

    Turn off auto-updates for the broken plugin (and other high-risk plugins) under Plugins or with your update-control workflow. Schedule the next attempt on a staging clone with the same PHP and WordPress versions. Success signal: production stays on the rolled-back version; staging is where you retry the new release.

When to stop troubleshooting

Pause if you cannot access files, you keep disabling the wrong plugin, database migration damage is suspected, malware-looking files appear in the plugin folder, or the site is a live store mid-promotion. Hand off with the plugin slug, from/to versions, update time, log lines, and backup timestamp rather than stacking more updates on production.

Information to collect before requesting help

  • 01 Plugin name, folder slug, and version you updated from and to
  • 02 Whether wp-admin still loads
  • 03 Exact error presentation (critical error, WSOD, 500) plus screenshot
  • 04 PHP version and WordPress version
  • 05 Error log lines naming the plugin file path
  • 06 List of other plugins updated in the same batch and their timestamps
  • 07 Backup availability from before the update (files and database)

How a professional repairs the problem

We identify the failing plugin from logs or update timestamps, then isolate it without wiping your entire plugin stack—usually a targeted folder rename or recovery-mode deactivate. After front-end and admin access return, we roll back or patch to a compatible release, flush caches, and verify critical journeys (home, login, forms, checkout). Finally we document a safer update process: staging first, selective auto-updates, and PHP/WordPress compatibility notes so the next release does not take production down again.

Frequently asked questions

Will disabling the plugin delete my content? +
Disabling stops the plugin’s PHP from running. Posts, pages, and most settings remain in the database. Some shortcodes or blocks may show raw tags until you reactivate a working version or replace the feature.
Can I update all plugins at once safely? +
Bulk updates are the fastest way to take a site down and the hardest to bisect afterward. Update high-risk plugins (security, page builders, WooCommerce, caching, SEO) one at a time with a backup between each, preferably on staging first.
Auto-updates broke my site—should I turn them off? +
Keep auto-updates for trusted, low-surface security plugins if you have reliable backups and monitoring. Disable auto-updates for complex commerce, builder, membership, and custom plugins until you have a staging workflow.
Why does the site still fail after I renamed the plugin? +
Another plugin in the same batch may also be broken, a must-use plugin may still load, a drop-in may be involved, or cache may be serving old errors. Check logs again, clear all caches, and inspect mu-plugins.
Is this different from a theme update failure? +
The recovery pattern is similar—isolate the last changed code—but theme files live under wp-content/themes/. If both a theme and plugins updated, disable the newest change first based on folder timestamps.
Should I delete the plugin folder to fix it faster? +
Prefer renaming over deleting. Renaming preserves files for rollback and comparison. Delete only after you have a replacement zip and a backup, and you are sure you will not need the old files for diagnosis.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.