WordPress user roles explained: who should be an Administrator, Editor, Author or Contributor
Most small WordPress sites end up with too many Administrators. The web designer who built the site, the colleague who writes the newsletter, the agency that ran a campaign two years ago: everyone was given full access because it was the quickest way to stop the "I can't see that menu" emails. Each of those accounts can install code, change any setting and delete every other user.
WordPress ships with a role system designed to avoid exactly that. This guide explains what each built-in role can do, where the dangerous capabilities sit, and how to give every person the least access that still lets them do their job.
Roles and capabilities in one paragraph
A capability is a single permission, such as publish_posts, upload_files or activate_plugins. A role is a named bundle of capabilities. Each user has a role, and WordPress checks the capability, not the role name, before letting them do something. The Roles and Capabilities page of the WordPress documentation lists every default role and capability; the summary below follows it.
The six built-in roles
- Super Admin exists only on a Multisite network. It can create and delete sites, manage network-wide plugins and themes, and manage every user on the network.
- Administrator has access to all administration features of a single site: plugins, themes, settings, users, tools, and all content. WordPress creates one Administrator account when it is installed.
- Editor can publish and manage posts and pages, including other people's, moderate comments, manage categories and tags, and upload files. An Editor cannot install plugins, switch themes, change settings or manage users.
- Author can write, upload media for, publish, edit and delete their own posts, and nothing else. Authors cannot create or edit pages, and cannot touch posts by other users.
- Contributor can write and edit their own posts but cannot publish them: they submit them for review, and an Editor or Administrator publishes. Contributors also cannot upload files, so they cannot add images to a post themselves.
- Subscriber can log in, read and manage their own profile. On a plain WordPress site that is all; membership or shop plugins often use this role, or one of their own, for customers.
Plugins frequently add roles of their own, such as Shop Manager in WooCommerce or SEO Manager in some SEO plugins. Check what those roles can do in the plugin's documentation before assigning them: some include capabilities close to an Administrator's.
The capabilities that carry real risk
Not all permissions are equal. A handful of capabilities let an account run code or take over the site, and they are worth knowing by name.
- Installing, activating and editing plugins and themes (
install_plugins,activate_plugins,edit_plugins,edit_themesand their relatives). A plugin is PHP code that runs on your server. Anyone who can install one can do anything the server allows. By default these belong to Administrators only. - Managing users (
create_users,promote_users,delete_users). An account that can promote users can make itself, or a new account, an Administrator. unfiltered_html. It allows a user to post raw HTML, including JavaScript, in posts, pages and comments. On a single site, both Administrators and Editors have it by default; on Multisite, only Super Admins do. This is the reason an Editor account is more sensitive than it looks: if its password leaks, an attacker can plant a script on every page the Editor can edit.unfiltered_upload, which lets a user upload any file type. No role has it by default, not even Super Admin; it has to be enabled with theALLOW_UNFILTERED_UPLOADSconstant. Leave it off.
Two constants in wp-config.php reduce the damage a compromised Administrator account can do. The wp-config.php page of the Advanced Administration handbook describes both:
define( 'DISALLOW_FILE_EDIT', true );This removes the built-in plugin and theme file editors from the dashboard, so nobody can paste code into a theme file from the browser. It is a sensible default on almost any site.
define( 'DISALLOW_FILE_MODS', true );This goes further: it also blocks installing and updating plugins and themes from the dashboard. It suits sites deployed from version control, where updates arrive by another route. On a site where updates are done by clicking "Update now", it will stop those updates, so only use it if someone updates the site another way.
Choosing a role: common situations
- The owner or the person responsible for the site: Administrator. Ideally one or two people, each with their own account, never a shared "admin" login.
- A member of staff who publishes news and edits pages: Editor. They can manage all content without being able to break the site's code or settings.
- A regular blogger who writes their own posts: Author.
- A guest writer, an intern or a volunteer whose texts are checked before going live: Contributor. Someone else adds the images and publishes.
- A freelance developer fixing a problem: Administrator for the duration of the job, then downgrade or delete the account. Agree this before giving access.
- Customers, members or newsletter readers: Subscriber, or the role created by the membership or shop plugin.
If nobody fits a built-in role exactly, pick the lower one and see what is missing before reaching for a role-editor plugin. Custom roles are legitimate, but every capability you add by hand is one more thing to remember during the next audit.
The settings that create users for you
Two options under Settings → General deserve a look. Membership: Anyone can register lets visitors create an account from the login page. Leave it unticked unless the site really needs public sign-up. New User Default Role sets the role those visitors receive. It should be Subscriber. A site where anyone can register and the default role is Author or above is handing out publishing rights to strangers, and spam bots find such sites quickly.
Auditing the user list
Open Users → All Users and filter by role using the links above the table. Then, once a year or whenever someone leaves:
- Count the Administrators. For each one, ask who it is and whether they still need it. Downgrade with the Change role to… menu above the list.
- Look for unknown accounts, especially Administrators you do not remember creating. An unexpected Administrator is a classic sign of a compromised site: change all passwords, check the plugins list and restore from a clean backup if needed.
- Delete accounts that are no longer used. When you delete a user who has written content, WordPress asks whether to delete that content or attribute it to another user. Choose Attribute all content to and pick an existing account, or the posts will go with the user.
- Check application passwords. On each remaining Administrator's profile page, the Application Passwords section lists the passwords issued to apps and services. Revoke the ones nobody recognises.
Protecting the accounts that matter
Roles limit what an account can do; they do not stop someone from logging in as it. Every Administrator and Editor should use a unique, long password from a password manager and a second factor: two-factor authentication for WordPress explains the options, from authenticator apps to passkeys. Limiting repeated login attempts, covered in login lockouts and maintenance mode, slows down password guessing against the accounts you keep.
Finally, before a big clean-up of users or roles, take a backup. Deleting the wrong account with "delete all content" ticked is the kind of mistake that is easy to undo only if you can restore; how to back up a WordPress site covers making one and testing it.
A short checklist
- One or two named Administrators, no shared "admin" account.
- Editors for people who manage content, Authors and Contributors for people who only write.
- Anyone can register: off, unless needed; default role: Subscriber.
DISALLOW_FILE_EDITset totrueinwp-config.php.- Former staff and freelancers removed, their content attributed to a current user.
- Two-factor authentication on every account that can publish or change settings.
Logins & site adminTwo-factor authentication
Authenticator apps, passkeys and backup codes: which second factor to choose and how to roll it out safely.
Logins & site adminLogin lockouts and maintenance mode
Two kinds of lock-out for WordPress: limiting failed login attempts against brute-force attacks, and closing the site to visitors during maintenance without hurting SEO.
Logins & site adminBacking up WordPress
Files and database as one set, copies in separate places, and a test restore before the day you need it.