WordPress user roles and user management

Short answer: WordPress has five default roles – Subscriber, Contributor, Author, Editor, and Administrator – each with a different set of permissions. Add users from Users > Add New in the admin, and assign the lowest role that lets the person do their job. Administrator is the most dangerous role to hand out, so give it only to people who truly need it.

That short answer is the 90% version. The rest of this guide covers what each role can actually do, how to pick the right one for clients and guest writers, how to add and remove users properly, why you cannot change a username through the UI (and the two real ways to do it), how author archive pages work, Gravatar profile pictures, and the security rules that keep a WordPress user list from becoming a liability.

The five default WordPress roles#

Every standard WordPress install (single-site, not Multisite) ships with these five roles, ordered from least to most powerful:

The jump that matters most is from Editor to Administrator. An Editor can publish anything, delete anything in the content area, and break your content – but they cannot install a malicious plugin, change the site URL, or lock you out. An Administrator can do all of that. This is why “give the client Administrator” is usually the wrong call.

Subscriber

Read-only access to anything public, plus the ability to manage their own profile (name, bio, password, email). Subscribers cannot write, comment on a protected post, or see the admin dashboard beyond their own profile screen. If you run a membership site, a paywalled blog, or a comment system that requires registration, Subscriber is the role new signups land in.

Contributor

Can write and edit their own posts, but cannot publish them (an Editor or Admin has to approve) and cannot upload images or files. This sounds restrictive and it is, but that is the point: a guest writer submits drafts, your team reviews, edits, and publishes. The no-upload restriction is often surprising – you can work around it by inserting images after the Editor publishes, or by using a plugin that grants upload rights to Contributors you trust.

Author

Can write, edit, publish, delete, and upload media for their own posts. Cannot touch anyone else’s content. Authors are the default “trusted writer” tier – they have a byline, they run their own corner of the site, and you do not have to approve every post.

Editor

Full control over the content area: posts, pages, categories, tags, comments, media. Editors can edit and delete any content from any user, moderate comments, and manage the site’s editorial structure. They cannot install plugins, manage users, or change site settings. This is the right role for an editorial manager or a client who handles content but should not be touching infrastructure.

Administrator

Total control. Installs plugins and themes, adds and removes users (including other Administrators), changes site settings, edits theme and plugin code through the admin if that is enabled, exports data, and can delete the entire site. An Administrator account is effectively the site – if one is compromised, the whole site is compromised.

On a WordPress Multisite network there is also a Super Admin role that sits above Administrator and can manage the whole network. We are skipping that here – WordPress Multisite hosting: what you need to know covers the Multisite-specific pieces.

Which role to assign#

A few rules that handle most situations:

• Clients: Editor. They can manage content without being able to break the site, install plugins, or lock out the developer. If the client insists on Administrator, that is a conversation about responsibility – if they have the key, they own what happens when something breaks.
• Guest writers: Contributor. Drafts in, you review, you publish. Upgrade to Author if the person writes for you regularly and you trust their work.
• In-house writers: Author. They publish their own work under their own byline.
• Editorial managers: Editor. They run the content operation across multiple writers.
• Developers and site owners: Administrator. As few as possible, ideally one primary account per real person.
• Subscribers and members: Subscriber. Default for registered users who are not part of the team.

The principle underneath all of this is least privilege: give each user exactly enough permission to do their job and nothing more. An Author with Administrator rights is a security problem even if they would never do anything wrong, because their password is one more place where a breach becomes a full compromise.

How to add a new user#

From the admin:

1. Go to Users > Add New.
2. Fill in Username (cannot be changed later through the UI – see the next section), Email (required, must be unique on the site), First Name and Last Name (optional but appear on the author archive and in bylines), Website (optional).
3. Leave Send the new user an email about their account checked. WordPress sends a password setup link; the user picks their own password rather than you setting one and emailing it.
4. Pick the Role.
5. Click Add New User.

If you do set a password manually, use something long and random (WordPress suggests one for you) and send it through a channel the user will not leave open, not email. Better: do not set one – let the welcome email handle it.

Removing a user without losing their content#

Deleting a user is more destructive than it looks. If you click Delete on a user who has published posts, WordPress asks whether to delete all their content or attribute all content to another user. Almost always, you want the second option.

1. Go to Users > All Users.
2. Hover over the user and click Delete.
3. On the confirmation screen, select Attribute all content to and pick a user (often a generic “Editorial” or “Admin” account).
4. Click Confirm Deletion.

The user is removed, but every post, page, and comment they wrote now shows the chosen user as author. The URL structure and post content are untouched. If you instead pick “Delete all content,” every post, page, attachment, and comment they created is gone – recoverable only from a backup.

For staff turnover, create a generic “Editorial” Author account before anyone leaves, reassign content to it, and delete the real user. That keeps the byline sensible without leaving old email addresses attached to live posts.

Changing a username (the three real answers)#

WordPress does not let you edit a username from the Users screen. Once created, it is fixed in the wp_users table. There are three ways around this, in order of recommendation:

1. Create a new user, reassign content, delete the old one

The cleanest fix. Create a new user with the username you actually want, reassign all posts from the old user to the new one (via the deletion flow above), then delete the old account. The display name, bio, and Gravatar stay consistent if you copy them across. The only thing that changes is the author archive URL (which follows the username or user_nicename).

This works for everyone and does not require a database edit or a plugin.

2. Use a plugin

Easy Username Updater and similar plugins add a “Change Username” button to the user profile screen. Install, activate, edit the user, type a new username, save. The plugin updates the wp_users.user_login field for you. This is fine for a one-off rename – deactivate and remove the plugin once you are done, because you do not need a username-changing plugin sitting on your site permanently.

3. Edit the database directly

Only do this if you are comfortable with MySQL and you have a backup.

UPDATE wp_users SET user_login = 'newusername' WHERE user_login = 'oldusername';

That is the only field that needs to change. user_nicename (which controls the author archive URL) can be updated separately if you want the URL to match:

UPDATE wp_users SET user_nicename = 'newusername' WHERE user_login = 'newusername';

Log the user out and have them log back in with the new username. Back up first – wp_users is not a table you want to mistype into.

Author archive pages#

Every user who publishes at least one post gets an author archive page at yoursite.com/author/username/ . It lists every post that user has written, usually with the same template as a category archive.

What most themes show:

• The author’s display name as the page heading
• The biographical info from the user’s profile (the Biographical Info field on Users > Your Profile)
• A list of the author’s posts

A few things to know:

• The URL uses user_nicename , not the display name. If the user is “Gabor Leszlauer” with username “gabor,” the archive is at /author/gabor/ . Change the nicename in the profile (or in the database) if you want a different URL.
• The slug prefix can be changed. By default it is /author/ . Some themes and plugins let you change it to /writer/ or similar, but this can break external links if you change it after the site has traffic.
• Users with no published posts do not get an archive. Or rather, they do, but the page is empty. This is occasionally useful for hiding service accounts.
• You can customize the layout. Most themes have an author.php template you can edit, or support Full Site Editing templates in block themes. Page builders (Elementor Pro, Divi, Bricks) all support author archive templates.

If you do not want author archives at all – for a single-author blog where the archive is redundant with the post list – you can disable them with a plugin (Yoast SEO has an option for this under Search Appearance) or by adding a redirect in the theme.

Gravatar profile pictures#

WordPress uses Gravatar for profile pictures by default. A Gravatar is an image tied to an email address – upload once, and it appears on every WordPress site (and many other platforms) that asks for that email’s avatar. There is no WordPress setting for uploading a custom avatar through the user profile.

How to set one up:

1. Go to gravatar.com and sign in with the email address the user has on the WordPress site.
2. Upload a photo.
3. Confirm the email.

The avatar appears everywhere within an hour or so. On the WordPress site it shows up on the user profile, in comments, on the author archive, and in any theme area that pulls the author avatar.

If you need custom avatars uploaded directly to the site (not through Gravatar), a plugin like Simple Local Avatars or WP User Avatar adds an upload field to the user profile and overrides the Gravatar lookup. This is the right approach if team photos are sensitive, if the site is behind a login and users do not want their avatars on a third-party service, or if you just do not want to rely on Gravatar.

User role plugins and custom capabilities#

The five default roles are rigid – you cannot grant an Author the ability to upload media to someone else’s post, or restrict an Editor from moderating comments, without code. For everything outside the defaults, there are plugins:

• User Role Editor. The most popular option. Lets you create new roles, clone existing ones, and toggle individual capabilities per role. Good for “I need an Editor who cannot delete published posts.”
• Members. Simpler interface, fewer features, but covers the common cases and is lightweight.
• PublishPress Capabilities. Focused on editorial workflows – restricting which categories a user can post to, which post statuses they can set, and similar.

A caution: custom capabilities live in the database. If you uninstall the plugin, the custom roles usually stay (broken) unless you remove them first. Use the plugin’s own “Reset roles” feature before deactivating, or you will end up with orphaned roles that only the plugin could manage.

For most sites, the five default roles are enough. Reach for a role plugin only when you hit a concrete limitation, not because the flexibility sounds nice.

Security rules for WordPress users#

User accounts are one of the main attack surfaces on a WordPress site. A few rules that prevent most problems:

• One Administrator per real person. Not one per role, not a shared “admin” account the whole team uses. Shared accounts make audit logs useless – you cannot tell who did what – and when someone leaves, you cannot rotate just their access.
• No “admin” username. The username admin is the first thing every brute-force bot tries. Use something unguessable, and if you inherited a site with admin , rename it using the “create new user, reassign content” method above.
• Strong passwords, always. WordPress suggests strong passwords by default – use them. Do not override the suggestion with something memorable. If someone complains, point them at a password manager.
• Two-factor authentication on all Administrator accounts, minimum. Wordfence, Two Factor, and WP 2FA all work. Editors should also have 2FA if they touch content that matters.
• Delete accounts for people who have left. Do not just demote them to Subscriber. Reassign their content and remove the account. A dormant Administrator account with a reused password is a standing invitation.
• Audit the user list every few months. Go to Users > All Users, sort by role, and look for anything that does not belong – accounts you do not recognize, Administrators who should have been demoted, Subscribers from a plugin that registered users automatically.
• Watch for bot-created accounts. If registration is open (Settings > General > “Anyone can register”), bots will create fake Subscriber accounts. Either disable open registration, add a CAPTCHA to the registration form, or accept that you will need to clean the list periodically. What happens when bots find your WordPress login page covers the broader pattern.

If you suspect an account has been compromised, the response is immediate: change the password, revoke any active sessions (from the user’s profile screen or with a plugin), check for new Administrator accounts you did not create, and review recent posts and plugin installs for anything unexpected. My WordPress site was hacked: what to do right now covers the full incident response.

If you are locked out of your own account and cannot reset through the login screen – password reset email not arriving, 2FA device lost, or an attacker changed your email – locked out of WordPress admin: how to get back in walks through the database-level recovery steps.

A short user management workflow#

Pulling it together, a maintenance rhythm that keeps a WordPress user list healthy:

• On hire: add the user with the lowest role that fits. Enable 2FA in the same session.
• On role change: update the role, do not create a new account.
• On departure: reassign their content to a generic “Editorial” account, then delete the user. Do not demote and leave.
• Every quarter: audit the user list. Check for unknown accounts, outdated roles, and dormant Administrators.
• Every quarter: verify 2FA is still enabled on every Administrator and Editor.
• Annually: review whether any custom roles from plugins are still in use. Remove the ones that are not.

User roles done well are invisible – the right people have the right access and nothing happens. Done badly, the user list is where a breach becomes a disaster. The whole system rewards restraint: fewer accounts, lower roles, no shared logins.

If you are also thinking about who can do what at the hosting layer rather than the WordPress layer, how to manage MySQL user permissions and privileges covers the same least-privilege principle applied to database users – the pattern is the same even though the tooling is different.