This is the practical checklist version. If you’re defining or auditing a care-plan offer for a delivery agency, work through each section below and decide explicitly what’s in scope, what’s billed separately, and what service level you’re committing to. The discipline of writing it down is what separates a profitable product from a slow margin leak.

Every credible care plan, regardless of price, includes these. Treat them as the floor, not the ceiling.

• Updates: WordPress core, themes, and plugins on a defined cadence — ideally tested on staging before pushing live.
• Backups: Automated, off-site, with a stated retention window and a documented, tested restore procedure.
• Security: Malware scanning, firewall rules, login hardening, and a written incident-response path.
• Monitoring: Uptime alerts plus periodic performance and Core Web Vitals checks.
• Content edits: A capped allowance of minor changes, defined precisely so it can’t expand into free project work.
• Reporting: A monthly summary of everything performed, because the report is the deliverable the client actually sees.

Most catastrophic care-plan failures trace back to one of these two categories being sloppy. Get them right and you have eliminated the majority of emergency calls.

Update checklist

• Define a cadence: weekly for active sites, monthly for static ones.
• Test updates on a staging copy before production wherever the tier allows.
• Take a backup immediately before any update batch.
• Visually verify key pages after updating — homepage, checkout, contact form.
• Log what was updated so it lands in the monthly report.

Backup checklist

• Store backups off-site, never only on the same server as the site.
• State the retention window in the contract (for example, 30 daily plus 12 monthly).
• Test a real restore on a schedule — an untested backup is a guess, not a backup.
• Back up both files and the database together.

The value of monitoring is that you find out before your client does. A care plan that only reacts when the client emails “the site is down” isn’t a care plan — it’s a help desk with a worse name. Include continuous coverage and a defined response.

• Malware and vulnerability scanning on a schedule, with alerts routed to your team, not the client.
• Login and access hardening: enforced strong passwords, limited login attempts, and two-factor for admin accounts.
• Uptime monitoring with a stated check interval and an escalation path when a site goes down.
• Performance baselines: track Core Web Vitals over time so degradation is visible before it becomes a complaint.
• Incident response: a written runbook for a compromised site — isolate, restore from clean backup, identify the entry point, report.

The line items above are where the work lives. The boundaries below are where the profit lives. Most agencies lose money on care plans not because the tasks are hard, but because the scope is fuzzy.

• Cap the edit allowance. Specify it in tasks or hours per month and define what a “task” is. “Update the team photo” is in scope; “redesign the about page” is a quoted project.
• List explicit exclusions. New page builds, custom development, content writing, and SEO campaigns are common things clients assume are included. Name them as out of scope.
• State your SLA per tier. Response time, resolution target, and support hours, written down. Vague commitments get exploited.
• Define rollover rules. Decide whether unused edit time rolls over (usually no) and put it in writing before a client asks.

For how these boundaries translate into actual tier pricing, the WPOS pricing structure is a useful reference point for what scoped, repeatable operations cost at fleet scale.

A scope matrix you can lift straight into a contract

Ambiguity is what kills care-plan margin, and the cure is a matrix that states, line by line, what is included, what is billed, and what is excluded. Drop something like the following into your statement of work and revisit it whenever a client request makes you hesitate about whether it’s covered.

The point of the matrix isn’t legal armor — it’s a shared reference that lets your delivery team say “that’s out of scope, here’s the quote” without inventing the answer on the spot. Consistency across the fleet is what makes the plan a product rather than a per-client negotiation.

What to include as you scale: from manual to AI-native execution

The checklist above assumes a human performs each item on each site. That assumption is exactly what caps your margin once the fleet passes a few dozen sites. The agencies pulling ahead are folding an AI-native execution layer into their care plans so the repeatable work scales without proportional headcount.

Concretely, the application-layer items on this checklist — automated audits, ongoing content management, and store operations — can be executed today through a structured layer rather than by hand. WPOS is the only WordPress AI system that is both independent of any builder or host and operates through that structured execution layer rather than touching the raw site directly. Across the connected fleet that already translates to over 800 pages produced per month and more than 20,000 agent tool-executions per month. For the underlying model, see what WPOS is, and review the available connectors to understand how it plugs into an existing stack.

Keep the seam honest with clients. Application-layer operations — audits, content, store ops — are automated now. Infrastructure-layer autonomy such as self-healing and automatic rollbacks is on the roadmap, not in today’s product. Include the former in what you promise today; describe the latter as direction, not delivery.

Practically, that means rewriting your checklist in two columns: the items a human still has to own, and the items the execution layer can run on a schedule. As more of the routine work shifts to the second column, you can either widen what each tier includes at the same price, or hold the scope and let the freed-up time go toward higher-value work the client will pay a premium for. Either way, the checklist stops being a labor estimate and starts being a margin lever.

Frequently asked questions

How many content edit hours should a care plan include?

There’s no universal number, but most agencies cap entry tiers at 30 to 60 minutes of edits per month and mid tiers at one to two hours. The key is to express it as a hard cap and define what counts, so a “quick edit” request can’t quietly turn into an unpaid redesign. If a client routinely exceeds the cap, that’s a signal to move them up a tier or onto a separate retainer.

Should the care plan include hosting?

It can, but bundling hosting changes the economics and your liability. Many agencies keep hosting as a separate line so the care plan stays portable across whatever host the client uses. If you do bundle it, be clear about what the care plan covers at the application layer versus what the host covers at the server layer, so accountability is never ambiguous during an incident.

What should the monthly report actually contain?

At minimum: updates applied, backups taken, security scans run with any findings, uptime percentage, performance trend, and edits completed against the allowance. Keep it skimmable — a client should grasp the value in 30 seconds. The report is the single most important retention tool in the plan, because it makes invisible work visible at exactly the moment budgets get reviewed.

Want to build a care plan whose checklist scales without scaling headcount? Look at how WPOS structures its plans for agencies running maintenance across a fleet, or sign up for the WPOS beta to test the execution layer against your own sites.

Part of our guide: WordPress Maintenance Plans at Scale: Agency Guide.

For a delivery agency, the care plan is less about the technical chores and more about the business model. It converts the long tail of post-launch work — the work that otherwise gets done for free, badly, or not at all — into predictable monthly revenue. This guide defines exactly what a care plan is, what separates an agency-grade plan from a hobbyist’s, and where the model is heading as AI-native tooling reshapes how fleets get maintained.

At its simplest, a WordPress care plan is a productized maintenance retainer. Instead of billing hourly every time a plugin breaks or a client wants a banner swapped, you sell a fixed scope of recurring work at a fixed price. The client gets peace of mind and a single point of accountability; the agency gets recurring revenue and a reason to stay in the relationship after the invoice for the build is paid.

The defining characteristics are recurrence (monthly or annual), a bounded scope (what’s included versus billed separately), and an implicit or explicit service-level commitment (how fast you respond when something goes wrong). Everything else — the specific tasks, the reporting cadence, the tooling — is implementation detail layered on top of those three pillars.

Scope varies by tier, but almost every credible plan covers the same foundational categories. The difference between a $49 plan and a $499 plan is depth and responsiveness, not the presence of these line items.

• Updates: Core, theme, and plugin updates applied on a defined schedule, ideally tested against a staging copy before going live.
• Backups: Automated, off-site backups with a stated retention window and a tested restore process.
• Security: Malware scanning, firewall configuration, login hardening, and a defined incident response if a site is compromised.
• Uptime and performance monitoring: Alerts when a site goes down or slows, plus periodic performance and Core Web Vitals checks.
• Small content edits: A bounded allowance of minor changes — text swaps, image updates, new pages — usually capped at a set number of hours or tasks per month.
• Reporting: A monthly summary showing what was done, so the client sees the value they’re paying for.

The reporting line is the one agencies underrate. A care plan that does excellent invisible work and never reports it is a care plan one budget review away from cancellation. The deliverable clients can see is the report; the work behind it is what justifies the report.

A solo freelancer can run a care plan on a handful of sites by logging in manually each month. An agency maintaining a fleet of 50, 200, or 500 sites cannot. The distinction is operational, and it shows up in three places.

Defined service levels, not best effort

An agency-grade plan states response and resolution times in writing. “We respond to downtime within one hour during business hours” is a commitment a COO can staff against. “We’ll get to it when we can” is a liability that erodes margin and trust.

Fleet-level process, not per-site heroics

The agency model only works if maintenance is repeatable across the fleet. That means standardized update windows, centralized monitoring, and a consistent runbook for the predictable failures. The economics break the moment every site needs a senior developer to log in and improvise.

A scope that protects margin

The fastest way to lose money on care plans is unbounded “small edits.” Agency-grade plans define the edit allowance precisely, specify what counts as in-scope versus a quoted project, and enforce it. The plan is a product, and products have a spec.

Project work is feast or famine. You close a build, deliver it, invoice it, and then start the hunt for the next one. Revenue spikes and craters with the sales pipeline, which makes hiring, forecasting, and cash flow a constant guessing game. Care plans solve the structural problem underneath that: they convert one-time project clients into recurring relationships with predictable monthly revenue.

That recurring base changes how the whole agency operates.

• Predictable cash flow: a book of care-plan clients covers a meaningful share of fixed costs before you sell a single new project.
• Higher agency valuation: recurring revenue is worth far more per dollar than project revenue if you ever sell the business.
• Stickier relationships: staying in monthly contact means you’re the first call for the next build, the redesign, and the referral.
• Better risk posture for the client: a maintained site is far less likely to be hacked, broken, or quietly degrading — which protects your reputation as much as theirs.

The catch is that this only works if the plan is profitable to deliver. A care plan that consumes more senior-developer time than it brings in revenue is worse than no plan at all, because it ties up your scarcest resource on your lowest-margin work. That tension — recurring revenue versus cost to deliver — is the central problem care plans have to solve, and it’s exactly the problem AI-native operations are starting to change.

Most agencies sell three tiers because three is the number that lets a buyer self-select without analysis paralysis. The middle tier should be the one you actually want most clients on; the others exist to frame it. You can see how this tiering logic maps to platform-level economics on the WPOS pricing page.

The traditional care plan was built around human labor: a person logging into each site, running updates, eyeballing the result. That model caps your margin at how many sites one person can babysit. The shift now underway is toward AI-native operations, where the routine work of a care plan is executed through a structured layer rather than by hand on the raw site.

This is the wedge WPOS occupies. WPOS is the only WordPress AI system that is both independent — locked to no builder and no host — and operates through a structured execution layer rather than acting on the raw site directly. Today that means the application-layer operate work of a care plan can be automated: scheduled audits, ongoing content management, and store operations. Across the current fleet, that already shows up as roughly 300 updates handled in 90 days and over 20,000 agent tool-executions per month — the kind of throughput a headcount-bound model can’t match. To understand the underlying approach, see what WPOS is and how it operates client sites.

A clear caveat on the seam: deeper infrastructure-layer automation — self-healing, automatic rollbacks, proactive host-level maintenance — sits on the roadmap, not in today’s product. The honest framing for your clients is that the predictable application-layer work is increasingly automated now, while the infrastructure autonomy is coming. WordPress isn’t dying; it’s being out-executed by faster, AI-native tooling, and the agencies that adopt that tooling early are the ones whose care-plan margins survive the next few years.

Logging into 20 admin panels to toggle maintenance mode is not a scaling problem waiting for a bigger team; it is a systems design failure your agency can fix today.

The average maintenance window for a WordPress agency managing 10 to 30 client sites looks like this: one person logs into each site, activates a maintenance screen, waits for the all-clear, then logs back in to deactivate. At 3 to 5 minutes per site, a 20-site fleet costs an hour of senior engineer time on access and navigation alone. That hour is not billable.

The second cost is human error. When maintenance mode is triggered manually, sites get missed. A developer distracted by a message skips one. A client calls because their site is still live during a database migration. The operations failure is not the manual work itself; it is the absence of a repeatable, auditable runbook that executes identically every time.

The fix is treating maintenance mode as a fleet-level command, not a per-site task. Every site in your fleet should respond to a single script: activate, verify, work, deactivate.

WordPress maintenance mode is controlled entirely by a single file, .maintenance, placed in the WordPress root directory.

When WordPress initializes in wp-settings.php, it checks whether a .maintenance file exists in the root of the installation. If the file is present and contains a PHP variable named $upgrading set to a Unix timestamp within the last 600 seconds, WordPress serves the maintenance screen instead of the normal site. The file itself contains a single line: <?php $upgrading = [timestamp]; ?>

The maintenance screen is customizable. If a file named maintenance.php exists inside your wp-content/ directory, WordPress serves it instead of the default “Briefly unavailable for scheduled maintenance” message. A well-run agency puts a branded maintenance page here with an estimated return time and an emergency contact for urgent issues.

Two constraints your script must account for:

• The 600-second window: WordPress only respects the maintenance file if the timestamp inside it is within 10 minutes of the current time. For windows longer than 10 minutes, your script must refresh the file every 9 minutes by rewriting it with an updated timestamp, or use WP-CLI’s built-in maintenance mode command, which handles the refresh automatically.
• Logged-in admin bypass: By default, WordPress allows logged-in administrators to view the site during maintenance. This is useful for post-activation verification, but it means client contacts with administrator accounts can still access the site during the window.

Maintenance mode is, at its core, a file operation. Anything that can write and delete files on your server controls it.

Every reliable fleet-wide maintenance approach reduces to one of three mechanisms: WP-CLI over SSH, direct file operations via SSH, or a WPOS site agent command.

Method 1: WP-CLI over SSH

WP-CLI’s maintenance-mode subcommand is the most operator-friendly approach for agencies with server access. It handles the timestamp refresh internally, accepts a u002du002dpath flag to target a specific WordPress installation, and returns a clean status on every call. To activate across a fleet, SSH into each host and run wp maintenance-mode activate u002du002dpath=’/var/www/yoursite’ u002du002dallow-root. To deactivate, replace activate with deactivate. A bash loop over a list of your site hosts and paths completes a 20-site fleet in under 30 seconds and writes a log of every command executed.

Method 2: Direct file operations via SSH

If WP-CLI is not installed on the target servers, write the .maintenance file directly. SSH into each host and run: echo ‘<?php $upgrading = $(date +%s); ?>’ > /var/www/site/.maintenance. For windows longer than 10 minutes, rerun this command every 9 minutes to refresh the timestamp. This method also lets you copy a custom maintenance.php to wp-content/ at activation time, so every site in the fleet displays a branded maintenance screen instead of the WordPress default. Deploy the template once, reference it from the activation script, and every client sees consistent branding during every window.

Method 3: WPOS site agent

If your agency runs a fleet through WPOS, maintenance mode is issued as a single command to the site agent. The agent handles the SSH connection, file write, and status verification per site, then logs the maintenance window to each site’s Playbook automatically. No shell loop required: the fleet responds as a unit and the operation is recorded without a separate documentation step.

Before starting any migration, update, or infrastructure change, confirm that every site in the maintenance window is actually serving the maintenance screen to visitors.

The verification step is where most scripted approaches fail. A site may have returned an SSH error silently. A path variable may have been wrong. A server may have been unreachable at activation time. Beginning work without verifying puts live client traffic through a half-migrated state, and that is a client relationship event, not just a technical one.

The fastest check: request each domain and read the HTTP status code. WordPress returns 503 Service Unavailable when serving the maintenance screen. Any site returning 200 OK is still fully live. Run a curl request against every domain after activation, and run the same check again after deactivation to confirm every site is back online.

Do not begin work until every site returns 503. A checklist that can be skipped is not a runbook; it is a suggestion.

For agencies operating through WPOS, the Workspace shows each site’s current status. Maintenance mode appears as a status flag in the fleet view, so you can confirm the entire fleet from one screen without running a separate request per domain.

Every maintenance window needs a paired client communication runbook that runs in parallel with the technical steps; the script and the client messages are two sides of the same operation.

Client-facing communication during a maintenance window is not a courtesy. It is the difference between a client who trusts your agency’s process and one who contacts your team at 2 AM because their site returned a 503 with no explanation.

The three-message sequence:

1. 24 hours before the window: “Hi [Client Name], we have a maintenance window scheduled for [Date] at [Time] [Timezone]. Your site will be offline for approximately [Duration]. We will send a confirmation when the work is complete.”
2. At window start: “Maintenance has begun on [Site Name]. Expected completion: [Time]. We will notify you as soon as the site is back online.”
3. At window close: “Maintenance on [Site Name] is complete. The site is live. Here is a summary of what changed: [Summary]. Please reach out if you notice anything unexpected.”

The summary in the close message is not optional. Agencies that send “all done” with no detail are training clients to distrust their maintenance windows. Specifics, including version numbers or a one-line description of what was migrated or restructured, build the kind of retention that carries a $5,000-plus relationship through years of work.

Wire the client messages to your maintenance script so they send automatically at the right moments. The activate step triggers the first notification. The deactivate step triggers the close. Removing human judgment from the timing removes the most common failure point in client communication during a maintenance window.

Every maintenance window your agency runs is a decision, and decisions not recorded are institutional memory that disappears with the next team turnover.

The most common knowledge gap for WordPress agencies is not technical skill. It is that the context behind past decisions dissolves when people leave. A client site migrated from shared hosting to a VPS in Q3. Why? Which server? Who approved it? What changed? If answering those questions requires hunting through chat history, your agency has a memory problem that compounds with every hire and every departure.

Maintenance windows are high-signal events. They almost always accompany a significant change: a core update, a hosting migration, a database restructure. Recording them creates a timeline that future team members can read in seconds rather than reconstruct over hours.

What to record per maintenance window:

• Date, start time, and duration
• Sites included in the window
• Reason for the window
• What changed, including specific version numbers, migrated paths, and configuration changes
• Who ran the operation
• Whether any anomalies occurred and how they were resolved

If your agency operates on WPOS, each site carries a Decisions log in its Playbook. A maintenance window entry might read: “2026-06-14: Maintenance window (22:00 to 23:15 UTC). Updated WordPress core from 6.7.1 to 6.8.0 across 18 client sites. No anomalies. Runbook version 3.1.” Six months from now, that entry answers every question a new team member might ask about that site’s history.

For the monthly cadence that generates these records systematically, and the full framework that turns isolated windows into a scalable plan, see WordPress maintenance plans at scale.

Broken links compound quietly across a client fleet, eroding search rankings and client trust long before anyone files a support ticket. Every site in your roster generates them continuously: content editors delete pages without setting redirects, third-party sources remove articles linked in year-old posts, external platforms migrate without notice. None of these events trigger an alert, and no one is watching the full fleet.

The SEO cost is structural. Search engines waste crawl budget on dead internal paths. Pages with broken outbound links signal low editorial quality, which affects how aggressively a site is crawled and how confidently its pages rank. The trust cost arrives faster. A broken link on a service page, a form that routes nowhere, or a resource that 404s mid-checkout is a client-facing incident. When a client finds it before you do, the support conversation costs more time than the fix would have.

The compounding problem is that most agencies discover broken links reactively. They surface in client emails, in an unexplained traffic drop, or during an occasional manual check. There is no system watching the full fleet, and no cadence that guarantees coverage before a problem becomes client-visible. This post addresses that gap with a detection and remediation process that runs across the entire client roster without manual, per-site logins. For the broader SEO picture this process feeds into, see how to run an SEO audit across multiple WordPress sites.

Monitoring broken links at fleet scale requires a detection layer that operates across every site without you logging in manually. Per-site manual checks work for one or two clients. Beyond that, the time cost exceeds the value, and gaps open between check cycles where links break and stay broken for weeks.

A functioning fleet-scale monitoring process has four components:

• Detection: a crawler or scanning extension that runs on a schedule and covers internal links, external outbound links, image sources, and redirect chains longer than two hops.
• Aggregation: a way to collect results from multiple sites into a single view, without logging into each WordPress admin individually.
• Triage: a method for sorting results by impact, so the team addresses a broken link on a high-converting service page before one in a low-traffic archived post from three years ago.
• Remediation protocol: a documented set of fix options (redirect, replace, remove) and assignment rules so fixes happen on a known timeline.

Most agency teams have intentions in all four areas and a functioning system in none. The difference matters at fleet scale, where the gap between intention and execution is exactly where broken links live undetected.

The right broken link checker for an agency running multiple client sites is not necessarily the most widely installed option. Different applications solve different parts of the detection problem, and combining them by use case gives better coverage than any single option alone.

Broken Link Checker is the most widely installed free WordPress scanning extension. It runs server-side, detecting broken links in posts, pages, and comments, and reporting them from within the WordPress admin. The free version works well for individual sites, but it is resource-intensive when left running continuously. The better agency pattern: install it, run a scan, address or export the results, then deactivate it until the next cycle.

Screaming Frog SEO Spider is a desktop crawler that handles multi-site crawls from a central machine. It surfaces broken internal and external links, image errors, and redirect chains. For agencies running monthly site audits, a Screaming Frog batch crawl across the client list is a practical cadence. The free tier crawls up to 500 URLs per site; the paid licence removes that limit and enables scheduled crawls.

Ahrefs and Semrush are the stronger options for tracking broken external links and inbound links that point to 404s on client sites, coverage that a WordPress-native scanner misses entirely. Most agencies running SEO retainers already have access to one of these platforms, and their site audit features surface broken backlinks as a dedicated report separate from the on-site crawl.

ManageWP and MainWP both include site health modules that surface broken link data across connected sites from a shared operational view. If either platform is already part of your fleet management setup, broken link detection fits into the existing monthly pass without requiring a separate step.

A consistent crawl cadence across the full client fleet is what separates reactive fire-fighting from a process an agency can run on schedule. The crawl itself is straightforward; the operational discipline around it is where most agencies fall short.

Set a monthly crawl as the baseline for every client site. Sites in active content production or receiving significant organic traffic should run weekly. Each crawl should cover all internal links (pages, posts, navigation menus, footers), external outbound links in post content, image sources, and redirect chains longer than two hops. Long redirect chains do not register as broken links, but they slow page load and consume crawl budget in ways that compound across a large site.

A practical agency setup pairs Screaming Frog for the monthly structural crawl, run from a central machine or a shared team account, with the Broken Link Checker extension on client sites for between-crawl coverage where you have managed WordPress access. Export all results to a shared sheet or your agency’s project management system, tagged by site and crawl date.

The key discipline is aggregation before triage. Do not fix links as you find them in the crawl. Collect all results first, then bring the full picture to triage. This gives you cross-site visibility: if six clients all link to the same external resource that has gone offline, that is a pattern to address once, not six separate items.

A raw export of 404s is not a fix list; triage determines which broken links cost the most and which can safely wait. Without a triage layer, teams spend equal time on a broken link on a high-converting service page and a broken link in a six-year-old archived post, and neither reflects actual priority.

A workable triage framework runs on three factors: page traffic, page type, and link position.

• Priority 1 (fix within 48 hours): broken links on pages receiving more than 500 sessions per month, on service or product pages, on contact and conversion pages, and in site navigation. These affect the most users and the highest-value paths on the site.
• Priority 2 (fix within the current maintenance cycle): broken internal links on blog posts and resource pages with moderate traffic. These affect SEO and user experience but are not on direct conversion paths.
• Priority 3 (batch quarterly): broken external links on posts receiving fewer than 100 sessions per month. The cost in rankings and experience is low; batching reduces the overhead of addressing them one at a time.

For the fix itself, the remediation options are: a 301 redirect if the content moved to a new URL; a URL replacement if a working alternative exists; link removal if the destination no longer exists and no substitute serves the same purpose; and page restoration if the destination was deleted by mistake. Document every fix in the client’s records with what broke, what was fixed, and when. This is how you detect patterns over time and distinguish a client whose editors routinely delete pages without checking for inbound links from one whose external link rot is an inherent part of linking to third-party sources.

Broken link monitoring delivers value only when it runs on a defined cadence, not when someone remembers to check. The operational goal is a recurring process that requires no judgment to initiate: it runs on a fixed schedule, produces a structured output, and feeds directly into triage and remediation.

A monthly cadence works as follows. On the first working day of each month, run the full fleet crawl across all client sites. By day three, complete triage on all results and assign Priority 1 and Priority 2 items to the responsible person. Priority 1 items are resolved by day five. Priority 2 items are resolved by end of the second week. Priority 3 items are logged and addressed in a batch at the end of the month or carried into the following quarter.

Clients on active SEO retainers should receive a brief broken link summary in their monthly report: how many were found, how many were fixed, and any patterns worth noting. This converts a maintenance task into a visible deliverable that demonstrates the agency’s ongoing attention to each site’s operational health.

Broken link monitoring fits into the broader monthly maintenance pass alongside software updates, uptime checks, performance baselines, and backup verification. The monthly WordPress maintenance routine guide covers how to structure that full pass so every task, including broken link detection, runs on a predictable cadence rather than as an ad hoc event.

At agency scale, WordPress multisite permission failures are almost always governance failures, not configuration errors. WordPress core gives you a capable permission model, but it was not designed for the multi-client complexity an agency introduces: dozens of users, multiple client relationships, contractor rotations, and handoffs where nobody remembers who had access to what.

The core problem is role scope. WordPress multisite operates on two planes: the network level, governed by the Super Admin role, and the site level, governed by the standard WordPress roles (Administrator, Editor, Author, Contributor, Subscriber). These two planes do not automatically translate into client isolation. A site-level Administrator on one subsite cannot access another subsite’s content by default, but a Super Admin can see and operate everything across the entire network.

In practice, agencies over-grant Super Admin status because it is convenient. A developer needs to troubleshoot a theme conflict on a client subsite, and instead of scoping their access correctly, someone elevates them to Super Admin for the day. The elevation never gets revoked. Six months later, that developer is at a different agency and still has full network access to every client site on the network.

When agencies say WordPress multisite is not working, a permission misconfiguration is one of the first things to investigate: the wrong role on the wrong site can block content publishing, expose the admin interface to the wrong people, or prevent client users from accessing the areas they need. The fix is rarely technical. It is a governance model applied consistently.

If you are still weighing whether multisite is the right architecture for your fleet, this post covers the tradeoffs between WordPress multisite and a fleet of single sites. This post assumes you have already made the multisite decision and need to govern it properly.

Every agency multisite network should map to exactly three tiers: network operations, site delivery, and client access. This is not a WordPress-specific concept; it is how any multi-tenant system with confidentiality requirements separates authority from access.

Tier 1: Network Administrators. This tier owns the infrastructure. It can add and remove subsites, manage network-level themes and plugins, and access every subsite on the network. Membership should be limited to agency principals and your most senior technical operators, typically two to four people at most. Anyone in this tier holds the keys to every client relationship on the network.

Tier 2: Agency Operators. These are the people who deliver work: developers, designers, content strategists, project managers. They need site-level access to do their jobs, but they do not need network-level authority. Assign them as Administrators or Editors on the specific subsites they are actively working on. When an engagement ends, their site-level access should be revoked as part of the offboarding checklist, not left in place as a courtesy.

Tier 3: Client Users. Clients interact only with their own subsite. The appropriate role depends on what the client needs to do: a client who publishes content regularly may need Editor access; a client who only reviews drafts needs Contributor or Author. Almost no client should receive Administrator access to their own subsite, because site-level Administrators in a multisite network have capabilities that exceed what a content owner needs.

The tier model also gives you a clean answer to the question of who can see what. Tier 1 sees everything. Tier 2 sees what they are assigned to. Tier 3 sees only their own subsite. When a permission question arises, the answer almost always maps to one of these three tiers; the discipline is in keeping the mapping current and enforced as your fleet grows.

The configuration principle is simple: no client account should ever receive Super Admin status, and no client account should be able to navigate to another client’s subsite. Both outcomes require deliberate configuration, because WordPress multisite does not enforce client isolation by default.

Control user registration at the network level. In Network Admin, go to Settings, then Network Settings, and review the Allow New Registrations option. For most agency fleets, this should be set to No Registrations Allowed. You add users manually, which gives you full control over who enters the network and at what tier. Open registration is appropriate only for networks designed for public membership, not multi-client agency work.

Add users at the site level, not the network level, wherever possible. When you add a user through the Network Admin Users screen, they become a network-level user who can be associated with any subsite. When you add a user through a specific subsite’s Users menu, their account is scoped to that site. Use the site-level path for all Tier 2 and Tier 3 accounts. Reserve the Network Admin Users path for Tier 1 accounts only.

Limit what site Administrators can do. By default, network-activated plugins cannot be installed by site Administrators, which is correct for a managed agency fleet. Confirm that the plugins management screen is not exposed to site-level admins on client subsites. If you are using a WordPress multisite management plugin to extend network capabilities, verify that its settings panel is visible only to Super Admins, not to site Administrators who happen to hold a broad role.

Use role assignment to define delivery boundaries. A developer assigned as Editor on Client A’s subsite and Administrator on Client B’s subsite has a clear and auditable scope for each engagement. That mapping should live in your agency’s documentation, reviewed at each project kickoff and each offboarding. The configuration step is simple; the discipline is in maintaining it as the fleet scales.

Contractor access is where permission drift accelerates fastest: temporary users added for a sprint rarely get removed when the engagement ends. A contractor who had Editor access on three client subsites during a build often still has that access a year later, because nobody owns the offboarding step.

Treat contractor access as a named, time-bound decision, not a standing configuration. When you add a contractor as a Tier 2 operator on a specific subsite, record three things: which subsites they have access to, what role they hold, and when that access expires. That record belongs in the same place your agency stores every other operational decision, not in someone’s inbox or a chat thread that will scroll out of reach.

Scope contractor access to the minimum required. A contractor building a WooCommerce integration does not need Administrator access to do the work; they need the specific capabilities the role provides. If your multisite configuration allows role customization, use it. If it does not, assign the next role down and document any exceptions so the next person who looks at the account understands why it exists.

Guest access for client stakeholders reviewing work but not managing content is a distinct case. A client’s marketing lead who needs to preview a campaign page before launch does not need a persistent account with ongoing access. Persistent accounts should be reserved for users who have a recurring operational reason to be in the site. One-time or time-limited review requests should not result in permanent user records.

When you manage multiple WordPress sites across different clients, the contractor access problem multiplies. The same contractor may hold access across several subsites, added at different times by different project leads, with no single person holding the complete picture. A cross-network access review is what surfaces this; the discipline of scoping access correctly at the point of addition is what prevents it from accumulating in the first place.

A quarterly access review is the minimum cadence for any multisite fleet managing three or more client sites. Without it, permission drift compounds: accounts accumulate, roles inflate, and nobody holds a current picture of who can do what across the network.

Start at the network level. In Network Admin, navigate to the Users screen to see every account on the network. Review any account with Super Admin status and confirm each one belongs in Tier 1. If you find Super Admin accounts that belong to former employees, contractors, or clients, revoke Super Admin status immediately, then determine whether the underlying account should remain on the network at all.

Audit each subsite individually. Navigate to each subsite’s Users menu and review who holds what role. Cross-reference against your active client roster and active team assignments. Former clients should have no accounts on their former subsites. Former project contributors should have their access revoked unless they are still actively engaged. This is tedious to do manually at scale, which is why a documented process with a named owner is essential.

Look for role inflation. A common pattern in agency fleets is that a user starts as an Editor and gets promoted to Administrator for a specific task, then the promotion is never reversed. Review every Administrator-level account on every client subsite and confirm the role is still appropriate. If it is not, downgrade it and note the change in your audit record.

Document what you find and what you change. An access review that produces no record is not an audit; it is a spot-check. The record should note the date, who conducted the review, what was found, and what was changed. This documentation protects the agency if a client ever raises a data access concern, and it provides a baseline for the next quarterly cycle.

A permissions policy that lives only in someone’s head is not a policy; it is a liability. The goal here is a written governance document that any team member can follow when onboarding a new client, adding a contractor, or conducting a quarterly review.

The document does not need to be long. It needs to cover four things: the three tiers and who belongs in each one, the role mapping (which WordPress roles correspond to which delivery or client scenarios), the review cadence and who owns it, and the onboarding and offboarding checklists.

The onboarding checklist runs once per new client subsite provisioned and once per new team member assigned to a site. It covers which Tier 2 accounts need site-level roles and at what level, and what initial Tier 3 accounts are created for the client. Starting clean matters: it is far easier to grant access incrementally than to revoke it after the fact, once the relationship is established and the account has become load-bearing.

The offboarding checklist is more important and more often neglected. When a client engagement ends, every Tier 2 account added for that engagement should be reviewed and either revoked or preserved with documented justification. When a team member leaves the agency, their access across the entire fleet should be revoked, not just from their most recent project. This is the step that prevents the permission accumulation described in the earlier sections.

The most durable place for this policy is the system your agency uses to record operational decisions. Agencies running their fleet on WPOS store this kind of governance documentation in their Playbook, where it persists across team turnover and is accessible when a new hire needs to understand the access model. The handoff problem is closely related: when a project lead leaves, the institutional knowledge about who has access to what should not leave with them.

Enforce the policy by embedding it in the project cadences your team already runs. The quarterly review should be a calendar item with a named owner, not a good intention. Each project kickoff includes a permissions setup step. Each project close includes a permissions cleanup step. When the governance model is woven into existing operations rather than standing apart as a compliance exercise, it gets done.

A WordPress site agent is the operating layer that connects directly to a live client site, reads its current state, executes delegated tasks, and logs every decision into a per-site Playbook. This is a materially different thing from the AI website builders that generate a site once and forget everything. The site agent is persistent: it carries context forward from every command, every approved decision, and every Playbook entry you add over time.

What it replaces is scattered: the Slack threads where client context lives, the Notion doc a developer hasn’t updated in eight months, the 20-minute context-rebuild every time someone new touches a site. When institutional knowledge lives in those places, it walks out the door with the person who wrote it. A site agent moves that knowledge into a structured Playbook attached to the site, where every future operator can access it and the agent can reference it automatically.

For a deeper grounding in what this operating layer looks like across a WordPress fleet, read What Is an Operating System for WordPress? before proceeding.

The highest-value move before connecting any site is to sort your fleet into three tiers: actively developed, live and stable, and in maintenance. This isn’t just an organizational exercise. It determines where the site agent’s Playbook context needs to be deepest (active development sites), where a lighter seed is sufficient (stable live sites), and where a basic status log is enough for now (maintenance sites).

Start with your top three active client sites. Running the full connection and Playbook setup on a handful of high-activity sites gives you signal within a week, which is far more useful than a thin setup across 40 sites simultaneously. The goal on day one is not coverage. It is depth on the sites where the most decisions are being made right now.

Before you open the Workspace, pull together the context that exists but isn’t structured: the email threads where a client approved a design direction, the Slack message where your developer explained why a plugin was excluded, the notes from the last site review call. These are the raw material for your initial Playbook entries. Collecting them before you start means the agent has real context to work with from the first command.

Connecting a site agent to a client WordPress site starts in your WPOS Workspace, where each site gets its own Command Center. The process is the same for every site in your fleet, which means once you have run it once, you can move through the remaining connections quickly.

1. Add the site to your Workspace. From the Workspace, select the option to add a new site and enter the site URL. This creates the site record that the Playbook, Decisions log, and agent activity will attach to.
2. Install the Command Center. WPOS pushes the Command Center installation from the Workspace. Once installed and activated inside wp-admin, the Command Center appears as a dedicated surface where the site agent operates and where site-level commands can be issued directly.
3. Authenticate the connection. Connect the Command Center to your Workspace using the credentials generated during setup. This is the link that lets the Workspace and the site agent communicate: commands issued from the Workspace flow through to the Command Center, and activity logged in the Command Center surfaces back in the Workspace.
4. Confirm the connection is active. Both the Workspace view and the Command Center inside wp-admin should show the site as connected. Run a basic status check to confirm the agent can read and respond.

Repeat this sequence for each site in your priority tier. The Command Center on each site is independent: changes to one site’s Playbook or agent configuration do not propagate to other sites unless you explicitly push a fleet-wide update from the Workspace.

The Playbook entries you create on day one are the foundation every future conversation with the site agent builds on. A sparse Playbook means the agent has to ask for context repeatedly. A well-seeded Playbook means the agent can operate with the standing knowledge of a senior developer who has worked on that client for years.

The Playbook is organized into Chapters. Start with three for each new site:

• Brand: The client’s brand guidelines, approved tone of voice, color and typography rules, and any explicit restrictions. If the client has ever said “we never use X” or “always lead with Y,” that goes here.
• Audience: Who the site is for. Buyer personas, geographic focus, the problems the site is designed to solve for visitors. This gives the agent the context to assess whether any content or structural decision is aligned with the site’s actual purpose.
• Decisions: The standing decisions that govern the site. Approved plugin stack, hosting constraints, structural choices that were debated and resolved. Every decision logged here is one the agent doesn’t need to re-derive from scratch in future commands.

The other Chapters (Conversations, Components, Site map, Lessons, Internal) fill in over time as the agent logs activity and you add entries from ongoing work. Day one is about Brand, Audience, and Decisions: the context the agent needs to operate without hand-holding from the first command.

The first commands you run across the fleet should be observational: ask each site agent to report the current status, flag content that hasn’t been updated in 90 days, and surface any plugin versions that are lagging. These commands cost nothing to run, return immediate signal, and log the baseline state into the Playbook so future comparisons have a reference point.

From the Workspace, you can issue fleet-level commands that run across all connected sites. From the Command Center on an individual site, you can issue per-site commands with the full Playbook context of that specific client available to the agent. Both surfaces use the same command format: state what you need, and use Plan mode for anything multi-step so you can review the execution sequence before the agent proceeds.

Useful first commands for a newly connected fleet:

• Run a site status report and log the result as a baseline entry in the Decisions chapter.
• Ask the agent to identify any pages where the headline or meta description doesn’t align with the Brand chapter entries you just seeded.
• Flag any active plugins that weren’t part of the approved stack recorded in the Decisions chapter.
• Request a list of the five most recently modified pages, with the last-modified date and the responsible user.

Each of these commands generates a Task the agent tracks to completion. The Task log becomes part of the site’s Playbook history, which means the next operator who opens the Command Center can see what was run, when, and what it returned, without asking anyone.

After 30 days of active commands and Playbook entries, the site agent surfaces patterns that no manual reporting would catch at fleet scale. This is where the compounding argument becomes concrete rather than theoretical.

Watch for three early pattern signals:

• Repeated decisions. If the agent flags the same type of issue across multiple sessions on a single site, the underlying cause belongs in the Decisions chapter as a standing rule, not in the session log as a recurring task. The Patterns I’ve noticed feature surfaces these clusters so you can act on the root cause, not the symptom.
• Cross-site drift. Sites configured identically six months ago will diverge as different developers make small choices. Fleet-level pattern detection surfaces when two sites that should match have drifted, before the client notices.
• Knowledge gaps in the Playbook. When the agent asks a question you’ve already answered on another site, that answer belongs in both Playbooks. The Workspace view lets you identify Playbook entries present on some sites but missing on others, so you can standardize the standing context across the fleet.

The accumulation argument for the site agent is straightforward: after six months of active use, the Playbook for each client site contains more institutional knowledge than any individual on your team holds in their head. That context doesn’t resign, go on leave, or forget what was decided in Q3. It stays attached to the site, compounds with every new command, and makes every future operator immediately functional on a site they’ve never touched before.

For agencies ready to run this across a full client fleet, see WPOS pricing for fleet-tier options.

A runbook is not a checklist; it is the operational document that captures what to do, why each step exists, and what to do when a step fails. A checklist is a memory aid for someone who already knows the procedure. A runbook is the procedure itself, documented for anyone on the team, including the person who joined last week.

The distinction matters at agency scale. When you manage multiple WordPress sites across a rotating team, a checklist relies on tacit knowledge that leaves with each departing employee. A runbook externalizes that knowledge into a persistent document the team can run against, audit, and improve over time.

Consider a site launch. A checklist might say: “Enable caching.” A runbook entry says: “Enable caching on the production server using the agency standard configuration (see: Site Variables, Caching Layer), because uncached WordPress under traffic load on launch day caused the Q3 client incident. If the caching layer fails to activate, revert to the static pre-launch state and open an incident.” That third sentence, the recovery path, is what a checklist never carries. It is what turns a generic instruction into a durable operational asset.

A checklist is disposable. A runbook compounds. Every time a team member executes a procedure and updates the entry afterward, the document becomes more reliable. After two years of consistent use and post-incident updates, the runbook carries institutional knowledge no individual on the team could reconstruct from memory alone.

Five operations recur in every WordPress agency regardless of team size: site launch, core and extension updates, client onboarding, scheduled WordPress maintenance, and incident response. These are not the only operations an agency runs, but they are the ones where undocumented procedure causes the most expensive failures.

Site launch covers the full sequence from staging sign-off to DNS propagation confirmation. Every agency has learned at least one painful launch lesson; the runbook is where those lessons live permanently, not in the memory of a senior developer who may leave next quarter.

Core and extension updates covers the cadence, the staging verification step, the production deployment sequence, and the rollback trigger condition. This is the operation most agencies run informally, and the one that causes the most unplanned downtime. A WordPress maintenance plan that scales across multiple client sites depends on this runbook entry being precise and consistently followed across the fleet.

Client onboarding covers the steps to provision a site in the agency’s operating environment: access grants, branding kit configuration, initial site status, and the first Playbook entries. Documenting this operation reduces new client setup from a three-person coordination effort to a one-person procedure.

Scheduled maintenance windows cover the client communication sequence (when to notify, through which channel), the maintenance-mode activation procedure, the scope of work to be performed, and the verification sequence before the site returns to live status.

Incident response is the operation most agencies never document until after a damaging incident. The runbook entry does not need to anticipate every failure mode; it needs to establish the response sequence: detect, contain, communicate, resolve, and record. A team following a documented sequence under pressure makes fewer compounding errors than one improvising from memory.

Each runbook entry needs four components: the trigger condition, the ordered procedure, the verification step, and the rollback path. Without all four, the entry is a partial document that forces the operator to improvise at exactly the wrong moment.

The trigger condition answers: what causes this operation to run? For a site launch, it is client sign-off on staging plus a confirmed DNS cutover window. For a core update, it is a new WordPress release with a security classification. Documenting the trigger removes ambiguity about when to start and prevents premature execution on a site that is not ready.

The ordered procedure is the numbered sequence of steps. Each step should be atomic enough to verify independently: not “configure the server” but “set PHP memory limit to 256MB in wp-config.php and confirm with a phpinfo() check.” When an operation uses wordpress automation (a deployment script, a backup command, a pre-launch preflight), the runbook step names the script and its expected output, not just the intention behind it.

The verification step answers: how do you know the operation succeeded? For a site launch, this is a structured list of URLs to test, a load threshold to confirm, and a client confirmation to collect. For a maintenance window, it is a specific set of site functions to confirm are operating correctly before the maintenance notice comes down. Verification that cannot be checked is not verification.

The rollback path is the most important component and the most commonly omitted one. For every operation, document the condition that triggers a rollback and the exact steps to reverse the procedure. A runbook entry without a rollback path is incomplete for any operation that touches a live site.

A runbook entry carrying all four components is self-sufficient: a new team member can execute a covered operation without asking a senior colleague. That is the practical test for whether an entry is complete enough to ship.

A runbook that lives in a shared document no one maintains is almost as costly as a runbook that does not exist; survival requires ownership, version history, and rationale embedded in every step. The institutional memory leak is the most expensive failure mode for a growing WordPress agency, and a decaying runbook is still a leak.

Assign an owner to each operation entry. The owner is the person responsible for keeping the entry current, not necessarily the person who executes the procedure. When an entry becomes outdated, there is a named person to update it. When a team member leaves, the handoff explicitly includes their runbook entries, with the incoming owner reviewing and approving the current state before the departure is complete.

Store the runbook in a system that records change history. When a procedure changes, capture the reason alongside the change. Three months after an update, “changed caching activation step because new server infrastructure requires a different sequence” is worth far more than the updated step alone. Rationale in the version history prevents the team from reverting a deliberate change because they no longer remember why it was made.

Embed rationale inside the entries themselves, not only in the version history. The rationale does not need to be long: a single sentence per step that would surprise a new operator is enough. Steps that “everyone knows” are the first ones to cause incidents when the people who knew them leave.

Use the onboarding test as the most reliable quality check: give a new team member a runbook entry for an operation they have not performed before and ask them to execute it without assistance. Every place they stop and ask a question is a gap in the runbook, not a gap in their knowledge. Close those gaps before the next execution, not after.

A runbook disconnected from site-specific context delivers generic instructions that fail on site-specific details; every operation entry should reference the variables that change from one client site to the next. The procedure for a core update is the same across your fleet in structure, but the staging URL, the backup location, the client communication contact, and the rollback threshold differ per site.

Structure runbook entries to distinguish the constant procedure (steps that apply to every site) from the site variables (the values that change). The constant procedure lives in the runbook. The site variables live in the site record. When an operator runs the update procedure for a specific client, they follow the constant procedure and substitute the site-specific values from that client’s record. This structure scales to a fleet of any size without duplicating procedures.

This is what it means to operate WordPress as an operating layer across your agency fleet rather than treating each site as a standalone engagement. The same runbook entry governs all client sites; only the site variables differ. Agencies that manage multiple WordPress sites at scale know that per-client procedural duplication is where consistency breaks down first.

Site variables worth recording for each client include: staging and production URLs, backup schedule and storage location, client communication contacts with their notification preferences, performance baselines, and any site-specific constraints that override the standard procedure. A client who requires 72 hours advance notice before any maintenance window is a site variable, not a note buried in a chat thread that no one will find at 11pm on a Tuesday.

Connect the runbook to each site’s Playbook entries so that recorded decisions surface during the operations they govern. A client preference recorded in the Decisions log should be visible when the maintenance runbook entry is opened for that site. Without that connection, the decision exists but does not govern the operation, which is the structural gap that produces client-facing errors that feel surprising and are entirely avoidable.

Every incident is a runbook audit: if a step failed or was improvised under pressure, the gap belongs in the document, not only in the post-mortem. The instinct after an incident is to fix the immediate problem and move on; the discipline is to spend thirty minutes updating the runbook before closing the incident record.

Run a structured post-incident review after any incident that required improvisation or caused client impact. The review asks four questions: what was the trigger, what step failed or was missing, what did the team do instead, and what would the correct runbook entry have said? The answer to the last question is the update. Write it before the memory of the improvisation fades, because that improvisation is the most valuable data the incident produced.

Not every incident reveals a runbook gap; some reveal a gap in a site variable record. If a team member improvised because a staging URL was not recorded, the update is to the site record, not the procedure. Distinguishing between procedure gaps and information gaps ensures updates go to the right place and the runbook does not accumulate site-specific data that belongs elsewhere.

Track the update frequency as a signal. A runbook entry updated five times after incidents in six months indicates an unstable operation, one that warrants investigation into whether the underlying procedure is sound. A high-frequency operation entry untouched for two years is a candidate for a scheduled review: either it is genuinely stable, or the team has stopped recording incidents against it.

The compounding value of a living runbook is that each update makes the next execution of that operation safer. An agency that has run site launches for five years and updated its launch entry after every gap now holds five years of collective learning in a single document. That document belongs to the agency, not to any individual on the team. It is what separates an agency that operates a fleet from one that manages a collection of sites one at a time.