Grouped by release, not by site
The update queue groups by plugin and version, so you see "Yoast SEO 24.1, affects 22 sites" rather than twenty-two separate line items. Select the release once and it applies everywhere it is relevant.
Bulk updates
Bulk update WordPress plugins, themes and core across every site at once
Bulk update WordPress plugins, themes and core across your entire portfolio from one screen. Every pending release is grouped by plugin so you can see exactly how many sites it affects, then select, schedule and ship, with a restore point taken automatically before anything changes.
Included on every plan. No add-on pricing.
Updated
Bulk update runExample data
Selected
23
releases
Sites affected
31
of 34
Restore points
31
complete
Est. duration
6m
staggered
YOYoast SEO 24.1
ReadyWPWordPress 6.8.3
ReadyCFContact Form 7 6.1
ReadyWCWooCommerce 9.4.2
Staged firstWhat are bulk WordPress updates?
Bulk WordPress updates apply the same plugin, theme or WordPress core update to many sites in one action, instead of logging into each site's wp-admin and pressing Update one site at a time. The point is speed without losing control: you still choose what updates, where, and when.
Before you send a major release to every site, our guide on how to update WordPress core safely covers the checks to make first.
For the single-site side of the job, from choosing a plugin to deleting it, see our guide to WordPress plugin management.
WPCentrify lists every pending update across all your WordPress sites, grouped by plugin and version, so you can see how many sites a release touches, select it once and send it to every site that needs it. Updates run the way WordPress's own Update now button runs them, a plugin that breaks a site is put straight back, and the run shows each site's progress live.
WPCentrify bulk updates at a glance
- One list of pending plugin, theme and WordPress core updates across every connected site.
- Updates grouped by release, so one choice reaches every site that needs it.
- A plugin or theme update that leaves a site broken is put straight back on that site.
- Live progress for every website in the run, and one place to see what finished, what waits and why.
- Updates from paid plugins are found too, without anybody opening wp-admin.
The problem
Bulk WordPress updates: why site-by-site does not scale
The arithmetic is unforgiving. A site with twenty-five plugins produces roughly eight to twelve updates a month. Logging in, checking, applying and verifying takes six to ten minutes if nothing goes wrong. At fifteen sites that is a full working day every month spent on an activity that produces no billable output and no visible value.
The natural response is to batch it, and the natural consequence of batching is falling behind. Sites drift months out of date, security patches sit unapplied, and eventually one update has to jump four versions at once, which is exactly the update most likely to break something.
What this looks like without a platform
- Twenty browser tabs, each one a different wp-admin
- Losing track of which sites you already did
- No record of what changed, so no way to diagnose a regression later
- Update fatigue leading to sites that are six months behind
How it works
How to manage WordPress plugin updates across every site
Filter by anything that matters
Filter by risk band, client, care plan tier, hosting provider, tag, WordPress version or whether the site is a store. Save the filter as a view you return to weekly.
Exclusions that stick
Pin a specific plugin on a specific site with a reason attached, and it stays excluded from bulk actions until you unpin it. The exclusion appears in the audit log so a colleague understands why.
Scheduling that respects the business
Set a maintenance window per site in the site's own time zone. A restaurant site gets updated at 4am local, a B2B site at 2am, and a store with a Black Friday campaign is frozen entirely for the week you specify. Those windows are one of the conditions maintenance automation rules read before anything runs.
In practice
What happens when you bulk update WordPress plugins
Pre-flight restore point
Every site in the batch gets a fresh encrypted snapshot before its first change. If anything goes wrong, recovery does not depend on last night's backup.
Sequenced, not simultaneous
Updates are staggered across sites rather than fired at once, so you never overload a shared host or trip a rate limit. Higher-risk releases in the batch can be routed through safe updates for visual checks first.
Automatic retry with backoff
Transient failures, a host briefly unreachable or a lock file held, are retried with backoff rather than reported as a failure that needs your attention.
A single result summary
One notification when the batch completes: what succeeded, what was skipped and why, what failed and what was done about it. Anything that shipped and then failed pixel comparison is listed there too, already rolled back.
At scale
Update multiple WordPress sites without doing it site by site
- See at a glance how many sites a single plugin release touches
- Update WordPress core, plugins, themes and translations in the same pass
- Roll out to a canary site first, then the rest of the batch
- Bulk enable or disable WordPress automatic updates by risk band
- Track which sites are furthest behind and prioritize them
- Export the change history for any period as CSV
Answers
Questions about bulk updates
What people ask before they turn this on.
Connect every site to one dashboard, then work from the pending-update list rather than from the sites themselves. WPCentrify groups each release by plugin, so you select the plugin once and it applies everywhere it is due. A restore point is taken per site before anything is written, and anything you have pinned is skipped automatically. Higher-risk releases can be sent through safe updates for visual checks first.
Yes. Pin any plugin at a specific version on a specific site with a note explaining why. It stays out of every bulk action until you unpin it, and the reason is visible to anyone else on your team.
That site is retried with exponential backoff. If it is still unreachable after the retry window it is reported as skipped rather than failed, and the rest of the batch proceeds. Nothing is left half-applied.
Yes. A multisite network connects as a single unit and you can act on the network level or on individual subsites, with network-activated plugins handled correctly.
Yes. Most people set a weekly window for low-risk updates and let security patches ship as soon as they are risk-scored. Both are policies you configure once per site or per care plan tier.
On a single site, open Plugins in wp-admin, tick every plugin with an update and choose Update from the bulk actions menu. Across many sites, use a management tool: WPCentrify lists every pending update on every connected site, grouped by plugin, and sends each one to every site that needs it in one action.
It is safe when every update has a way back. WPCentrify keeps a copy of each plugin or theme folder an update replaces on the website, checks the site after the update, and puts the previous version straight back if the update leaves the site broken. Updates on a run go to one site after another, so a problem is seen before it reaches every site.
Yes. WPCentrify sends a WordPress core update to every site you choose, takes a copy of the database and WordPress's own files first, and finishes the database upgrade WordPress needs afterwards even on hosts that block the request WordPress normally uses for it.
Yes. Paid plugins usually announce their updates only when somebody opens wp-admin. WPCentrify asks for them the same way, so updates for premium plugins appear in the list without anybody logging in to each site.
Early access open
Try bulk updates on your own sites
Connect a site in under two minutes and see this working against something real. Free during early access.
Free during early access. Keep your data, export any time.