WordPress User Roles and Capabilities

On most WordPress sites with more than one user, everyone is an administrator. The writer who joined for one guest post: admin. The intern who left eight months ago: admin. The SEO consultant whose contract ended last spring: admin, and their password is probably Summer2024! because it was set in a hurry.

This is not because people are careless. It is because WordPress permissions look simple on the surface (a dropdown with five options) while the real system underneath (capabilities) is invisible unless you go looking for it. So people pick the role that definitely will not cause a support ticket, which is Administrator, and move on.

The fix takes about an hour, and it starts with understanding what the roles actually mean.

Roles are just bundles of capabilities

WordPress does not check your role when you try to do something. It checks whether you have a specific capability — a named permission like edit_posts, publish_pages, or manage_options. A role is nothing more than a labeled bag of capabilities. Administrator is a bag with roughly 60 of them; Subscriber is a bag with one (read).

This matters for two practical reasons:

You can modify the bags. If Editors on your site need to manage a specific plugin, you can grant that one capability to the Editor role instead of promoting people to Administrator.
Plugins add their own capabilities and sometimes their own roles. WooCommerce ships a Shop Manager role with capabilities like manage_woocommerce. If you only think in terms of the five defaults, you will miss half of what is actually configured on your site.

A few capabilities do the heavy lifting, and knowing them by name makes every permissions decision easier:

edit_posts — create and edit your own posts (drafts included)
publish_posts — make your own posts live without review
edit_others_posts — edit content written by anyone; this is the line between a writer and an editor
edit_pages / edit_others_pages — the same, but for pages, which usually means the site's core marketing content
upload_files — add media
moderate_comments — approve, spam, and trash comments
edit_theme_options — change menus, widgets, and Site Editor settings
install_plugins, activate_plugins, update_plugins — the keys to the codebase
manage_options — change site settings; this is the capability most plugins check before showing their settings screens, which makes it close to full control
unfiltered_html — post raw HTML including scripts; more on this one below, because it deserves its own warning label

The six built-in roles, translated into job descriptions

Here is what each default role amounts to in practice, phrased the way you would phrase it to a human being rather than a database:

Role	What they can actually do	Give it to
Subscriber	Log in, manage their own profile, read private-ish things if you build that	Members, customers, commenters who need accounts
Contributor	Write and edit their own drafts. Cannot publish, cannot upload images	Guest writers, new freelancers you have not worked with yet
Author	Write, upload media, and publish their own posts. Cannot touch anyone else's content	Regular writers you trust to publish without review
Editor	Everything content: all posts, all pages, everyone's drafts, comments, categories. No plugins, no themes, no settings	Content leads, marketing managers, anyone who owns the words
Administrator	Everything, including installing code, changing themes, and deleting other users	One or two people who are accountable for the whole site
Super Admin	Multisite only: everything, across every site in the network	Almost nobody

Two of these are chronically misused. Contributor's inability to upload images makes it nearly useless for real writing workflows — a guest author who cannot add a featured image will email you the files, which defeats the purpose. In practice most teams skip straight to Author and handle review through an editorial plugin or a simple agreement about drafts. And Administrator gets handed out for tasks that Editor covers completely, because nobody remembers that Editor can already edit every page on the site.

Decision rules for the people actually on your team

Rather than reasoning from the role names, reason from the request. Some worked examples:

The freelance writer

Author. They publish their own work, they cannot break anyone else's. If you want to review everything before it goes live, keep them at Author anyway and use a plugin like PublishPress to add an editorial approval step, rather than downgrading them to Contributor and dealing with the image problem.

The marketing manager

Editor. This is the role's entire reason for existing. The common objection is that they also need to edit the homepage banner or the menu — and if the homepage is a page built with the block editor, Editor already covers it. If it lives in the Customizer or Site Editor settings, grant the Editor role the single capability edit_theme_options instead of promoting anyone (see custom capabilities below).

The SEO consultant

Editor, plus whatever capability their SEO plugin defines. Yoast, for example, registers capabilities like wpseo_manage_options that can be granted separately. What the consultant does not need is install_plugins. If they ask for admin access to install a tool, the correct flow is that they ask, you install it, and they configure it with a scoped capability.

The agency or developer

Administrator — but temporary. Create the account when the engagement starts, note it somewhere you will actually look at again, and deactivate it when the project ships. A reasonable standing rule: any Administrator account with no logins for 90 days gets demoted to Subscriber, not deleted, so content attribution survives.

The client (if you are the agency)

This is the fun inversion. Clients usually want admin on their own site, which is fair — they own it. But if you have a maintenance contract, an admin client who installs a page builder on Friday evening is your weekend problem. The honest arrangement is Administrator for the client plus a written agreement about what triggers billable cleanup, or Editor plus a fast turnaround promise for anything code-shaped. Pick one deliberately instead of defaulting.

When the built-in roles are not enough

Sooner or later a request arrives that does not fit: the store assistant who should manage WooCommerce orders but not edit blog posts, or the HR person who should update the careers page and nothing else. You have three options, in ascending order of effort.

Option 1: grant a capability to an existing role

One line of WP-CLI:

wp cap add editor edit_theme_options

Now every Editor can manage menus and widgets. This persists in the database (roles are stored in the wp_options table under wp_user_roles), so it survives theme changes and updates. To reverse it: wp cap remove editor edit_theme_options.

Option 2: create a custom role

When a set of people needs a distinct bundle, make the bundle explicit:

wp role create content_manager 'Content Manager' --clone=editor

wp cap add content_manager edit_theme_options

Cloning from an existing role and adjusting is far less error-prone than building from scratch, because forgetting a mundane capability like read produces confusing breakage.

Option 3: use a role editor plugin

If the command line is not your habitat, the Members plugin or User Role Editor give you the same power with checkboxes. They are well-maintained and fine to run in production. The one warning: these plugins make it very easy to edit the built-in roles into unrecognizable shapes. Prefer creating new roles over mutating Editor into something no future developer will expect.

A rule of thumb for choosing: if the exception applies to one or two people, grant capabilities to their user directly or bump the existing role. If it applies to a category of people that will outlive any individual (shop staff, regional editors), create a named role. Future-you reads content_manager and understands; future-you reads an Editor role with fourteen bolted-on capabilities and starts a spreadsheet.

The sharp edges nobody mentions until they cut you

unfiltered_html

On a single site, Administrators and Editors have unfiltered_html, which means anything they paste into a post — including a <script> tag — is saved and served verbatim. This is why an Editor account is a real security asset, not just a content one: a compromised Editor can inject JavaScript into every page. Treat Editor credentials with nearly the same seriousness as Administrator ones, and require strong passwords and two-factor authentication for both. (On multisite, only Super Admins get this capability, which is one of multisite's quiet security wins.)

Plugins that check the wrong thing

Plenty of plugins gate their settings behind manage_options when they should define their own capability. The symptom: you want to let an Editor configure the forms plugin, but the only way is full admin. Before promoting anyone, check the plugin's documentation for a capability filter — many popular plugins (Gravity Forms, Yoast, WooCommerce) define granular capabilities precisely for this case.

Role sprawl from deactivated plugins

Roles live in the database, not in plugin code. Deactivate WooCommerce and the Shop Manager role remains, orphaned. Run wp role list occasionally and remove roles whose parent plugin is long gone: wp role delete shop_manager (after moving any users off it).

Admin over email trust

Administrators can change other users' email addresses and passwords. Every admin account is therefore also a takeover path for every other account. This is the concrete reason the answer to how many admins should we have is as few as survivable — usually two, so a lost phone does not lock you out of your own site.

The one-hour audit

If you have inherited the usual everyone-is-admin situation, here is the cleanup, in order:

List the admins. wp user list --role=administrator --fields=user_login,user_email,user_registered — or the Users screen filtered by role. Expect surprises.
Demote by default. For each admin, ask what they actually did in the last quarter. Content work means Editor. Writing means Author. Nothing means Subscriber. Only unambiguous site-ownership keeps Administrator.
Deal with departures. For people who left: wp user update 47 --role=subscriber plus a password reset, or reassign their content and delete the account with wp user delete 47 --reassign=3. Demotion preserves bylines; choose based on whether their authorship matters publicly.
Check the nonhuman accounts. Service accounts for backup tools, form integrations, and site managers often sit at Administrator. Verify each one still corresponds to a live integration, and use application passwords (built into WordPress since 5.6) rather than the account's real password for API access.
Write the mapping down. One paragraph in your internal docs: which role each kind of teammate gets, and who approves Administrator. This is the part everyone skips and the reason the audit has to be repeated annually instead of never.

What this buys you

Least-privilege on a WordPress site is not really about defending against your own team. It is about limiting the blast radius of ordinary accidents: the phished password, the laptop left on a train, the well-meaning click on Update All at 5 p.m. Friday. An attacker with an Author account can post spam; an attacker with an Administrator account owns the server's webroot and everything in it.

The roles system that ships with WordPress is genuinely good — better than most CMSes — but only if you use more than one row of it. Spend the hour. Demote generously. And when someone asks for admin access to change a headline, you will finally have a better answer than sure, fine.

Photo: himanshu marathe on Pexels