Every WordPress site is a small permission system pretending to be a content tool. The moment a second person logs in, you have to answer a question the software cannot answer for you: how much of the site does this person actually need to touch? Get it wrong in the generous direction and a freelance writer can deactivate your security plugin. Get it wrong in the stingy direction and your editor pings you on Slack every afternoon to publish a post they wrote. This article is about hitting the middle — assigning access that matches what people genuinely do, and knowing exactly which lever to pull when the five built-in roles don't fit.

Roles are just named bundles of capabilities

WordPress doesn't really think in roles. Internally it thinks in capabilities — atomic permissions like publish_posts, edit_others_posts, manage_options, install_plugins, and edit_users. A role is nothing more than a saved set of these checkboxes stored in your database under the wp_user_roles option. When you understand that, the whole system stops feeling rigid. You are never stuck with the defaults; you are one capability edit away from any boundary you want.

The five standard roles map to capability bundles like this:

Subscriber — can read and manage their own profile. Useful for membership sites and comment gating, useless for a content team.
Contributor — has edit_posts but not publish_posts or upload_files. They can draft, but they cannot publish and, surprisingly, cannot upload images. That missing upload capability trips up nearly every team that uses this role for guest writers.
Author — can publish_posts and upload_files, but only ever sees their own content. No edit_others_posts.
Editor — has the full content stack including edit_others_posts, delete_others_posts, moderate_comments, and manage_categories. No site-configuration power.
Administrator — has everything, crucially including manage_options, install_plugins, edit_themes, and edit_users.

On multisite there's a sixth tier, Super Admin, who holds network-wide capabilities like manage_network and create_sites that don't exist on single installs.

The one line that divides your whole site

If you remember nothing else, remember this: the meaningful security frontier is not Editor vs. Author. It is Administrator vs. everyone else, and the capability that draws the line is install_plugins (alongside edit_plugins and edit_themes).

Plugin installation is arbitrary code execution. A plugin is PHP that runs on your server with your database credentials. So anyone who can install a plugin can, in practice, do anything the server can do — read your wp-config.php, exfiltrate user data, or drop a persistent backdoor that survives a password reset. This is why a phished Administrator password is not a content problem, it's a server compromise. Treat every Administrator account as a key to the building, not a key to a desk.

Practical consequences:

Keep the Administrator count in the low single digits. One or two people on a small site; a tightly defined ops group on a large one.
Never share a login. Individual accounts mean you can revoke one person without resetting everyone, and your audit trail actually points at a human.
Enforce two-factor authentication on every account with install_plugins. Free plugins like Wordfence Login Security or the 2FA built into miniOrange and Solid Security cover this. On Administrator accounts, 2FA is not optional hardening — it's the control that stops the most damaging attack class WordPress has.

Where the defaults quietly fail real teams

Three friction points show up again and again once more than a couple of people share a site.

Contributors can't add images

You hand a guest writer the Contributor role, they draft a beautiful post, and then they can't insert a single screenshot because upload_files isn't in the bundle. Teams usually solve this badly by promoting them to Author — which also hands them publish_posts, defeating the entire point of the review gate. The correct fix is to add upload_files to the Contributor role and leave publishing locked.

Editor is all-or-nothing across other people's work

The Editor role can edit, and delete, everyone's content. There is no built-in "senior writer who can publish their own but only suggest changes on others'." If your editorial culture relies on review rather than direct overwrites, capabilities alone won't express that — you'll need either a custom role or a team agreement layered on top (more on that below).

Settings access is bundled with content power

The person who runs your SEO plugin or configures your email forms often needs manage_options-adjacent access to one plugin's settings — but the only role that grants settings access is Administrator, which also grants plugin installation. There's no native middle tier of "trusted configurator who can't run code."

Reaching for a role plugin — and which one

When the defaults pinch, a role-management plugin lets you edit capabilities through a UI instead of hand-coding add_role() calls. The current landscape:

PublishPress Capabilities (formerly Capability Manager Enhanced) is the one I'd start with in 2026. Clean interface, per-role capability grids, the ability to clone a role before editing it, and granular control over editorial and block-editor permissions. It pairs naturally with the rest of the PublishPress editorial suite.
Members (by the Awesome Motive / MemberPress team) is the veteran. Rock-solid, adds content-access control by role, and integrates with membership flows.
User Role Editor is the long-standing utility option — functional and lightweight, with a slightly more utilitarian interface.

The customizations actually worth making:

Strip edit_users and promote_users from any non-Administrator role. This is the single most important hardening edit. It stops a compromised or careless editor from minting a new Administrator account — a classic privilege-escalation path.
Build a "Configurator" role with content capabilities plus access to specific plugin settings, but without install_plugins. This solves the SEO/forms-manager problem cleanly.
Add upload_files to Contributor so your review gate survives contact with reality.
Create a "Reviewer" role that can read and comment on drafts (often via editorial-comment plugins) without edit_others_posts, giving you feedback without overwrite risk.

A structure that scales from 5 to 20 people

For a typical content team, this mapping holds up:

Owner / Ops (1–2): Administrator. Owns updates, security, backups, billing, and incident response. 2FA mandatory.
Managing Editor (1–3): Editor role, optionally extended to manage roles below Editor but never to create Administrators.
Writers (most of the team): Author for staff who publish their own work; a custom Contributor-plus-upload role for those whose work is always reviewed first.
Guests / freelancers: Contributor, ideally with their accounts set to expire or be deactivated when the engagement ends.

The layer capabilities can't enforce

Capabilities define what a role can do. They cannot define what a role should do, and trying to encode every "should" as a custom capability leads to a brittle tangle of micro-roles nobody remembers. The smarter move is to let a written team agreement carry the soft boundaries.

An Editor technically can delete a two-year-old cornerstone article. The agreement — one page in your onboarding wiki — says they check with the Managing Editor first. That isn't enforced by delete_others_posts; it's enforced by professional norms and the fact that the expectation is written down. This works because the overwhelming majority of access mishaps aren't malicious. They're someone unsure of the convention. Spell the convention out and you prevent most accidents without bloating your permission model.

The short version

Start from the defaults, move the install_plugins line as far away from your content people as possible, and reach for PublishPress Capabilities only when a real workflow gap appears. Lock down edit_users everywhere but Administrator, put 2FA on every admin, and write down the soft rules instead of trying to code them. Roles are a tool for matching access to behavior — not a bureaucracy to admire.

WordPress User Roles: Who Should Get What Access