WordPress User Roles: What Each One Can Do and Who Gets What

Every account on your site carries a label that says what it is allowed to do. That label is the role, and getting WordPress user roles right is one of the cheapest security wins there is. A stolen Subscriber password is an annoyance. A stolen Administrator password is the whole site.

This article covers what each default role can do, who should get which one, how roles differ for shops and agencies, how to build a custom role, and how to clean up the accounts you no longer need.

The Default WordPress User Roles

A role is a named bundle of capabilities. A capability is a single permission, such as "publish posts" or "install plugins". The WordPress roles and capabilities handbook puts it simply: a role defines what a user can see and do in the dashboard, and the capabilities are the individual things inside it.

A normal site has five roles. A multisite network (several sites sharing one WordPress install) adds a sixth.

• Administrator: access to all the administration features of a single site.
• Editor: publishes and manages posts, including other people's.
• Author: publishes and manages their own posts.
• Contributor: writes and manages their own posts but cannot publish them.
• Subscriber: can only manage their own profile.
• Super Admin: multisite only, with access to the network administration features as well as everything else.

Those one-line descriptions come from the official roles and capabilities documentation. The gap between them is wider than the names suggest, so here is a table of what each role can actually do on a single site.

Two small notes on that table. The code editing row can be turned off for everyone, which we come back to later. And a "No" for Editor on settings does not mean Editors are harmless: an Editor can publish whatever they like, so a hijacked Editor account can still put spam or a fake page in front of your visitors.

Key takeaway: The big jump in power is between Editor and Administrator. Everything below Administrator can change content. Only an Administrator can change the site itself.

Why WordPress User Roles Matter for Security

Think of WordPress user roles as the keys on a caretaker's ring. A cleaner needs the front door and the supply cupboard, not the safe. Handing everyone the master key is faster on day one and expensive on the day one of those keys goes missing.

Accounts get compromised in ordinary ways: a reused password leaks from another service, a laptop is stolen, a guessed password falls to a bot. When that happens, the damage depends on the role. A hijacked Author can publish junk under their own name. A hijacked Administrator can install a plugin that contains a backdoor, create more administrators and lock you out.

That is the idea behind least privilege: give each person the lowest role that still lets them do their job, and nothing more.

Least Privilege in Practice: Who Gets Which Role

Here is how it plays out for the people who usually end up on a WordPress site.

Writers and Bloggers

Someone who writes articles needs Contributor if you want to review everything before it goes live, or Author if you trust them to publish. Neither role can touch plugins, themes or other users. A writer who asks for Administrator "just to upload an image" almost never needs it. Authors can upload media; Contributors cannot by default, so if a writer needs to add their own images, Author is the answer, not Administrator.

Editors and Content Managers

A person who reviews and publishes other people's work needs Editor. That is also the right ceiling for most marketing staff. If they need to see form entries or manage a single plugin's screen, many plugins have their own permission setting, so use that instead of promoting them.

Freelancers and Contractors

This is where accounts pile up. A designer needs access for two weeks, then the account stays for two years. Give contractors the lowest role that does the job, write down when the work ends, and remove the account on that date. Our WordPress website handover checklist covers this from both sides. If a developer needs Administrator to do a task, treat it as a loan: create the account for the project, then delete it when you sign off.

Shop Staff

For an online shop, the person who packs orders does not need to install plugins. WooCommerce adds its own roles for exactly this reason, which the next section covers.

Agencies and Care Plan Providers

If you look after client sites, you probably need Administrator, and so does everyone on your team. That makes your own accounts the juicy ones. Use a named account per person (never a shared "agency" login, and see how to manage multiple WordPress sites without one), turn on two-factor sign-in for all of them, and remove people the day they leave. Handing out WordPress user roles across many client sites is part of the job. Our article on WordPress care plans covers how agencies organise this work, and the agency security guide goes deeper on access.

Pro tip: Count your Administrators. For a small business site, one or two named people is normal. Five, with two of them nobody remembers adding, is a finding.

WooCommerce Roles: Shop Manager and Customer

WooCommerce adds two roles on top of the defaults.

• Customer is created for people who check out. It is similar to Subscriber in that it has no access to the admin beyond their own account.
• Shop Manager is meant for staff who run the store day to day. It can manage orders, products and customers without being a full Administrator.

The point of Shop Manager is that your fulfilment person can handle orders without being able to install plugins, edit themes or add users. Use it, and work through the rest of our WooCommerce security checklist while you are at it. A shop with five Administrators "because it was easier" has five ways for an attacker to take the checkout over.

Customer accounts matter too, because shops can end up with thousands of them. They are low-privilege, but they are still logins that attackers can try passwords against. Our WooCommerce integration page explains how Stack Guard works alongside a shop.

Custom Roles and Capabilities

Sometimes the five roles do not fit. You want a role that can publish and also manage a particular plugin's settings, or a read-only role for an auditor.

WordPress lets you create your own. According to the developer handbook, add_role() takes a role name, a display name and an array of capabilities, and it runs once: the role is stored in the database, so later calls with a different list do nothing. To change an existing role, use add_cap() and remove_cap() on the role object.

// Run once, for example on plugin activation.
add_role(
    'site_auditor',
    'Site Auditor',
    array(
        'read'       => true,
        'list_users' => true,
    )
);

There are two things to know before you start.

1. Start from nothing, then add. A role built from a short list is easier to reason about than a copy of Editor with things taken away.
2. Custom capabilities only do something where they are checked. A made-up capability has no effect in the default admin. It only matters in code that calls current_user_can() for it.

If you would rather not write PHP, a role editor plugin gives you the same thing with checkboxes. Whichever way you go, keep your custom roles few and documented. A role nobody can explain is its own risk. Also leave the Administrator role alone: the handbook warns against removing it, and an edited Administrator is how people lock themselves out.

Audit Your WordPress User Roles

WordPress user roles drift. Staff move on, agencies change, plugins add their own roles. Once a quarter, spend ten minutes on this.

1. Go to Users and filter by Administrator. Check that every name belongs to a person you can identify.
2. Filter by Editor and do the same.
3. Look for accounts with generic names such as admin, support or webmaster. If your own account is called admin, here is how to change your WordPress admin username.
4. Check the email address on each account. An old agency address that nobody reads is an account anyone could recover with a password reset.
5. Look at the registration date on anything unfamiliar. A new Administrator you did not create is one of the signs of a hack, covered in signs your WordPress site has been hacked.
6. Check the default role for new registrations under Settings, General. It should be Subscriber, or Customer on a shop, unless you have a good reason.

The full routine fits into a bigger check-up, which we walk through in the WordPress security audit article.

Removing Old Accounts Safely

When someone leaves, deleting the account is the cleanest fix, but it needs one decision first. When you delete a user in WordPress, it asks what to do with their content. You can delete all content, or attribute all content to another user. Pick the second unless you really want the posts gone.

For accounts you are not sure about, lower the role to Subscriber first and watch for a week. If nobody complains, delete it. A lower role is reversible. A deleted account is not.

Remember that a password change does not end a session that is already open. If a laptop has been lost or a person left on bad terms, also sign them out. WordPress can do that from the user's profile screen with Log Out Everywhere, which is useful when you need an account to stop working right now.

What Stack Guard Adds

WordPress roles control what people can do in WordPress. Stack Guard adds a few controls around them.

• Choose which roles and users can open Stack Guard (Free). Each role gets Full Access, View Only or Hidden, so a client or an editor can see the security status without changing a setting. A per-person override is part of Pro. The access control documentation has the details. Note these levels only control Stack Guard itself. A Hidden Administrator can still manage plugins and users in WordPress.
• User Security Console (Pro). One screen lists your users with their role, password age, two-factor status, last sign-in and active sessions, with filters for Admins, No 2FA and Dormant. You can end a session or sign someone out everywhere. A dormant administrator is one who has not signed in for 90 days, which is how the old agency account gets noticed. See user security.
• Require two-factor by role (Pro), and for admins (Free). Stack Guard Free can require two-factor for administrators. Pro lets you require it by role or for named users, so editors and shop managers are covered too. The two-factor feature page explains the options, and our guide to two-factor authentication shows how to roll it out to a team.

The reason to pair roles with two-factor is simple. Least privilege limits what a stolen account can do. Two-factor makes the account harder to steal in the first place.

A Role Checklist You Can Use Today

1. Count your Administrators and justify each one.
2. Give every person a named account, never a shared one.
3. Use Contributor, Author, Editor or Shop Manager wherever Administrator is not strictly needed.
4. Set an end date on contractor accounts when you create them.
5. Turn on two-factor for every account that can publish or manage the site.
6. Review the Users screen every quarter and remove what you do not recognise.

Do those six things and your WordPress user roles will be tidier than most sites that have been running for years.