Updating applies security patches and bug fixes to WordPress core, plugins and themes. It is the single highest-value maintenance task, because most compromised WordPress sites are running a vulnerability that was patched before they were attacked.
Worth knowing: Never update during a launch, a campaign or a sale. The upside of applying a routine update immediately is small; the downside of breaking checkout during peak traffic is not. Freeze changes around anything that matters and update the day after.
Management plugins and services can apply updates across many sites from one dashboard, and some add a visual regression check that screenshots key pages before and after so you can see what changed. That check is the genuinely useful part — bulk-clicking update on forty sites without verification just makes the same mistake faster.
The mechanical part of updating is not the work — it is the twelve logins and the checking afterwards. That is the part worth describing rather than repeating.
“Update all plugins on every site with an available security release, skipping WooCommerce, and report what changed.”
+ 11 sites scanned — 7 with security updates pending
+ contact-form-7 5.9.3 → 5.9.4 on 6 sites
+ wordfence 7.11.2 → 7.11.4 on 4 sites
! WooCommerce skipped as instructed (3 sites had updates available)
+ Snapshot taken per site before applying — all reversible
A snapshot is taken per site before anything is applied, so an update that breaks a checkout page is reversed from the dashboard rather than over FTP. How undo works.
This is where managing many sites stops scaling by hand. A disclosed vulnerability in a plugin you use on eleven client sites is a countdown, and the answer needs to be one instruction across the portfolio with a snapshot per site — not an afternoon of logins while the window stays open.
Related: When an update breaks the site · The latest WordPress version · Packaging this as a care plan
For most sites, yes. Running unpatched plugins is the single most common route to a compromise, and that risk usually outweighs the risk of an update breaking something. The exception is heavily customised, commercial or business-critical plugins, where a staging test first is worth the delay.
Plugins and themes first, then core. Plugin authors typically ship compatibility updates ahead of a core release, so this order means core arrives to code that already expects it. Take a backup before you start either way.
If you can reach the admin, roll back or deactivate the plugin you just updated. If you cannot, rename the wp-content/plugins folder over FTP to deactivate everything, then restore access and re-enable them one at a time. If the site shows a critical error message, check the admin email — WordPress usually names the plugin and includes a recovery link.
Check weekly, and apply security releases as soon as they appear. The dangerous window is between a vulnerability being disclosed publicly and your site being patched, and automated scanners are looking during exactly that period.
Security updates across your whole portfolio, with a snapshot per site and a report of what changed.
Start free