WordPress User Roles: Who Should Get What Access

WordPress ships with five user roles out of the box: Subscriber, Contributor, Author, Editor, and Administrator. Plus Super Admin for multisite. The default structure works fine for a single-person blog but creates problems on team sites where the available roles don't match the access patterns the team needs.

The questions that matter for role design are: who needs to publish, who needs to edit other people's work, who needs to install plugins, who needs to add new users, who needs to change site-wide settings. The default roles bundle these questions in ways that often don't match real teams.

What the default roles do badly

The Administrator role can do everything. Adding plugins, editing theme code, deleting users, changing site URL. For a small team, giving Administrator to multiple people means any one of them can break the site catastrophically, intentionally or accidentally.

The Editor role can publish anyone's content but can't change site settings or install plugins. This is closer to a useful boundary but still allows editors to modify content from other editors, which isn't always what teams want.

The Author role can publish their own posts but can't see drafts from other authors. This blocks collaborative workflows where authors want to give each other feedback before publishing.

The role structure that works for teams

For sites with 5-20 contributors, the structure that scales without creating headaches:

Site Administrator (1-2 people): full Administrator access. Responsible for plugin updates, security, billing, and incident response.

Content Manager (1-3 people): Editor role with optional custom capabilities to manage user roles below Editor. Approves submissions, publishes scheduled content, manages editorial calendar.

Senior Author (3-8 people): Editor role, but the team agrees informally that Senior Authors edit their own content and request review from the Content Manager rather than editing each other directly. Capability-wise they could edit each other; the team agreement creates the boundary.

Author (4-15 people): Author role with default capabilities. Writes posts in their assigned categories, manages their own media uploads.

Contributor (variable): Contributor role for freelancers or guest writers. Can write drafts but can't publish.

When the defaults need plugins

Several plugins extend WordPress's role system meaningfully. Members and User Role Editor are the longstanding tools; PublishPress Capabilities is the modern version with the cleanest UI.

The customizations worth making in role plugins:

• Restrict Editors from changing user roles (especially adding new Administrators)
• Create a "Reviewer" role with capability to comment on drafts but not edit them
• Give specific roles access to specific plugins (e.g., only Content Manager can access the SEO plugin settings)
• Create role-based content visibility (some posts visible only to logged-in users with specific roles)

The security boundary that matters

The most important security boundary is the Administrator-or-not boundary. Administrators can install plugins, which means Administrators can run arbitrary code on the server. A compromised Administrator account is effectively a compromised site.

For this reason, Administrator access should be tightly limited and used only for actual administration. Don't give Administrator to people who only need to edit content. Don't share Administrator credentials across multiple people. Use individual accounts so revoking one person's access doesn't lock everyone out.

Two-factor authentication on Administrator accounts is non-negotiable. The threat model: an attacker who phishes one Administrator credential can install a backdoor plugin and persist access even after the password is changed. 2FA stops the initial compromise.

The team agreement that supplements technical roles

Capabilities define what a role can do. Team agreement defines what a role should do. The two should align, but they don't have to be enforced at the same level.

For example: Editors could technically delete any post. The team agreement might be that Editors don't delete posts older than 6 months without checking with the Content Manager. This isn't enforced by capabilities; it's enforced by professional practice.

The pattern works because most violations of team agreement aren't malicious; they're accidents or unclear expectations. Writing the agreement down (in a wiki page that new team members read during onboarding) prevents most of those accidents without requiring complex capability customization.