How to update WordPress plugins safely: the order, the checklist, and what to do when an update breaks something
Most WordPress sites break during plugin updates. Not because updates are inherently dangerous, but because most people update everything at once, skip the backup, and have no plan for when something goes wrong. The update itself isn’t the risk. The order and the preparation are.
This is the process that keeps updates from becoming emergencies.
Why plugin updates break things
A plugin update changes code that your site depends on. Most of the time, the change is safe: a bug fix, a security patch, a new feature that doesn’t touch anything else. But sometimes the updated plugin conflicts with another plugin, drops support for a PHP function your other plugins use, or changes behavior that your theme or customizations were built around.
The problem isn’t that plugins conflict. It’s that you updated 12 plugins at once and now something’s broken and you have no idea which one caused it. Roll them all back and you’ve lost the security patches. Leave them all active and you can’t isolate the problem. That’s the position that turns a 10-minute update into a two-hour debugging session.
The fix is simple: update one plugin at a time, test between each one, and know what to do when something breaks before you start.
Before you update anything: the 3-step preparation
Step 1: Take a full backup
A backup taken immediately before an update round is the only thing that guarantees you can get back to exactly where you started. Not a backup from last week. Not a backup from this morning. A backup taken right now, before this update session begins.
Your backup needs to include both your files (the WordPress installation, plugins, themes, uploads) and your database (posts, settings, orders, users, all of it). A files-only backup can’t restore a broken site. A database-only backup can’t restore missing plugin files. You need both.
Most backup plugins (UpdraftPlus, Jetpack Backup, BlogVault) let you trigger a manual backup on demand. Do that now. Confirm the backup completed before moving on. If your host provides a one-click backup in the hosting control panel, that works too. The method doesn’t matter. What matters is that you have a confirmed, complete backup from immediately before you started.
Step 2: Note what’s currently working
Before you change anything, spend 90 seconds confirming the current state of your site. Load the front page. Load a product page if you have WooCommerce. Try adding an item to the cart. Submit a contact form. Load wp-admin and make sure the dashboard responds normally.
You’re creating a baseline. If something breaks after an update, you need to know whether it was working before you started. More than once, a site owner has blamed an update for a problem that was already there.
Step 3: Enable the debug log
Add these two lines to wp-config.php before you start updating:
define('WP_DEBUG', true);define('WP_DEBUG_LOG', true);
This tells WordPress to write errors to a log file at wp-content/debug.log instead of displaying them on the page. If an update breaks something, the log will name the cause. Without it, you’re diagnosing a broken site with no evidence. With it, you’re reading a record of exactly what went wrong. The full walkthrough for reading that log is in how to turn on the WordPress debug log and what to do with what you find.
The update process: one at a time
Step 4: Update one plugin, then stop
In wp-admin, go to Dashboard > Updates. You’ll see a list of plugins with available updates. Resist the “Update All” button. Click the update for one plugin only. Wait for it to complete.
Which one to update first? Start with security-critical plugins: security scanners, firewall plugins, anything whose changelog mentions a security fix. Then move to your most-used plugins: WooCommerce, your form plugin, your page builder. Save cosmetic or low-stakes plugins for last.
If you have a staging site, run the full update sequence there first and confirm everything works before touching production. If you don’t have a staging site, the one-at-a-time process with testing between each update is your equivalent.
Step 5: Test before moving to the next update
After each plugin update, check the things most likely to be affected. Updated your payment gateway plugin? Try a test transaction. Updated your form plugin? Submit a test form. Updated a caching plugin? Clear the cache and reload a few pages. Updated something you’re not sure about? Load the front end, check wp-admin, and look at the debug log for any new entries.
This testing doesn’t need to be exhaustive. It needs to be enough to confirm the update didn’t break something obvious. Two minutes of checking after each update is the difference between catching a problem immediately and discovering it three updates later when you can no longer tell which one caused it.
Step 6: Repeat until all updates are done
Update one plugin, test, update the next, test. Work through the list. It takes longer than clicking “Update All,” but it takes much less time than diagnosing a broken site where you updated everything at once and don’t know where to start.
When you’re done with all updates, do one final check of the things that matter most to your site: checkout flow, contact forms, membership login, whatever functionality your site depends on. Clear your cache if you have a caching plugin. Then check the debug log one more time for any errors that appeared during the session.
When an update breaks something
Something broke. You updated one plugin, tested, and something that was working isn’t working now. Here’s the path.
Step 7: Identify which update caused it
If you were updating one at a time and testing between each, you already know which plugin caused it: the last one you updated. That’s the value of the one-at-a-time process. You don’t have to guess.
If you updated multiple plugins before testing (it happens), check wp-content/debug.log. The error will usually name a specific file or function, which points to a specific plugin. PHP errors in WordPress: what they mean and what to do first covers how to read what the log is telling you.
Step 8: Roll back the offending plugin
The fastest way to roll back a single plugin is to deactivate and delete the current version, then install the previous version manually. You can find previous versions of any WordPress.org plugin by going to the plugin’s page on wordpress.org, scrolling to the “Advanced View” section, and downloading the specific version you need from the “Previous Versions” dropdown. Upload it via Plugins > Add New > Upload Plugin.
If your backup plugin supports single-plugin rollback (Jetpack Backup and BlogVault both do), use that instead. It’s faster and lower-risk than manual reinstallation.
If the broken site is blocking your access to wp-admin entirely, use your hosting file manager to rename the offending plugin’s folder in wp-content/plugins (add _disabled to the end of the folder name). That deactivates the plugin without requiring wp-admin access, and should restore enough functionality to get back in.
Step 9: Confirm the rollback fixed it, then decide next steps
After rolling back, retest the thing that broke. If it’s working again, the update was the cause. You now have two options: wait for a newer version of the plugin that fixes the conflict, or investigate whether the conflict is with another specific plugin and whether there’s a workaround.
Check the plugin’s support forum on wordpress.org. If the update introduced a conflict, other users will have reported it. The plugin developer may have already released a patch, or there may be a known workaround in the support thread. If the conflict is unresolved, check whether your host has PHP error logging you can enable to get more detail on the specific incompatibility.
For functional failures that aren’t producing a clear PHP error, a Loupely capture taken from the page where the failure is occurring reads the server-side state at the moment of the failure: PHP errors, hook execution order, REST API responses. If the debug log isn’t naming the cause clearly, the capture fills in the gap.
Auto-updates: what to know before enabling them
WordPress lets you enable automatic updates for individual plugins. The appeal is obvious: security patches apply themselves without you having to remember. The risk is real: an auto-update can break something at 3am and you won’t find out until a visitor tells you, or until you log in the next morning.
A middle path that works well: enable auto-updates only for plugins where the developer has a strong track record of stable releases, and only if your host takes automatic nightly backups. That way an auto-update that breaks something can be rolled back to the previous night’s backup without losing much. For WooCommerce, payment plugins, and anything touching transactions, leave auto-updates off and update manually following the process above.
The part that saves you the most time
The backup in Step 1 and the debug log in Step 3 are what make every other step faster. The backup means a catastrophic failure is recoverable. The debug log means a broken site is diagnosable. Without those two things, a broken update is a debugging problem where you’re working without evidence. With them, it’s a lookup: what does the log say, and what does the backup restore to.
Everything else in this process is about keeping the update session small enough that you always know what changed. One plugin, one test, one plugin, one test. The whole thing takes longer per update and dramatically less time per incident.
