WordPress User Roles: Who on Your Team Should Have Which Access

WordPress ships with six built-in user roles — Super Admin, Administrator, Editor, Author, Contributor, and Subscriber — and each one grants a different set of permissions. Most small businesses use exactly one of them. Everybody gets Administrator, because that is the role that was already selected when the owner clicked “Add New User,” and nobody wanted to be the person who gave a coworker too little access.

That default costs you two things. It means any one of five or six people can break the site by accident, and it means that if any one of those accounts gets taken over, the attacker arrives with the keys to everything. Neither risk is theoretical, and neither requires anybody to be careless.

Here is what each role actually does, and how to match the right one to each person on a small team.

The six WordPress user roles, in plain English

Roles are bundles of individual permissions, which WordPress calls capabilities. You rarely need to think at the capability level, but you do need to know where the lines fall.

Administrator — everything. Installs and deletes plugins and themes, runs core updates, changes every setting, edits and deletes anyone’s content, and creates, promotes, and deletes other users. On a single-site install this is the top of the ladder.
Editor — full control over content, no control over the site itself. An Editor can write, publish, edit, and delete anyone’s posts and pages, manage categories, moderate comments, and upload images. An Editor cannot install a plugin, switch a theme, change a setting, or touch a user account.
Author — their own posts only. Can write, publish, and delete their own posts and upload files, and cannot see or alter anyone else’s drafts. No access to pages.
Contributor — writes drafts, cannot publish them. The role has three capabilities in total: read, edit their own posts, and delete their own posts. Someone else has to hit Publish.
Subscriber — can log in, read, and edit their own profile. Nothing else. This is the right role for a membership or newsletter account.
Super Admin — only exists on a multisite network, where it governs the whole network of sites. If you run one website, you will never see it.

The gap between Administrator and Editor is the one that matters most. Everything that can take a site offline — a plugin update that conflicts with the theme, a permalink setting changed on a hunch, a deleted user whose posts go with them — lives on the Administrator side of that line. Everything a marketing person needs to do their job lives on the Editor side.

Who on your team gets what

For a business with fewer than about twenty people, this mapping covers nearly every case:

The owner — Administrator. Somebody internal has to be able to grant and revoke access, and it should be the person who signs the checks.
Marketing lead or office manager who updates the site weekly — Editor. This is the role almost everyone who has been handed Administrator should actually have.
Staff who write blog posts or news items — Author if you trust them to publish without review, Contributor if posts should be read first.
An outside writer, intern, or guest contributor — Contributor.
Your developer or maintenance provider — Administrator, on an account in their own name.
A customer, member, or donor with a login — Subscriber, or whatever custom role the membership plugin created for that purpose.

Two or three Administrators on a small-business site is reasonable. Seven is a sign nobody has looked at the user list in a few years.

The Contributor trap

There is one thing about Contributor worth knowing before you assign it: the role cannot upload files. Not a photo, not a PDF, not a logo. A Contributor can write a thousand words and will not be able to attach a single image to the draft.

That surprises people, and it is the usual reason a guest writer gets bumped to Author after one frustrating afternoon. If the person writing needs to place their own images, give them Author and review the posts before they go out, or have someone with Editor access add the images at publication. Decide which before you send the login, not after.

Why this matters more for organizations than for companies

Businesses hire and fire slowly. Volunteer organizations turn over on a schedule — boards rotate, committee chairs change, and the person who ran the newsletter last spring is now the treasurer.

When I built the custom WordPress site for the Truchas Chapter of Trout Unlimited in northern New Mexico, the site was designed around content that several different people add over time: chapter news, an events calendar, membership and volunteer signups. A structure like that only stays healthy if the access structure matches it. The people posting news need to be able to post news. They do not need to be able to install plugins — and when they hand the newsletter off to the next volunteer, the role should move with the job, not the person.

Should my web developer have an administrator account?

Yes — while they are working on the site, on an account in their own name, with their own email address. A developer genuinely needs plugin, theme, and update access to do the work, and shared logins make it impossible to tell from the activity log who changed what. What you should not do is let that account sit active for three years after the project ended. When an engagement finishes, either downgrade the account or delete it and reassign its content. Any reputable developer will expect you to, and will tell you so themselves.

What to do when someone leaves

Deleting a WordPress user is not like deleting a file. When you remove an account that has published content, WordPress asks whether to delete that content or attribute it to another user. Choose the second option, always. Otherwise you can lose a year of blog posts because an employee left.

The sequence that works:

Reassign their published content to an account that is staying.
Delete the account rather than just changing its password. A dormant account is still a login screen target.
Change any shared credentials that person had — hosting, domain registrar, analytics, the form plugin’s notification address.
Check Users → All Users for anything you do not recognize while you are in there.

A ten-minute audit you can run today

Read every Administrator name out loud. If you cannot say what that person does for you this month, they do not need the role.
Downgrade anyone who only ever edits content to Editor. Nothing they do day to day will change.
Look for generic usernames — “admin,” “editor,” the company name. Those are the first ones guessed in a login attack. Create a named replacement and remove the generic one.
Turn on two-factor authentication for every Administrator. This is the single highest-value change on the list.

Put a recurring reminder on the calendar for twice a year. The list grows on its own; it only shrinks on purpose.

Where custom roles come in

Sometimes the six built-in roles genuinely do not fit. A staff member needs to edit the events calendar and nothing else. A department head should manage their own section of the site and no other. That is what custom roles are for, and on a custom build they can be defined exactly — a role whose entire scope is one custom post type, with no access to anything around it.

That is worth doing when the need is real and permanent, and not worth doing to avoid a conversation about who should be an Administrator. Start with the built-in roles, run the audit, and add a custom role only when you can name the specific thing they cannot express.

Patrick Iverson is a brand strategist and custom WordPress developer in Santa Fe, New Mexico, running an independent practice here since 2001. If you are not sure who has access to your site or what they can do with it, that is an easy thing to look at together — send a note and we will go through the user list.