Updates are the second-leading cause of "the site is suddenly broken" support tickets, right after hacks. They are also the single most important habit for keeping the site safe. The reconciliation is having a process: update in a way that catches breakage immediately, with a rollback path that takes 30 seconds.
The full update checklist
Step 1: take a backup, off-site
Before anything. If the backup tool reports success, verify the backup file exists and has a sensible size. A 0-byte success is not success.
Step 2: note the current versions
Screenshot the plugins page so you know what versions you are coming from. If you have to roll back, you need this.
Step 3: update WordPress core first
Not plugins, not themes — core. Plugins are usually compatible with the latest core; the reverse is not always true. Reload the site, check the front page and admin still work.
Step 4: update plugins in batches of 5-10
Not all at once. After each batch, reload the public site and check three things:
- The home page renders correctly.
- The most-used template (product page, blog post, contact form) renders correctly.
- The admin still loads without PHP errors.
If anything broke, you know it was one of the last batch — much easier to identify and roll back than if you had updated everything at once.
Step 5: update the theme last
Themes are riskier because they touch the visual layer. If your theme is significantly customized, run the update on a staging environment first.
Step 6: clear all caches
Page cache, object cache, opcode cache, CDN cache. The site is now serving updated code; visitors should not see cached old code.
Step 7: visual diff
Compare key pages to before the update. Some plugin updates silently break CSS in ways monitoring tools miss but a human sees in 5 seconds.
The rollback playbook (when something does break)
For a single broken plugin, the fastest path is:
- Note which plugin caused the problem (you batch-updated, so you know which 5-10 it was in).
- Disable the offending plugin via SFTP — rename its folder in
wp-content/plugins/. - Reload the site. It should work without the plugin.
- Download the previous version from the WordPress.org plugin repository (every plugin has a "Previous Versions" tab on its directory page).
- Replace the folder with the previous version, re-enable.
- Report the bug to the plugin author and re-test the new version in a week.
For a broken theme, swap to a default WordPress theme temporarily, then restore the customized one from backup. For a broken WordPress core update, restore the entire site from the pre-update backup. This is rare — core updates almost never break sites — but it is why step 1 exists.
What to update less often
Some plugins are stable and rarely change. Others churn out updates weekly with risky changes. Track which plugins on your site are in which category. The high-churn plugins should get extra scrutiny each week. The stable ones rarely cause problems.
One signal: read the plugin's changelog before updating. "Fixed translation" is safe. "Refactored the database layer" is high-risk; back up twice and update on staging first.
Outsourcing this
If updating WordPress is something you do as a non-technical task, paying someone else to do it is one of the highest-ROI maintenance decisions available. The work itself is well-defined, the risks are predictable, and an experienced engineer recovers from a botched update in 15 minutes vs the 4-hour panic spiral most owners go through.