WordPress User Roles Permissions Setup: Safe Access for Client Teams

A proper WordPress user roles permissions setup is the difference between a site your whole team can work on safely and a site where one well-meaning click takes the homepage down. Most business sites do not have a permissions problem because someone was careless. They have one because everyone was given an Administrator account on day one, when the site was small and the team was two people, and nobody ever went back to fix it. This guide walks through how to set up roles and permissions for a client team properly: what each default role can do, how to apply least privilege without slowing real work down, the mistakes that cause the expensive accidents, and the audit habit that keeps the whole thing honest.

This guide is written for business owners, marketing leads, and whoever ended up as the site’s unofficial administrator. You do not need to write code: you need a clear model of who can do what, and a setup you can check in about ten minutes.

What WordPress user roles permissions setup actually controls

WordPress controls access through two ideas that work together. A role is a named bundle of permissions, such as Editor or Author. A capability is a single permission inside that bundle, such as publish_posts, edit_others_posts, install_plugins, or edit_theme_options. Assigning a role hands over its whole bundle of capabilities.

That distinction matters because most permissions problems are bundle problems, not people problems. A marketing manager given Administrator does not just gain the ability to publish pages. They also gain the ability to install plugins, change themes, edit user accounts, and delete content they did not create. Nothing about their job needs those powers, but the role hands them over anyway. A good setup matches the bundle to the job, and nothing more.

There is one more thing worth knowing before you touch any settings. WordPress checks capabilities, not job titles. If a plugin adds a capability, or a custom role is built badly, tidy labels in the Users screen can hide permissions far wider than you expect. Check what roles can actually do, not just what they are called.

The five default roles, explained like a practitioner

WordPress ships with five roles on a standard single site, plus Super Admin on multisite networks. Here is what each one means in practice.

• Administrator. Full control: settings, themes, plugins, users, and all content. There should be very few of these, ideally two or three named people, including someone technical who can recover the site if something breaks.
• Editor. Full control over content: publish, edit, and delete any post or page, moderate comments, and manage categories. Editors cannot install plugins, change themes, or touch site settings. For most content teams, Editor is the highest role anyone needs.
• Author. Can write, upload media, publish, and delete their own posts, but cannot touch anyone else’s content. This fits regular contributors who own a beat, such as a staff writer or department lead.
• Contributor. Can write and edit their own posts, but cannot publish them. A Contributor’s work waits for review. This is the right role for guest writers, junior staff, and anyone whose work should pass an editor before it goes live.
• Subscriber. Can manage only their own profile and read content. On a business site, this is usually the right default for registered customers, members, or anyone who just needs an account.

The gap between Editor and Administrator is the most important one here. Editor covers almost every legitimate content job. Administrator adds site-breaking powers: installing code, changing who can log in, and altering settings that affect every page. If a job does not include installing software or managing users, it does not need Administrator, however senior the person is.

The least-privilege setup we use for client teams

Least privilege is a simple rule: give each person the smallest set of permissions that lets them do their job well, and no more. Done properly, it speeds teams up, because people stop worrying about breaking something. Here is the setup we recommend as a starting point.

1. Two Administrators, named and known. One is the site owner or technical lead; the other is the agency or developer maintaining the site. Both use strong passwords and two-factor authentication. Nobody shares an Administrator login.
2. Editors run content. The marketing lead and senior content staff get Editor. They can publish, correct, and remove anything, which is what content leadership requires.
3. Authors own their beats. Regular writers get Author. They can publish their own work without waiting, but cannot rewrite a colleague’s page by accident.
4. Contributors for everyone unproven. New writers, freelancers, and guest posters start as Contributors. Promotion to Author is a deliberate decision after a few clean pieces, not an automatic one.
5. Subscribers for accounts that just need to exist. Customers and members get Subscriber unless there is a specific reason to give more.
6. Separate accounts for separate jobs. One person should not share a login with colleagues: when five people share one login, you cannot tell who changed what, and you cannot revoke one person’s access without locking out the other four.

From our experience, the step teams resist most is cutting the number of Administrators. The resistance fades fast once people realise how little changes day to day: Editors can still publish instantly and Authors can still write. The only people who notice are the ones who used to install plugins on a whim, and that is exactly the behaviour the setup is meant to stop. A plugin installed without review is untested code running on your business site; it deserves a deliberate decision, not a casual click.

The mistakes that break sites

Most permissions damage we have repaired traces back to a handful of repeated mistakes, each easy to make and easy to prevent.

• Everyone is an Administrator. This usually starts during a launch, when speed matters more than process, and then nobody revisits it. The fix takes ten minutes in the Users screen, and it is the single highest-value permissions change most sites can make.
• Ex-staff keep access. Freelancers finish a project, employees move on, and their accounts stay live for months. Every dormant Administrator account is an unlocked door. Removing access should be part of the offboarding checklist, the same day.
• One shared login for the whole team. Shared logins destroy accountability: when a page is deleted, the log shows the shared account, not the person. They also make password rotation painful, because changing the password locks out everyone at once.
• Editors given plugin powers through a badly built custom role. We have seen custom “Senior Editor” roles that quietly included install_plugins, turning a content role into a site-control role. Always review the capability list, not just the role name.
• No two-factor authentication on Administrator accounts. Passwords leak. Two-factor authentication on every Administrator account is the cheapest serious security upgrade a WordPress site can make.

When the default roles do not fit: custom roles done carefully

Sooner or later, a growing team hits a case the defaults do not cover: a shop manager needs orders and products but not blog posts, or a client wants to approve content without publishing it directly. Custom roles are the right answer, provided they are built deliberately. Start from the closest default role and change as little as possible: start from Editor and remove publish rights for an approver, or from Shop Manager for order access without content powers. Document what the role is for and who holds it; if nobody can explain why it exists six months later, retire it.

Be careful with plugins that promise one-click role editing. They are legitimate tools, and we use them, but they make it easy to grant a dangerous capability by accident, because capabilities are listed by technical names. After creating or changing a role, log in as a test user with that role and try what it should not allow: the plugin installer, the theme editor, another user’s profile. If any open, the role is wrong, whatever its name says.

Auditing access: the quarterly habit that prevents most incidents

A permissions setup is not a one-time project: teams change, contractors come and go, and roles drift. The habit that keeps a setup honest is a short access audit, once a quarter, taking well under an hour on most business sites.

1. Open Users and sort by role. Read every Administrator account and ask whether each person still needs that level of access.
2. Remove or demote accounts for people who have left, projects that have ended, and agencies no longer engaged. When in doubt, demote rather than delete, so content stays attributed correctly.
3. Check for shared accounts and split them into named accounts, even if that takes a few extra minutes.
4. Confirm two-factor authentication is active on every Administrator account.
5. Review custom roles: does each one still have a reason to exist, and does its capability list still match that reason?
6. Note the date and who performed the audit. The record itself is part of the control.

From our experience, the audit usually finds something: most often a former freelancer still holding Editor access, or a manager made Administrator for a one-off task two years ago and never demoted. Neither is a scandal. Both are exactly what the audit exists to catch before they matter. Pair the audit with a backup you have actually restored from at least once, and with the broader WordPress plugin development discipline of reviewing what runs on your site, and you have covered the two failure modes behind most small-business site emergencies: someone with too much access, and code nobody reviewed.

For the technical background on exactly which capabilities each role holds, the official WordPress Roles and Capabilities documentation is the reference worth bookmarking.

Frequently asked questions

How many WordPress Administrators should a business site have?

Two or three named people is the right range for most business sites: the owner or technical lead, plus the developer or agency maintaining the site.

What is the difference between Editor and Administrator in WordPress?

Editors have full control over content: they can publish, edit, and delete any post or page. Administrators add site-level powers on top: installing plugins and themes, changing settings, and managing users. If a job is about content, Editor is almost always enough.

Should clients get Administrator access to their own site?

Clients own their site, so the question is about risk, not rights. The practical answer is that one named client contact can hold Administrator, with two-factor authentication, while the rest of the team works as Editors and Authors. That keeps ownership real without giving every team member site-breaking powers.

How do I remove access when a freelancer or employee leaves?

Demote the account to Subscriber, or delete it and reassign its content to another user, on the person’s last day. Also reset shared passwords they knew and check for application passwords they may have created. Make this a step in your offboarding checklist so it never depends on someone remembering.

Can I create a custom role for someone who should only edit one section?

WordPress core roles are site-wide, not section-specific, so true per-section editing needs a plugin or custom code. Before adding that complexity, check whether an Editor with a clear editorial agreement, or a Contributor whose work is reviewed, already solves the problem.

A good WordPress user roles permissions setup is boring, and that is the point. Nobody notices it when it works: content flows, nobody breaks anything by accident, and when someone leaves, one change closes the door. Set roles to match real jobs, keep Administrators few and protected, and audit once a quarter. If your team has grown past the setup you launched with, or you suspect old accounts are still live, talk to us and we will review the roles, plugins, and access list with you before anything goes wrong. You can also see how we approach site builds on our web development services page.