Most WordPress sites hand out administrator accounts like guest wifi passwords. The freelancer who redesigned your homepage two years ago, the intern who wrote three blog posts, the agency you stopped paying in 2024 — a lot of them are still sitting in your user list with full control of the site. Nobody meant for it to happen. It’s just easier to click “Administrator” than to think about what a person actually needs to do.
That convenience is also how sites get wrecked. A single over-privileged account is all a phished password or a careless contractor needs to install a malicious plugin, change the admin email, or lock everyone else out. WordPress ships with a genuinely good permission system for exactly this problem, and hardly anyone uses more than one setting of it.
This is a practical guide to WordPress user roles and capabilities: what the built-in roles can actually do, when to reach for each one, and how to check and tighten who has access — from the dashboard and from the command line.
What Roles and Capabilities Actually Are
A capability is a single specific permission — edit_posts, publish_posts, install_plugins, manage_options, edit_users. WordPress has dozens of them, and every action in the dashboard is gated behind one. A role is just a named bundle of capabilities. When you make someone an Editor, you’re really handing them the set of caps that WordPress bundled under that label.
This matters because permissions in WordPress are additive and checked one capability at a time. The code that decides whether to show the “Plugins” menu isn’t asking “is this person an admin?” — it’s asking current_user_can('install_plugins'). Roles are a convenience layer on top of capabilities, which is why you can grant or revoke a single cap on a role without inventing a whole new one.
The principle of least privilege — give each account only the access it needs to do its job — is one of the cheapest security wins available. It costs nothing, needs no plugin, and shrinks the blast radius of every compromised password. The last WordPress cleanup we did started with a brute-forced administrator login; had that account been an Author, the attacker never gets near the plugin editor.
The Five Built-In Roles, From Most to Least Powerful
A standard single-site WordPress install ships with five roles. (A sixth, Super Admin, exists only on Multisite networks — more on that below.) Here’s what each one can and can’t do.
Administrator
Full control of a single site. An Administrator can do everything: publish and delete any content, install and edit plugins and themes, change every setting, and — the part people forget — create, edit, and delete other users, including other admins. On a normal site this role should belong to as few people as possible, ideally just you. Every extra admin is another key to the whole building.
Editor
An Editor owns the content side of the site without touching its plumbing. They can publish, edit, and delete anyone’s posts and pages, moderate comments, and manage categories and tags. What they can’t do is install plugins, switch themes, or edit users. For a client who runs their own blog, or a content lead managing a team of writers, Editor is almost always the right answer instead of Administrator.
Author
Authors are self-sufficient publishers of their own work. They can write, edit, publish, and delete their own posts, and upload media, but they can’t touch anyone else’s content and have no access to pages, plugins, or settings. It’s a good fit for a regular contributor you trust to hit publish without review.
Contributor
A Contributor can write and edit their own posts but cannot publish them — drafts go into a queue for an Editor or Admin to review and push live. Worth knowing: contributors also can’t upload files, so they can’t add images to their own drafts without help. That trips people up, but it’s by design. This role suits guest writers and anyone whose work you want a second set of eyes on before it goes out.
Subscriber
The lightest role. A Subscriber can log in, read content, and manage their own profile, and that’s it. It’s what you’d assign to registered members on a site with gated content or comments that require an account. If someone doesn’t need to create or change anything, this is where they belong.
Administrator — everything, including plugins, themes, settings, and users.
Editor — publish and manage anyone’s posts and pages; no plugins or settings.
Author — publish and manage only their own posts; can upload media.
Contributor — write their own drafts but can’t publish or upload files.
Subscriber — read content and edit their own profile; nothing more.
Choosing the Right Role: Least Privilege in Practice
The question to ask for every account isn’t “do I trust this person?” It’s “what does this person actually need to click?” Trust and access are different things — you can completely trust a writer and still have no reason to give them the power to delete the site.
Match the role to the task
A client who posts their own updates needs Editor, not Administrator. A monthly guest columnist needs Contributor or Author. A developer building a feature needs Administrator, but only while the work is happening. The membership plugin’s customers need Subscriber. Start from the smallest role that lets the person finish their job and only move up when they hit a wall.
Give elevated access an expiry date
Contractors and agencies are the usual source of privilege sprawl. When you bring one in, note the date, and when the engagement ends, demote or delete the account the same week. An admin login that outlives the relationship it was created for is pure downside — nobody’s watching it, and it still opens every door.
Never let people share a login
Shared accounts destroy accountability and make cleanup impossible. If three people use one “admin” account, you can’t tell who published what, you can’t revoke one person’s access without locking out the others, and you can’t rotate the password without a group text. One human, one account, every time.
Auditing and Fixing Access
You can manage all of this from Users → All Users in the dashboard, where WordPress groups accounts by role and lets you bulk-change roles from the dropdown. That’s fine for a five-person site. On anything bigger, or when you want a fast honest picture of who has the keys, the command line is quicker.
See who has what with WP-CLI
If you have WP-CLI available, listing every account and role takes one command:
wp user list --fields=ID,user_login,user_email,rolesTo see the roles registered on your site, and the raw capabilities inside any one of them:
wp role list
wp cap list editorReassigning a user is a single call — this drops an over-privileged account down to Editor:
wp user set-role someuser editorWhen you remove a user entirely, WP-CLI makes you decide what happens to their content. Use --reassign to hand their posts to another account instead of deleting them along with the user:
wp user delete olduser --reassign=1Watch for phantom admins
Two things worth checking on any site you inherit. First, look for accounts whose role doesn’t match their job — a “subscriber” plugin login that somehow has manage_options is a red flag and sometimes a sign of a past compromise. Second, malware frequently creates a hidden administrator to keep a foothold, so if the user count in the dashboard doesn’t match what you expect, dig in. A quick wp user list --role=administrator shows every admin on the site in one screen.
Custom Roles and Capabilities
The five defaults cover most needs, but sometimes you want a role that doesn’t exist — a “Shop Manager” who handles orders but not blog posts, or an “SEO” account that can edit content and settings but can’t install plugins. WordPress lets you build these in code.
The add_role() function creates a new role from a map of capabilities, and remove_role() deletes one. You can also tune an existing role by grabbing it with get_role() and calling add_cap() or remove_cap(). A common tightening move is to strip unfiltered_html or edit_theme_options from a role that shouldn’t have it.
One catch that costs people an afternoon: add_role() writes the role into your database once, so calling it on every page load does nothing after the first run. Register roles on plugin or theme activation, not on a hook that fires each request, and if you change a role’s capabilities in code, you may need to re-save it for the change to stick. If you’d rather not write PHP, a role-editor plugin gives you a UI for the same operations, though hand-built capability maps stay easier to audit.
Tightening user access is one layer of hardening a site. amplifi builds a free, MIT-licensed suite of WordPress plugins — security, schema, meta, consent, and more — all AI-powered and open on GitHub. Good permission hygiene plus a hardened install goes a long way.
View on GitHubThe Super Admin Role on Multisite
If you run a WordPress Multisite network, there’s a sixth role that doesn’t exist on a standalone install: Super Admin. A Super Admin has network-wide control — they manage every site in the network, install plugins and themes network-wide, and hold capabilities like manage_network and manage_sites. On Multisite, individual site Administrators are deliberately restricted: by default they can’t install new plugins or themes, because that power belongs to the network level. If you’re not running Multisite, you’ll never see this role, and that’s fine — the five standard roles are the whole story for the vast majority of WordPress sites.
Frequently Asked Questions
Spend ten minutes in your user list this week. Demote what doesn’t need admin, delete what’s gone stale, and give every new account the smallest role that gets the job done — your future self will thank you the next time a password leaks.
Built by amplifi.studio — see also One Login Away From Disaster: A WordPress Security Hardening Guide.