Most sites we fix after a bad update have the same story: a batch of plugins updated at once on the live site, with no recent backup. Updating safely mostly comes down to two things: doing it in a sensible order, and always having a way back.
Start here: take a fresh backup
Take a full backup (files and database) right before you update, not last night’s. Confirm it finished, and make sure you know how to restore it. A hosting snapshot works too, as long as you can restore it yourself without waiting on a support ticket.
If you don’t have a backup routine yet, set one up first. Our guide to backing up and restoring WordPress walks through it.
Read the changelog
On Plugins → Installed Plugins, plugins with an update show a View version details link. For plugins from WordPress.org, that opens the changelog. Premium plugins usually link to a changelog on the vendor’s site.
You’re looking for anything that raises the risk of the update:
- A major version jump, such as 2.9 to 3.0.
- A higher minimum WordPress or PHP version.
- Database changes or migrations.
- Words like “breaking change”, “removed”, “deprecated”, or “rewritten”.
A changelog that only lists small fixes is a low-risk update. A rewrite of the plugin’s core is not.
Update on staging first
For any site that brings in leads or sales, run updates on a staging copy before touching the live site. Refresh the staging site from live first so you’re testing against current content and settings. If you don’t have one, see how to set up a WordPress staging site.
Update in a sensible order
For routine updates, we go in this order:
- Plugins, starting with the main plugin before its add-ons (WooCommerce before WooCommerce extensions, a form plugin before its add-ons).
- Theme. If you use a child theme, this means updating the parent theme. Your child theme isn’t updated this way, which is the point of having one.
- WordPress core.
The exception: if a plugin’s new version requires a newer WordPress version than you have, update core first. WordPress shows a compatibility notice on the Plugins screen when a new version requires a newer WordPress or PHP version than your site runs.
Update major plugins one at a time
Small, low-risk plugins can be updated together. Anything your site depends on should be updated on its own, followed by a quick test before the next one. That usually means:
- Page builders and your theme
- WooCommerce and payment gateways
- Form, membership, and booking plugins
- Caching, security, and SEO plugins
If you update ten plugins at once and the site breaks, you have ten suspects. One at a time, you know exactly which update caused it.
Test the things that matter
Clear every cache first, or you may be testing an old copy of the page. Our guide on clearing the WordPress cache covers plugin, host, and CDN caches. Then check:
- The homepage and key pages, in a private browser window while logged out.
- Every important form: submit it and confirm the email arrives.
- Checkout, with a test order if you run a store.
- Logging in, and editing and saving a page.
- The mobile menu and site search.
Finally, check your error log for new warnings or fatal errors. See how to find the WordPress error log if you’re not sure where it is.
Then update the live site
Repeat the same updates in the same order on the live site, at a quiet time of day. Take another backup first. Some plugins, WooCommerce included, ask you to run a database update after the plugin update. Run it, then do the same tests you ran on staging.
How to roll back an update
WordPress has some built-in protection. Since version 6.6, if an automatic plugin update causes a fatal error, WordPress tries to roll it back. That doesn’t cover manual updates, or updates that break something without a fatal error, like a broken layout or a form that stops sending. For those, use one of the options below.
If the site shows a critical error
WordPress usually emails the admin a recovery mode link that lets you log in and deactivate the plugin at fault. If you can’t get in, connect by SFTP and rename the plugin’s folder in wp-content/plugins (for example, plugin-name to plugin-name-off). That deactivates it. Our guide to handling a WordPress critical error has the full steps.
Free plugins: WP Rollback
For plugins and themes from WordPress.org, the free WP Rollback plugin adds a Rollback link on the Plugins screen. Click it, choose the previous version, and confirm. It’s the fastest option when you can still reach the dashboard.
Premium plugins: upload the old version
Download the previous version from your account on the vendor’s site (most premium vendors offer older versions, though not all). Then go to Plugins → Add New Plugin → Upload Plugin and upload the zip. WordPress will detect that the plugin is already installed and offer Replace current with uploaded.
With WP-CLI
If you have SSH access, you can install a specific version of a WordPress.org plugin directly. Replace the slug and version number with your own:
wp plugin install woocommerce --version=9.0.2 --forceWhen to restore the backup instead
Rolling back a plugin’s files doesn’t undo changes it made to the database. If the update ran a database migration, or you updated several things and aren’t sure which one caused the problem, restoring the backup you took before updating is the cleaner fix. On a store, be aware that restoring the database loses any orders placed since the backup.
Want someone to handle it?
Our Care Plans include updates tested on staging first, backups before every update, uptime monitoring, and developer support, from $69 a month. If an update has already broken something, our $79 one-time fix will get it working again, usually within 24 hours, fixed or your money back.