Maintaining ten WordPress sites is a chore. Maintaining five hundred is an operations problem, and the habits that worked at ten will quietly break you at a hundred. We have maintained thousands of WordPress sites for agencies and hosts, and the pattern is always the same: the agencies that scale wrote down a policy, automated the boring parts, and measured the rest.
This guide walks through the six pieces that matter.
1. Write an update policy before you touch anything
Most fleet outages come from inconsistency, not from WordPress itself. One tech updates everything on Monday, another waits two weeks, a third turns on auto-updates and forgets. Decide the rules once and apply them everywhere.
A workable policy for an agency fleet:
- Core minor releases (6.9.1, 6.9.2): auto-update within 24 hours. They are security and bug fixes.
- Core major releases (7.0): hold 14 days, test on a representative batch of sites, then roll out in waves.
- Plugins and themes: update weekly in a fixed window, except security releases, which go out same day.
- Known troublemakers: keep a short list of plugins (page builders, WooCommerce, membership plugins) that only update after a staging check.
Put the policy in your care-plan contract so clients know what “maintained” actually means. It also gives your team a script when a client asks why their site was not on the newest version the morning it dropped.
2. Staging: tier it, do not blanket it
Running every update through staging on every site sounds responsible and is unaffordable. Tier instead:
| Site tier | Staging check | Example |
|---|---|---|
| Critical (ecommerce, lead-gen, high traffic) | Every plugin and core update | WooCommerce stores, membership sites |
| Standard (brochure, blog) | Major core and page-builder updates only | Local business sites |
| Low-touch (parked, archival) | None; rely on rollback | Event sites past their date |
Most hosts give you one-click staging. Where they do not, a disposable staging copy spun up by your maintenance platform does the job. The point is to put human attention where failure actually costs money.
3. Backups you have actually restored
A backup you have never restored is a hope, not a backup. The fleet rules:
- Daily full backups for every site, hourly database backups for anything transactional.
- Off-host storage. If the host’s disk fails, the host’s backups fail with it.
- Pre-update snapshot immediately before every update run, retained for at least seven days.
- Quarterly restore drills: pick five random sites, restore them to a scratch environment, confirm they load. Log the time it took.
That last line is the one most agencies skip, and it is the one that saves you when a client’s store goes white at 9 a.m.
4. Visual regression: catch what a 200 status code hides
An HTTP check tells you the site returned a page. It does not tell you the hero image is gone or the checkout button has fallen below the footer. Visual regression testing screenshots key pages before and after an update, diffs them, and flags anything above a threshold.
Set it up on three to five URLs per site: home, a key landing page, a product or service page, contact, and checkout where relevant. Tolerate small diffs (rotating testimonials, dates) and alert on anything over roughly five percent pixel change. Anything flagged gets a human look before the update is marked done. WP Maintain runs this automatically as part of every update cycle, which is the only way it is practical past a few dozen sites.
5. SLAs that match your tiers
Tie your response commitments to the same tiers you used for staging. A sane starting point:
- Critical sites: 1-hour response, 4-hour resolution target for outages; same-day security patches.
- Standard sites: 4-hour response, next-business-day resolution.
- Low-touch sites: 1 business day.
Publish uptime as a monthly number per client. Agencies that report “99.97% uptime, 14 updates applied, 0 incidents” every month have far fewer churn conversations than agencies that go quiet until something breaks.
6. Tooling: one dashboard, not six tabs
The minimum viable stack for a fleet:
- A fleet management platform that handles updates, backups, uptime, and visual regression from one place and lets you act on sites in bulk.
- A ticketing or task queue so update failures become tickets, not Slack messages that get lost.
- A reporting layer that produces client-facing monthly reports without a human copying numbers.
- Vulnerability intelligence that tells you which of your 500 sites run the plugin that got a CVE this morning.
Avoid building this out of seven single-purpose plugins. The moment you need to answer “which sites run Elementor below version X” across the fleet, a per-site approach falls over. We built WP Maintain because we hit exactly that wall maintaining sites for hosts and agencies, and 1,000+ agencies and web hosts now partner with Seahawk on this kind of work.
A weekly rhythm that holds up
- Monday: review the vulnerability feed; same-day patch anything critical.
- Tuesday: scheduled update window for standard sites, with pre-update snapshots and visual regression.
- Wednesday: staged updates for critical sites; human review of any flagged diffs.
- Thursday: clear the failure queue, chase client approvals.
- Friday: no updates. Reports go out, restore drill if it is the quarter’s turn.
Next step
If you are past the point where spreadsheets and a handful of plugins can hold your fleet together, WP Maintain was built for this: bulk updates with automatic rollback, off-host backups, visual regression, MainMonitor uptime and performance tracking, and white-label reports for every client. Book a walkthrough and bring your messiest site list.