How to update WordPress plugins on 50 client sites without breaking them

Every agency knows plugin updates matter. Most of the security holes published for WordPress each year are in plugins, not in WordPress itself, and attackers scan for sites running the vulnerable versions within days of a fix being released. A site that's three months behind is a site waiting to be found.

The problem isn't knowing. It's time. Fifty sites times "log in, check updates, update, check the site" is a morning a week, every week. So it slips, and the backlog makes the next round riskier, because twelve updates at once are much harder to untangle than two.

Here's how to make it a one-hour job.

Why updates get skipped

The reasons sites fall behind are nearly always the same:

• It takes too long. Logging in to each wp-admin, sometimes with 2FA, just to see whether anything needs doing.
• Fear of breaking things. One bad WooCommerce update on a Friday afternoon, and nobody wants to touch updates again.
• Nobody owns it. Updates are "everyone's job", so they're no one's.
• It's not billed. If updates aren't part of a care plan, they're free work, and free work gets done last.

A routine fixes the first three. A care plan fixes the fourth.

Rank updates by risk

Not every update deserves the same caution. Sorting them into three groups lets you move fast on most and slow down only where it matters:

A plugin that jumps a whole major version (say 8.x to 9.0) moves to "careful" whatever it is. Major versions are where breaking changes live.

The weekly routine

Pick a day and a time, put it in the calendar and give it an owner. Tuesday or Wednesday morning works well: not Monday when the week's urgent work lands, never Friday afternoon.

1. Check the backups exist

Before you change anything, confirm each site has a recent backup stored somewhere other than its own server. "Backup complete" in a plugin is a good sign; a restore you've actually tested is proof. If a site has no recent backup, take one first.

2. See every pending update in one place

This is where most of the time goes, and where tools save the most. Instead of logging in to each site, use a dashboard that lists pending plugin and theme updates across all your sites: ManageWP, MainWP, WP-CLI scripts, or the 200 Online connector. You want one screen that answers "what needs updating, where?"

3. Do the careful ones on staging

For important sites with a "careful" update, update the staging copy first and click through the parts that matter: the checkout, the booking form, the contact form. Most hosts offer one-click staging now. If the site has no staging copy, do careful updates during quiet hours and stay on the site for ten minutes afterwards.

4. Update the rest in batches

Update the routine plugins across all sites. Do one site first, check it, then do the rest. If you use WP-CLI, updating every plugin on a site is one command:

wp plugin update --all
wp theme update --all

Add --dry-run to see what would change first.

5. Check the sites afterwards

An update that returns a white screen should never wait for the client to find it. Straight after updating, check that each site's monitor is still green and that the homepage loads. For shops, add a product to the cart. Uptime monitoring with a keyword check catches most broken updates within minutes, even on sites you didn't open.

6. Log the time

Record the time against each client. It's the line in the monthly report that shows the care plan working, and it tells you after a few months whether your plan prices are right.

When an update breaks a site

It will happen eventually. What matters is how fast you get it back. Work through these in order:

1. Find the culprit. If you updated in small batches, it's one of a few plugins. Check the PHP error log, or turn on WP_DEBUG_LOG in wp-config.php and reload.
2. Roll back that one plugin. With WP-CLI, reinstall the previous version:

   wp plugin install plugin-name --version=1.2.3 --force

   The version number is in the plugin's changelog or on its WordPress.org "Advanced" page.
3. Can't get into wp-admin? Connect over SFTP or the host's file manager and rename the plugin's folder in wp-content/plugins, for example to woocommerce-off. WordPress deactivates it, and the site usually comes straight back.
4. Still broken? Restore the backup from before the update. This is why step 1 of the routine exists.
5. Tell the client, then the plugin author. Let the client know it was caught and fixed. Report the bug on the plugin's support forum, and hold that plugin back on your other sites until a fixed version is out.

Why we never one-click WordPress core updates

Our dashboard updates plugins and themes, but it deliberately doesn't run WordPress core updates. It shows them as pending and leaves the update itself to wp-admin.

That's on purpose. A core update can stop halfway, through a timeout, a full disk or a file permission problem, and leave a site in maintenance mode or broken. When that happens, you want a person watching the screen, not a background job. Minor security releases are different: WordPress installs those automatically by default, and that's fine.

Tools for updating many sites

• ManageWP: hosted dashboard for WordPress updates, backups and more, with paid add-ons per site.
• MainWP: free and self-hosted, with paid extensions. You run the dashboard on your own WordPress install.
• WP-CLI: free and the most powerful, if you're comfortable with SSH and scripts. No dashboard.
• 200 Online: plugin and theme updates on the same card as uptime, client logins, hours and tasks for each site. Works alongside the others; you don't have to choose.

Report it to the client

Updates are invisible when they go well, which is the point, and also the problem. Put them in the monthly report: how many plugins were updated, that the site was checked afterwards, and any update you held back and why. "We held back the WooCommerce 9.0 update until a known checkout bug was fixed" is exactly the kind of sentence that keeps a client on a care plan for years.

Frequently asked questions