WordPress User Roles and Permissions Explained, With Custom Role Examples

Giving a contractor full admin access is like handing over your house keys when they only needed the garage. Most of the time nothing goes wrong. Then a password gets reused, or an old account never gets deleted, and someone who came to fix a contact form can suddenly install plugins and delete users.

WordPress user roles are how you prevent that. Below you’ll find what each default role can do, a table to check at a glance, and then the harder stuff: custom roles in code, setups for agencies and stores, and a quick security check.

What Are WordPress User Roles and Permissions?

A WordPress user role decides what a person can do on your site. Each single action, like publishing a post or installing a plugin, is called a capability.

Think of it as two layers. Roles are job titles. Capabilities are the specific actions that job is allowed to perform. WordPress checks capabilities, not titles, whenever someone tries to do something. That’s why you can change what an Editor is allowed to do without inventing a new role, and why good code asks “can this user publish?” instead of “is this user an Editor?”

Plenty of guides blur the two. The official WordPress documentation on roles and capabilities is the reference every claim here was checked against.

The 6 Default WordPress User Roles (Explained)

Five or six? You’ll see both numbers online, and both are partly right. A standard single site has five default roles. Super Admin is the sixth, and it only exists once Multisite is switched on. Run one site and you’ll see five in the dropdown. Run a network and you’ll see six.

So what separates Author, Contributor, and Editor? Publishing and reach. A Contributor can’t publish. An Author can publish, but only their own posts. An Editor can publish and manage everyone’s.

WordPress Roles and Capabilities Reference Table

Here are the capabilities people ask about most, mapped to each default role.

*Single site installs only. On Multisite, a site Administrator can’t install plugins or edit users by default. Those powers sit with the Super Admin.

Two caveats. Plugins add their own capabilities on top of this list, and WooCommerce and most LMS tools do exactly that. And the table shows defaults. Any plugin or snippet can change them, so a site’s real permissions can differ from what’s printed here.

How to Add Users and Change Roles

To add a user, go to Users, then Add New. Enter a username and email, pick a role from the dropdown, set a strong password, and send the notification email if you want the person to log in right away.

To change someone’s role, open Users, then All Users, hover over the name, and click Edit. Choose a new role and hit Update User. For several people at once, tick their checkboxes on the Users screen, use the “Change role to” dropdown at the top, and click Change.

How to Create a Custom WordPress Role (Two Ways)

Default roles cover a lot, but they’re blunt. Sooner or later someone needs “Editor, except they can’t see pages” or “Shop Manager, minus the reports.” You can build that two ways.

With a Plugin (No Code)

A role editor plugin lets you clone an existing role, tick or untick capabilities, and save the result under a new name. For a one off change on a small site, that’s perfectly reasonable.

Before installing one, check its last update date, WordPress version support, and what happens to your roles if you deactivate it. Roles live in the database, so they usually survive. Usually isn’t a guarantee, so test on a staging copy.

With Code (The Developer Approach)

Code gives you roles that are versioned, repeatable, and identical across staging and production. The WordPress Plugin Handbook on roles and capabilities documents the functions used below.

Put this in a small custom plugin, not in your theme’s functions.php. A theme switch shouldn’t change who can do what. Also remember that add_role() writes to the database, so it only needs to run once. Hooking it to plugin activation handles that cleanly.

<?php
/**
 * Plugin Name: Client Roles
 * Description: Adds a Client Editor role for agency handoffs.
 * Version: 1.0.0
 */

register_activation_hook( __FILE__, 'cr_add_client_editor_role' );

function cr_add_client_editor_role() {
    add_role(
        'client_editor',
        'Client Editor',
        array(
            'read'                   => true,
            'upload_files'           => true,
            'edit_posts'             => true,
            'edit_others_posts'      => true,
            'edit_published_posts'   => true,
            'publish_posts'          => true,
            'delete_posts'           => true,
            'delete_published_posts' => true,
            'edit_pages'             => true,
            'edit_others_pages'      => true,
            'edit_published_pages'   => true,
            'publish_pages'          => true,
            'manage_categories'      => true,
        )
    );
}

To change an existing role instead, use get_role() with add_cap() and remove_cap(). These also save to the database, so run them once on activation as well.

register_activation_hook( __FILE__, 'cr_tweak_editor_role' );

function cr_tweak_editor_role() {
    $editor = get_role( 'editor' );

    if ( $editor ) {
        $editor->add_cap( 'edit_theme_options' );   // lets Editors manage menus and widgets.
        $editor->remove_cap( 'moderate_comments' ); // takes comment moderation away.
    }
}

Then check permissions in templates or plugins with current_user_can(). Always test the capability, never the role name.

if ( current_user_can( 'edit_others_posts' ) ) {
    // Show the editorial review panel.
}

If you need to delete a role you created, remove_role() does that. Never edit WordPress core files to change roles. The next update will wipe your work out.

Custom Roles for Real Business Scenarios

Here’s how the capability logic plays out in four situations that come up constantly.

The agency client handoff

The agency has built the site, and the client wants to update copy and publish news. The Client Editor role above gives them content control and nothing more. What stays out matters most: install_plugins, switch_themes, edit_theme_options, list_users, edit_users, and manage_options.

A client who can’t install plugins can’t break the build, and a compromised client login can’t reach the settings that matter. Teams offering custom WordPress development services often package this role into every handoff.

The WooCommerce Shop Manager tweak

WooCommerce has a Shop Manager role that includes orders, products, and customers. What if a store owner employs part time staff to pack orders? They need to view orders and print labels, but not sales reports. Deactivate the view_woocommerce_reports capability in a duplicate of the role (or the original role), and all is sorted. Capability titles might vary slightly between WooCommerce versions, so verify the latest release.

The LMS Instructor

Most learning plugins ship their own instructor role, which is fine until you need something slightly different. The cleaner route is giving your course post type its own capabilities:

• Register the post type with capability_type set to course and map_meta_cap set to true.
• WordPress then generates capabilities like edit_courses, publish_courses, and delete_courses.
• Create an Instructor role with those, plus read and upload_files.
• Leave edit_others_courses off so instructors only touch their own material.

The multi-author Publisher

A magazine with ten writers wants a gatekeeper. Contributors and Authors submit. A Publisher role holds edit_others_posts, publish_posts, and manage_categories, but not page editing, plugin access, or user management. It’s an Editor with a smaller footprint, and that’s the point.

Securing User Access: Least Privilege and Role Auditing

A compromised Administrator account is a compromised site. That’s the whole argument for least privilege, which simply means each person gets the minimum access their work requires.

Most real damage doesn’t come from clever attacks. It comes from admin sprawl. Four people with Administrator access because it was easier. A developer who left two years ago whose account still works. A shared login nobody owns. Every one of those is a door left open, and attackers don’t need much to walk through. For a wider view of the threats around that door, see this overview of WordPress security challenges and solutions.

A simple audit routine works well, and quarterly is plenty for most teams:

Honestly, step five gets skipped most often and pays off most. When something odd happens, you’ll know within a minute who had access.

User Roles on WordPress Multisite

Multisite changes the picture in ways that catch people out. One user account can exist across a whole network, but roles are assigned per site. The same person can be an Editor on one site, a Subscriber on another, and have no access to a third.

Then there’s the Super Admin, who sits above all of it. Super Admins manage the network itself: creating sites, installing plugins and themes, and managing users across every site. A site level Administrator has far less power than a single site Administrator does, which is deliberate.

This matters for enterprises and multi brand setups. When one network hosts ten brands, a careless Super Admin grant isn’t a ten minute problem. It’s a ten-site problem. Keep that role tiny. If you’re weighing whether a network is the right structure in the first place, the benefits of a WordPress multisite setup are covered separately, so they aren’t repeated here.

When Default Roles Are Not Enough (and You Need Custom Development)

Plugin-based roles carry most sites a long way. Some outgrow them, and the signals are fairly consistent:

• Access rules depend on conditions, such as “edit only posts in your own department” or “only during onboarding.”
• Custom capabilities need to be tied to several custom post types.
• Role logic has to stay consistent across integrations, like a CRM, an LMS, and a membership tool.
• Compliance requires documented, auditable access control.

If two or more of those sound familiar, you’re past clicking checkboxes. That’s development work: designing the capability model, writing it as code, testing it, and keeping it working through updates. A WordPress developer you can hire for that job should be able to show you a capability map before writing a line.

Common Mistakes and Myths

Wrapping Up

Set up your WordPress user roles well and you get a safer site and a team that can still work. Start with the defaults, give people the lowest role that fits, and check who has access every few months. If your rules get too complicated for a few checkboxes, that’s a job for a developer.

Frequently Asked Questions