- Guide
- Advanced
- 5 minutes read
- Reviewed August 5, 2026
- WordPress users, roles and permissions
WordPress Multisite allows one installation to operate a network of sites.
User identities are shared across the network, while roles and capabilities are generally assigned in the context of individual sites. A person can therefore exist in the network but have different access on different sites.
Shared Users, Separate Site Membership
Multisite uses shared user tables for the network. Creating a user once establishes the identity, but that does not mean the account has the same role on every site.
Site membership and capabilities are associated with the relevant site context. A user might be an Editor on one site, a Subscriber on another and have no role on a third.
The Super Admin Role
Super Admins control network-level administration. They may manage sites, network users, plugins, themes and network settings.
This role is more powerful than a single-site Administrator and should be restricted to network operators who genuinely need that control.
A site Administrator in Multisite cannot necessarily install plugins or themes because those decisions may be reserved for the network.
Site Administrators
A site Administrator manages one site within the network, subject to restrictions imposed by Multisite and the Super Admin.
Their capabilities can differ from a single-site Administrator. Documentation and support procedures must account for this difference so site owners do not assume missing menus are a bug.
Adding Existing Users to Sites
Because identities are shared, an existing network user can be added to another site and assigned a site-specific role.
Before adding them, verify:
- The site they should access.
- The role required on that site.
- Whether the network policy permits the action.
- Whether plugins add custom roles or site-specific capabilities.
Avoid assigning roles across every site merely for convenience.
Network Plugins and Permission Changes
A network-activated plugin can affect roles and capabilities across many sites. A site-activated plugin may affect only the site where it runs, depending on implementation.
Custom role migrations must consider:
- New and existing sites.
- Network activation.
- Per-site option storage.
- Users with different roles across sites.
- Uninstall and rollback behaviour.
Test permission changes in a realistic Multisite staging environment.
Content and Data Boundaries
Most site content uses site-specific database tables, while users are shared. Plugins may store network-wide or site-specific data.
A permission to view data on one site should not automatically expose data belonging to another site. API endpoints and custom queries must enforce site context correctly.
Registration and Network Policies
Multisite can support different registration models for users and sites. Network administrators should define:
- Who can create accounts.
- Who can create sites.
- Default site roles.
- Domain or email restrictions.
- Site-ownership and deletion policies.
- Support responsibilities.
Do not apply single-site registration assumptions without reviewing network settings.
Audit Multisite Access in Layers
Review:
- Super Admins.
- Network-level service accounts.
- Site memberships.
- Roles on each site.
- Network and site plugins that modify capabilities.
- External hosting and deployment access.
A user list from one site does not describe the complete network.
Frequently Asked Questions
Is a Multisite user automatically a user of every site?
The identity exists in the network, but site membership and role are assigned per site.
Is a site Administrator the same as a Super Admin?
No. Super Admin controls the network. Site Administrators operate within the permissions available on an individual site.
Can roles differ between sites?
Yes. Plugins and configuration can create different role definitions and assignments per site.
Applying Users and Permissions in WordPress Multisite in a Real WordPress Project
Assign access from responsibilities and capabilities rather than job title or convenience. Use named accounts, least privilege, clear recovery ownership and a documented process for reviewing and removing access.
A connected concept is WordPress Multisite. Reading the two together helps separate the immediate task from the wider WordPress responsibility.
A useful implementation begins by writing down the current state, the intended outcome and the evidence that will prove the change worked. This prevents a configuration screen, plugin recommendation or code snippet from becoming the entire strategy.
A Practical Example
Imagine a team making this decision for a production WordPress site. The useful question is not only “Can WordPress do this?” but “Which layer owns it, who maintains it, what data does it affect and how will we verify it after an update?”
Write the answer in operational terms. Name the content, user, setting, file, API or service involved. Then identify what should remain true if the theme changes, a plugin is replaced or the site is migrated.
Questions to Ask
- What user or system problem does this solve?
- Which WordPress layer owns the behaviour?
- What data is created or changed?
- Who may perform the action?
- What can fail, and how will that failure be visible?
- How is the result tested after updates?
- What is the migration or removal path?
Test Capabilities, Not Labels
Role names are useful for administration, but secure code should normally test the capability required for the action. Plugins can change role definitions, and Multisite introduces additional network context.
Create test accounts with realistic permissions and verify both the interface and direct requests. Hiding a menu item does not protect the underlying operation.
Keep Site and Network Context Explicit
Multisite shares users and code while storing much content and configuration per site. Record whether an operation belongs to one site, every site or the network itself.
When switching site context programmatically, restore the previous context and verify that permissions, options, uploads and URLs come from the intended site.
Official Reference Context
The WordPress Roles and Capabilities is the primary version-specific reference for this topic. Use the current documentation to verify interface labels, supported APIs and behaviour before applying instructions to a production site.
How to Verify the Result
- Sign in with a test account for each important role.
- Confirm both visible menus and direct permission checks.
- Review account recovery, session revocation and offboarding.
Related Articles
- WordPress Multisite
- WordPress Multisite: An Introduction
- Default WordPress User Roles Explained
- Troubleshooting WordPress Permission Problems