You just hired a talented freelance writer to help scale your content marketing. You want them to log into your website, draft their posts, format the text, and get everything ready for your final review. What you don’t want is for them to accidentally publish a half-finished draft, mess with your carefully configured Elementor layouts, or wander into your WP Engine server settings.
You navigate to the WordPress dashboard, click “Add New User,” and pause. The dropdown menu presents you with a list: Administrator, Editor, Author, Contributor, Subscriber. What’s the actual difference? And which one is safe to assign?
As a WordPress consultant, I spend a lot of time auditing infrastructure and cleaning up site architectures. I can tell you firsthand that improper role assignment is one of the most common ways sites get accidentally broken or maliciously compromised. Giving a contractor “Administrator” access because it was easier than figuring out the right role is the WordPress equivalent of giving someone the master keys to your building when they only need to water the plants.
In this guide, we are going to break down how WordPress handles user roles, how to assign them correctly, and how to write clean, performance-minded code to create your own.
The Philosophy: Scope of Trust, Not Seniority
The biggest mistake site owners make is treating WordPress roles like a corporate hierarchy. They give the CEO the “Administrator” role because it sounds like the highest rank, and they give the new hire “Subscriber.”
WordPress roles are not about seniority. They are about scope of trust and operational necessity.
This boils down to a core security concept known as the Principle of Least Privilege: a user should only have the bare minimum access rights necessary to perform their specific job.
The Default WordPress Roles Demystified
Out of the box, a standard WordPress installation ships with five primary user roles. Here is exactly what they can and cannot do.
1. Administrator
The Administrator has the keys to the kingdom.
- Capabilities: They can do everything. Publish posts, delete pages, install or delete plugins, change the core theme, alter deep database settings, and delete other users.
- Who gets it: Only the absolute core technical owners of the site. Your lead developer, your server administrator, and perhaps the primary business owner.
- The Risk: An Administrator can install a rogue plugin, break your caching layers, or accidentally wipe your database. Hand this role out very sparingly.
2. Editor
The Editor is the master of your content, but they are locked out of the site’s infrastructure.
- Capabilities: Publish, edit, and delete any post or page on the site, regardless of who wrote it. They can moderate comments, manage categories, and upload media files.
- Who gets it: Your Content Manager, Marketing Director, or Lead Editor.
3. Author
The Author is the master of their own domain.
- Capabilities: Write, edit, publish, and delete their own posts. They can also upload files to the media library.
- Limitations: They cannot touch posts written by other people, and they cannot create or edit Pages (like your Homepage or Contact page).
- Who gets it: Trusted staff writers or regular columnists who are authorized to publish directly to the live site.
4. Contributor
The Contributor is perfect for external freelancers.
- Capabilities: They can write and edit their own posts.
- Limitations: They cannot publish their posts. A Contributor must submit their draft for review, and an Editor or Administrator must click “Publish.” Standard Contributors also cannot upload files to the Media Library.
- Who gets it: Freelance writers, guest bloggers, or new employees whose work requires editorial oversight.
5. Subscriber
The Subscriber is the lowest tier of access.
- Capabilities: Log into the site, read content, and manage their own user profile (like changing their password).
- Limitations: Everything else. They cannot write posts or see the backend dashboard beyond their profile page.
- Who gets it: Customers, clients, or newsletter subscribers.
Under the Hood: Capabilities and Code
Now let’s look at how WordPress handles this system beneath the surface.
A “Role” in WordPress is just a labeled bucket. The actual permissions inside that bucket are called Capabilities.
Capabilities are granular, specific permissions. Examples include:
edit_postspublish_postsedit_others_postsupdate_pluginsunfiltered_html
When a user tries to click the “Update Plugin” button, WordPress doesn’t ask, “Is this user an Administrator?” Instead, the system asks, “Does this user’s current role possess the update_plugins capability?”
Where Roles Live in the Database
WordPress stores these roles and capabilities in the database within the wp_options table, under the wp_user_roles option. It stores them as a serialized array—a structured string of data mapping out exactly which roles have which capabilities.
Because this data is saved directly in the database, it is persistent.
Creating Custom Roles: The Clean Implementation
The default roles rarely fit a growing business perfectly.
Let’s say you have a “Content Manager.” You want them to be able to edit and publish all Posts and Pages. However, you don’t want them messing with your plugin configurations, and you don’t want them managing other users.
We can programmatically create a custom role using the add_role() function. Here is a clean example of registering that exact role:
add_role(
'content_manager',
'Content Manager',
[
'read' => true,
'edit_posts' => true,
'edit_others_posts' => true,
'publish_posts' => true,
'edit_pages' => true,
'edit_others_pages' => true,
'publish_pages' => true,
'upload_files' => true,
'manage_categories' => true,
]
);
The init Hook Performance Trap
If you are writing custom code for this, there is a massive performance bottleneck you must avoid.
Because add_role() writes data directly to your wp_options table, you should never place this function loosely inside the init hook without a logical guard rail.
If you do, WordPress will execute a database write to recreate this role on every single page load. If your site gets 5,000 visitors a day, your server is rewriting the user roles array to the database 5,000 times a day. This causes unnecessary database bloat and slows down response times.
The Fix: You only need to run add_role() once. Best practice is to place role creation inside a plugin activation hook (register_activation_hook) or run it once via WP-CLI.
(If you prefer a no-code approach, plugins like User Role Editor or Members provide excellent, visual UI wrappers for these same database modifications).
Your Practical Action Plan
If you manage a team or maintain client sites, take five minutes today to run a quick permission audit.
- Log into your WordPress Dashboard.
- Click on Users -> All Users.
- Look at the top filters or sort by the Role column.
If you see more than two or three Administrators, you have a security vulnerability. Does your graphic designer really need Admin access to upload a logo? Does the SEO agency you hired two years ago still have the keys to the server? Downgrade or delete those accounts immediately.
Map your company hierarchy to actual capabilities. When in doubt, ask yourself: “What is the absolute minimum level of access this person needs to do their job today?” Getting your WordPress user roles right creates a secure, streamlined environment. It allows your team to do their best work without the looming fear of accidentally bringing down the entire website.
Ready to dive deeper into custom permissions? Check out the technical companion to this post: Extending Role Capabilities in WordPress, where we cover how to modify existing roles without rewriting the whole array.