How to Manage WordPress Multisite User Permissions Across an Agency Fleet

u003cpu003eAt 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.u003c/pu003eu003cpu003eThe 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.u003c/pu003eu003cpu003eIn 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.u003c/pu003eu003cpu003eWhen agencies say u003cstrongu003eWordPress multisite is not workingu003c/strongu003e, 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.u003c/pu003eu003cpu003eIf you are still weighing whether multisite is the right architecture for your fleet, u003ca href=u0022/blog/how-agencies-should-decide-between-wordpress-multisite-and-a-fleet-of-single-sites/u0022u003ethis post covers the tradeoffs between WordPress multisite and a fleet of single sitesu003c/au003e. This post assumes you have already made the multisite decision and need to govern it properly.u003c/pu003e

u003cpu003eEvery 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.u003c/pu003eu003cpu003eu003cstrongu003eTier 1: Network Administrators.u003c/strongu003e 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.u003c/pu003eu003cpu003eu003cstrongu003eTier 2: Agency Operators.u003c/strongu003e 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.u003c/pu003eu003cpu003eu003cstrongu003eTier 3: Client Users.u003c/strongu003e 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.u003c/pu003eu003cpu003eThe 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.u003c/pu003e

u003cpu003eThe 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.u003c/pu003eu003cpu003eu003cstrongu003eControl user registration at the network level.u003c/strongu003e 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.u003c/pu003eu003cpu003eu003cstrongu003eAdd users at the site level, not the network level, wherever possible.u003c/strongu003e 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.u003c/pu003eu003cpu003eu003cstrongu003eLimit what site Administrators can do.u003c/strongu003e 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 u003cstrongu003eWordPress multisite management pluginu003c/strongu003e 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.u003c/pu003eu003cpu003eu003cstrongu003eUse role assignment to define delivery boundaries.u003c/strongu003e 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.u003c/pu003e

u003cpu003eContractor 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.u003c/pu003eu003cpu003eTreat 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.u003c/pu003eu003cpu003eScope 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.u003c/pu003eu003cpu003eGuest 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.u003c/pu003eu003cpu003eWhen you u003cstrongu003emanage multiple WordPress sitesu003c/strongu003e 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.u003c/pu003e

u003cpu003eA 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.u003c/pu003eu003cpu003eu003cstrongu003eStart at the network level.u003c/strongu003e 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.u003c/pu003eu003cpu003eu003cstrongu003eAudit each subsite individually.u003c/strongu003e 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.u003c/pu003eu003cpu003eu003cstrongu003eLook for role inflation.u003c/strongu003e 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.u003c/pu003eu003cpu003eu003cstrongu003eDocument what you find and what you change.u003c/strongu003e 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.u003c/pu003e

u003cpu003eA 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.u003c/pu003eu003cpu003eThe 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.u003c/pu003eu003cpu003eu003cstrongu003eThe onboarding checklistu003c/strongu003e 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.u003c/pu003eu003cpu003eu003cstrongu003eThe offboarding checklistu003c/strongu003e 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.u003c/pu003eu003cpu003eThe 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. u003ca href=u0022/blog/how-do-wordpress-agencies-run-client-handoffs-without-losing-institutional-knowledge/u0022u003eThe handoff problem is closely relatedu003c/au003e: when a project lead leaves, the institutional knowledge about who has access to what should not leave with them.u003c/pu003eu003cpu003eEnforce 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.u003c/pu003e