WordPress multisite introduces a permissions layer most solo operators don’t expect: the distinction between a site administrator and a network super admin. If you’ve ever granted someone “admin” access and watched them fail to install plugins, or wondered why a client can’t manage billing when they “own” their site, this is why.
The role split isn’t a bug. It’s architectural. But it catches people off guard because single-site WordPress collapses these into one role, and most multisite documentation assumes you’re running a university network, not a cluster of client sites or a portfolio of properties you manage alone.
What each role actually controls
A site administrator has full control over content, users, themes, and settings within a single site on the network. They can publish posts, moderate comments, manage menus, assign roles to other users on that site, and switch between themes—if you’ve allowed theme switching at the network level.
They cannot install or activate plugins, install new themes, edit PHP files via the theme editor (even if it’s enabled), access the network admin dashboard, or create new sites. Those permissions belong exclusively to the super admin.
A super admin controls the entire network. They can create and delete sites, install and network-activate plugins, upload themes, manage network-wide settings, and promote or demote users across all sites. They also inherit site-level admin privileges on every site in the network, whether explicitly assigned or not.
If you’re running a multisite as a solo operator—maybe you manage five niche content sites under one installation, or you host client projects—you’re almost certainly the only super admin. Everyone else, including clients who “own” their site, is a site administrator at best.
When role confusion breaks workflows
The most common issue: a client or collaborator reports they can’t install a plugin you told them to use. You check their account, see “Administrator” next to their name, and assume the platform is broken. It’s not. They’re a site admin, not a super admin, and multisite doesn’t let site admins touch plugins by default.
The second surprise: user management. A site administrator can add users and assign roles on their site, but they can’t remove a user from the network entirely. If someone needs to be deleted—not just demoted or removed from one site—that’s a super admin task. This creates cleanup debt if you don’t audit regularly.
The third trap: billing and domain mapping. If you’re using a plugin like Mercator or a host-managed domain mapping tool, site admins often can’t change the primary domain, even if they “own” the site contractually. That permission usually requires super admin access or a custom capability you’ve explicitly granted.
How to audit and delegate access correctly
Start by listing every user with super admin privileges. In the network admin dashboard, go to Users → Super Admins. If you see names you don’t recognise, or former contractors still listed, remove them immediately. Super admin is an all-or-nothing role; there’s no way to grant partial network control without a custom plugin.
For site-level access, go to each site’s dashboard and review Users → All Users. Confirm that client administrators are scoped to their site only. If someone needs plugin installation rights but shouldn’t control the whole network, you have three options:
- Pre-install and network-activate the plugins they need, then let them configure settings as a site admin
- Use a plugin like Multisite Plugin Manager or User Role Editor to grant granular capabilities—like
install_plugins—to site admins on a per-site basis - Promote them to super admin temporarily, have them complete the task, then demote them (risky, not recommended for clients)
Most operators choose option one. It’s cleaner and avoids the support overhead of explaining why a client can activate a plugin but not delete it from the network.
One non-obvious behaviour: user registration on multisite
If you enable open registration at the network level (Network Admin → Settings → Allow new registrations), users who sign up are added to the network, not automatically to any specific site. They exist in the user table but have no role and no dashboard access until a site admin or super admin assigns them to a site.
This confuses operators who expect self-service membership sites. A user registers, receives a confirmation email, logs in, and sees a blank dashboard with no menu items. They’re authenticated but not authorised anywhere. You have to assign them to a site and give them a role—Subscriber, Contributor, whatever fits—before they see content or functionality.
If you’re running a paid community or course platform on multisite, automate this with a membership plugin that handles role assignment on purchase. Don’t rely on WordPress’s default registration flow.
Multisite user roles aren’t complicated once you internalise the two-tier structure. But if you’re migrating from single-site WordPress or onboarding a client who expects full control, set expectations early. “Administrator” means something different here, and assuming otherwise costs you support time you don’t have.
One Two Three Send publishes operator-focused breakdowns like this one every day. Subscribe to catch the next deep dive on the tools and infrastructure that actually matter.