WordPress maintenance automation has a long-running market, especially outside Japan. ManageWP, MainWP, WP Umbrella, InfiniteWP — each has more than a decade of history behind it.

While building our comparison pages, we surveyed all four side by side. An interesting pattern emerged: three things none of the four tools offer.

Each is a gap the industry has long treated as "not feasible," and there are structural reasons why. Here's a look at those three unsolved areas — and why they remain unsolved.

Gap 1 — Per-plugin updates with HTTP checks between each one

In most maintenance tools, plugin updates run in bulk. After the batch, the tool takes a sitewide screenshot diff or HTTP status check, and if anything is broken, "Safe Updates" or "Atomic Updates" features roll everything back at once.

Why isn't "one at a time with an HTTP check between each" the standard? The main reason is API design constraints. WordPress's built-in wp_ajax_update-plugin and Worker-plugin APIs (like ManageWP Worker) are designed around batch processing. Doing an HTTP probe from an external host after every single update would add significant per-update overhead. The industry has settled on "bulk update → bulk check" as the natural granularity.

The side effect: identifying which plugin caused the breakage often falls to the operator's manual investigation.

Gap 2 — Pinpoint rollback (only the one that broke)

The industry-standard "Safe Updates" feature is fundamentally a "roll back everything" design. If 20 plugins are batched together and one breaks the site, all 20 updates revert. It's a safety-first choice — but operationally, it means the 19 that finished cleanly are also lost.

Why isn't pinpoint rollback (revert only the one that broke) the standard? The root cause is state-management complexity. To pinpoint rollback, you need to keep the pre-update files of each plugin individually. Storage, transfer cost, and dependency consistency checks become impractical over a Worker-plugin HTTP API. "One whole-site snapshot, restore once" is far simpler to implement and operate, which is where the industry converged.

WP-CLI-based approaches change the math here — but as the next section explains, WP-CLI itself isn't the industry mainstream, which limits how widely this alternative spreads.

Gap 3 — Reaching client sites without installing an extra plugin

This is the most structural gap. All four tools require a Worker / Child plugin installed on each client site. ManageWP Worker, MainWP Child, Umbrella, InfiniteWP Client — the names differ, but every tool ships a "gateway plugin" that lives on each managed site.

Why has the industry adopted this? It's about connectivity and compatibility guarantees. Shared hosts are extremely varied — SSH availability, WP-CLI presence, and firewall configuration all differ. A WordPress-internal gateway plugin lets the tool reach every site through a uniform HTTP API. It's the pragmatic industry solution.

But it comes with side effects:

• The client site permanently hosts a "maintenance-vendor management plugin"
• If that plugin develops a vulnerability, every client is affected
• Clients eventually ask "what is this plugin?" — which needs an explanation
• If the plugin gets deleted (e.g., on contract termination), the site disappears from the tool's management view

Whether to accept these trade-offs, or to choose a different connection model entirely, ends up being a quietly important axis when selecting a maintenance tool.

Takeaway — should the industry's premises be questioned?

What these three unsolved gaps share is that they're areas the industry has long agreed are "good enough as is." The combination of "bulk update + whole-site rollback + Worker plugin" is technically and commercially stable. The fact that four major tools have run on this same structure for over a decade speaks to the design's maturity.

That said, alternative approaches that question those industry premises do exist. Using SSH + WP-CLI sidesteps the API overhead, making step-by-step updates and pinpoint rollback practical, and removing the need for a Worker plugin. The trade-off: the target narrows to shared hosts where SSH is available, and the operator needs some familiarity with SSH fundamentals.

It's not a question of which is "right" — it's that the operating style and constraint mix lead to different fits. Whether you pick the industry-mainstream "Worker + bulk + whole-site rollback" model or step outside it, awareness of these three unsolved areas gives you a clearer frame for asking what actually matters to your own maintenance operation.