WordPress login redirects by role, explained

WordPress login redirects by role let different users land on different pages immediately after authentication. Instead of sending every administrator, editor, customer, member or contributor through the same post-login flow, WordPress can choose a destination based on the role attached to the authenticated account.

This is useful on websites where different kinds of users have completely different reasons for signing in.

An administrator may need the WordPress dashboard. An editor may need the Posts screen. A customer may need an account page. A member may need a private content area. Sending all of them to the same destination adds an unnecessary step and can expose an interface that has little relevance to their actual task.

This guide explains how WordPress login redirects work, how the login_redirect filter behaves, how roles and capabilities differ, what happens with multi-role users, how redirect_to affects the process and how to implement role-based login destinations safely.

What is a WordPress login redirect?

A login redirect determines where WordPress sends a user after authentication succeeds.

A typical WordPress login flow looks like this:

Visitor opens login page
        ↓
Credentials submitted
        ↓
WordPress authenticates user
        ↓
Authentication succeeds
        ↓
Redirect destination determined
        ↓
User is sent to destination

The destination may be influenced by:

• WordPress’s normal login behavior;
• a redirect_to parameter;
• a plugin;
• theme code;
• custom authentication logic;
• the login_redirect filter.

Role-based login redirects add another decision to this process:

Administrator → /wp-admin/
Editor        → /wp-admin/edit.php
Subscriber    → /my-account/
Customer      → /account/
Member        → /members/

Why redirect users by role?

Different WordPress roles exist because different users have different responsibilities.

The same principle can be applied to navigation after login.

An administrator might need:

/wp-admin/

while a customer might need:

/my-account/

and a contributor might be better served by:

/wp-admin/post-new.php

Sending users directly to the area relevant to them can:

• reduce unnecessary navigation;
• make membership sites easier to use;
• keep customers away from irrelevant admin screens;
• simplify editorial workflows;
• create clearer onboarding flows;
• reduce confusion after authentication.

If the distinction between WordPress roles and their permissions is not yet clear, start with WordPress user roles and capabilities, explained.

Roles and capabilities are not the same thing

A role is a named collection of capabilities.

Examples include:

• Administrator;
• Editor;
• Author;
• Contributor;
• Subscriber.

A capability is an individual permission such as:

edit_posts
publish_posts
manage_options
upload_files

The official WordPress Roles and Capabilities documentation explains how WordPress uses these permissions to determine what authenticated users can do.

This distinction is important because a redirect based on role changes only where a user lands. It does not change what that user is allowed to access.

A login redirect is not access control

Suppose Subscribers are redirected to:

/member-dashboard/

That does not automatically prevent them from attempting to visit:

/wp-admin/

or another protected area.

A redirect controls navigation after login. Permissions determine whether the user can perform actions after reaching a particular area.

This distinction is fundamental.

Do not use a login redirect as a replacement for:

• capability checks;
• role restrictions;
• content access controls;
• authentication checks;
• administrator authorization.

For a broader review of the permission model, see How to audit user roles on a WordPress site.

WordPress provides the login_redirect filter

WordPress exposes the login_redirect filter specifically for changing the destination after a successful login.

The official login_redirect documentation defines three parameters:

$redirect_to
$requested_redirect_to
$user

A basic callback looks like this:

add_filter(
    'login_redirect',
    'my_login_redirect',
    10,
    3
);

function my_login_redirect(
    $redirect_to,
    $requested_redirect_to,
    $user
) {
    return $redirect_to;
}

The filter receives the destination WordPress currently intends to use and lets your code return a different URL.

What does $redirect_to contain?

$redirect_to represents the destination WordPress has resolved for the login.

Your callback can preserve it:

return $redirect_to;

or replace it:

return home_url( '/account/' );

Returning the original value is important when your custom logic has no reason to interfere with the current login flow.

What is $requested_redirect_to?

WordPress login URLs can contain a requested destination.

For example:

https://example.com/wp-login.php
?redirect_to=https%3A%2F%2Fexample.com%2Fprivate-page%2F

This often occurs when someone attempts to visit a protected area before logging in.

The intended flow becomes:

Protected page requested
        ↓
User is sent to login
        ↓
Original destination stored
        ↓
Login succeeds
        ↓
User returns to requested page

A role-based redirect system needs to decide whether that requested destination should remain more important than the configured role destination.

Should role redirects override redirect_to?

There is no universally correct answer.

Two valid approaches exist.

Approach 1: preserve requested destinations

If a user was sent to the login form because they requested a particular page, you may want them to continue to that page after authentication.

This works well for:

• members-only articles;
• private dashboards;
• checkout flows;
• account actions;
• protected downloads.

Approach 2: always enforce the role destination

Some workflows require a predictable destination regardless of where the user came from.

For example:

Customer → /my-account/
Editor   → /editor-dashboard/
Vendor   → /vendor-panel/

TheOneWP Redirect After Login follows this second model: a configured role destination takes priority over the requested redirect_to value.

Neither strategy is automatically better. The important part is choosing intentionally rather than allowing competing plugins to engage in a small redirect civil war.

Use the $user parameter inside login_redirect

The login_redirect callback receives the authenticated user object directly.

Use it.

The WordPress documentation specifically warns that the global current-user value may not yet be reliably available when this filter executes.

A safe check begins with:

if (
    ! $user ||
    is_wp_error( $user )
) {
    return $redirect_to;
}

Then inspect the authenticated user object:

$roles = $user->roles;

Basic role-based login redirect example

A simple implementation could look like this:

add_filter(
    'login_redirect',
    'example_login_redirect',
    10,
    3
);

function example_login_redirect(
    $redirect_to,
    $requested_redirect_to,
    $user
) {
    if (
        ! $user ||
        is_wp_error( $user )
    ) {
        return $redirect_to;
    }

    if (
        in_array(
            'administrator',
            $user->roles,
            true
        )
    ) {
        return admin_url();
    }

    if (
        in_array(
            'editor',
            $user->roles,
            true
        )
    ) {
        return admin_url( 'edit.php' );
    }

    if (
        in_array(
            'subscriber',
            $user->roles,
            true
        )
    ) {
        return home_url( '/account/' );
    }

    return $redirect_to;
}

The callback:

1. confirms authentication produced a valid user;
2. checks the user’s roles;
3. returns a destination for matching roles;
4. falls back to WordPress behavior when no rule applies.

Always provide a fallback

Role redirect logic should not assume every possible account matches one of your hardcoded roles.

Plugins can create custom roles.

Sites can remove or rename roles.

A user may have an unusual configuration.

Therefore:

return $redirect_to;

is usually preferable to forcing an arbitrary destination when no explicit rule matches.

Custom roles change the picture

Many real WordPress installations contain more than the standard built-in roles.

Examples might include:

customer
shop_manager
vendor
member
instructor
student
moderator

Plugins such as ecommerce, LMS, forum and membership systems commonly register their own roles.

A role-based redirect solution should therefore work with registered WordPress roles rather than assume the website contains only Administrator, Editor, Author, Contributor and Subscriber.

For a deeper comparison of role architecture, see Custom WordPress roles vs. combining existing ones.

What happens when a user has more than one role?

This is where simple redirect snippets become less simple.

A user can potentially have several roles associated with the same account.

Imagine:

User:
    Editor
    Shop Manager

If you configure:

Editor       → /wp-admin/edit.php
Shop Manager → /wp-admin/admin.php?page=orders

which destination should win?

A system must define a priority rule.

Do not rely blindly on role array order

A naive implementation might do this:

$role = $user->roles[0];

and assume the first role is automatically the most important one.

That is fragile.

If your application supports multiple roles, define how conflicts are resolved.

Possible approaches include:

• explicit administrator-defined priority;
• capability-based priority;
• a fixed role hierarchy;
• first matching configured rule;
• a dedicated primary-role setting.

TheOneWP uses capability-based role priority

Redirect After Login resolves multi-role accounts dynamically.

If several of the user’s roles have destinations configured, the module compares how many capabilities each role grants and uses the destination associated with the most privileged matching role.

This avoids hardcoding a list such as:

administrator
editor
author
contributor
subscriber

and means custom roles can participate in the same resolution process.

The approach is particularly relevant on sites using multiple-role configurations.

Capability count is a priority strategy, not WordPress access control

It is important to distinguish two ideas.

WordPress itself decides whether a user may perform an action by checking capabilities.

The redirect module uses role capabilities only to resolve which configured destination wins when several roles compete.

That does not create a new WordPress security hierarchy.

The actual merged capabilities available to a user can be retrieved through WordPress’s user APIs. The official WP_User::get_role_caps() documentation explains how role capabilities and individual capabilities are combined.

Role redirects should use destinations users can actually access

It is entirely possible to configure a technically valid redirect to a page the user cannot use.

For example:

Subscriber
→ /wp-admin/plugins.php

The redirect may succeed, but the Subscriber still lacks permission to manage plugins.

WordPress will enforce the relevant capability checks afterward.

A good redirect configuration therefore aligns destination and permissions.

For example:

Administrator
→ /wp-admin/

Editor
→ /wp-admin/edit.php

Customer
→ /my-account/

Member
→ /members-dashboard/

Redirecting administrators

For administrators, the normal WordPress administration area is usually a sensible destination:

admin_url()

which typically resolves to:

https://example.com/wp-admin/

You could also send administrators to a specific management screen if the website has a specialized workflow.

Redirecting editors

An editor may not need the main dashboard at all.

A direct route to posts can be more useful:

admin_url( 'edit.php' )

or perhaps a custom editorial dashboard:

home_url( '/editorial-dashboard/' )

The correct destination depends on how the site is actually operated.

Redirecting authors and contributors

Authors and contributors are often interested primarily in content creation.

Possible destinations include:

/wp-admin/edit.php
/wp-admin/post-new.php

or a custom frontend submission interface.

Again, the redirect should reflect the actual role workflow rather than merely send everyone somewhere different for the sake of having configuration options.

Redirecting subscribers

Subscribers generally have very limited administration permissions.

On a membership site, sending them into wp-admin may add little value.

A destination such as:

/account/
/members/
/dashboard/

can provide a much clearer experience.

Redirecting WooCommerce customers

WooCommerce sites commonly want customers to land on the account area rather than the WordPress dashboard.

A conceptual rule might be:

customer
→ /my-account/

If another plugin controls WooCommerce authentication or checkout redirects, test the complete workflow carefully because multiple systems may filter the same destination.

Login redirects are especially useful on membership sites

Membership sites often have several distinct destinations.

For example:

Administrator → WordPress admin
Instructor    → Instructor dashboard
Member        → Member dashboard
Student       → Course area

This can turn login into part of the application’s navigation rather than simply a gateway to wp-admin.

Role redirects can improve onboarding

The first page shown after authentication has disproportionate importance.

A new user may expect to immediately find:

• their account;
• their course;
• their orders;
• their content;
• their dashboard;
• their assigned tasks.

Sending them first to a generic WordPress dashboard and expecting them to discover the correct area introduces needless friction.

Redirect After Login exists specifically to replace that one-size-fits-all post-authentication destination with per-role destinations.

Internal page destination vs. custom URL

A redirect system may allow two broad destination types.

WordPress page

The administrator selects an existing page.

For example:

Member Dashboard
Customer Account
Contributor Welcome

The advantage is that WordPress can resolve the current permalink for that page rather than forcing the administrator to maintain a hardcoded URL.

Custom URL

The administrator enters a URL directly:

https://portal.example.com/

This is more flexible but requires careful redirect validation.

External login redirects need additional care

Redirecting a user to another domain can introduce an open-redirect risk if arbitrary visitor-controlled destinations are accepted.

WordPress provides wp_safe_redirect() for redirects that should be limited to approved hosts.

The official wp_safe_redirect() documentation explains that the function validates the destination host and falls back when the host is not allowed.

If your system supports administrator-configured external destinations, allow only explicitly trusted hosts rather than accepting a URL directly from an untrusted request parameter.

How TheOneWP handles custom external destinations

Redirect After Login supports custom URLs in addition to local WordPress pages.

When an external custom URL is configured, its host is explicitly added to WordPress’s allowed redirect hosts so the destination can be used intentionally without opening redirects to arbitrary domains.

This distinction matters because:

Administrator chooses trusted destination
≠
Visitor supplies arbitrary redirect destination

What happens if the configured page is deleted?

A saved page ID can become invalid later.

The page might be:

• deleted;
• moved to Trash;
• changed to draft;
• made private;
• otherwise unpublished.

A robust redirect implementation should not blindly generate a destination from a page that is no longer valid.

Redirect After Login checks that a configured page is still published before using it. If the page is no longer valid, that role-specific destination is skipped and normal WordPress redirect behavior can continue.

What if no destination is configured for a role?

A role-based redirect system should not require every role to have a custom destination.

If no rule exists, WordPress can continue with its normal behavior.

This makes it possible to configure only the roles that need special treatment.

For example:

Administrator → default WordPress behavior
Editor        → default WordPress behavior
Customer      → /my-account/
Member        → /members/

This is generally cleaner than inventing destinations simply to fill every field.

Redirect After Login is not Redirect Manager

It is easy to see the word “redirect” and assume every redirect belongs to the same system. WordPress has apparently decided one word is enough for several entirely different jobs.

Redirect After Login handles navigation immediately after authentication.

A general redirect manager handles public URL routing such as:

/old-page/
→ /new-page/

Those are different problems.

A login redirect should not be added to your general SEO redirect table, and an old-page 301 does not belong in login authentication logic.

Login redirects are not the same as changing the login URL

Another separate feature is changing where the login form itself lives.

TheOneWP Custom Login URL changes the login endpoint and controls what happens when visitors request the default WordPress login addresses.

Redirect After Login instead controls what happens after credentials have been accepted.

The sequence is:

Custom Login URL
        ↓
User reaches login form
        ↓
Authentication
        ↓
Redirect After Login
        ↓
Role destination

For the security context around the login endpoint itself, see WordPress Login Security Layers, Explained.

Login redirects do not make authentication more secure

Sending a Subscriber to /account/ instead of /wp-admin/ does not make their password stronger.

Role redirects are primarily a workflow and user-experience feature.

Authentication security is handled by separate controls such as:

• strong credentials;
• rate limiting;
• IP restrictions where appropriate;
• two-factor authentication;
• account blocking;
• login monitoring.

TheOneWP Access Manager addresses login-side protection with IP rules, failed-login limits, lockouts and login-event logging.

Two-factor authentication happens before the final destination matters

On a site using two-factor authentication, the user may need to complete an additional authentication step before the login workflow is considered complete.

TheOneWP Two-Factor Authentication adds TOTP-based second-factor authentication to WordPress accounts.

The final role destination should be viewed as the endpoint of the authentication process, not as a mechanism for bypassing any required authentication step.

Login and logout redirects are separate

The destination after signing in and the destination after signing out solve opposite parts of the session lifecycle.

A complete flow might be:

Login
↓
Member dashboard
↓
User works
↓
Logout
↓
Public homepage

TheOneWP Redirect After Logout provides separate role-based destinations after logout.

This allows a site to design both ends of the session deliberately rather than treating login and logout as unrelated accidents of core behavior.

Example role-based login architecture

Consider a website with several account types:

Administrator
Editor
Customer
Premium Member

A sensible redirect plan might be:

Administrator
→ /wp-admin/

Editor
→ /wp-admin/edit.php

Customer
→ /my-account/

Premium Member
→ /premium-dashboard/

Now compare that with sending all four roles to:

/wp-admin/

The first structure reflects what each account is actually there to do. The second simply reflects WordPress’s origins as a publishing application.

Example with custom roles

Suppose an LMS defines:

student
instructor

You could use:

student
→ /courses/

instructor
→ /instructor-dashboard/

No built-in WordPress role needs to be involved.

This is why a reusable role-based redirect system should read the site’s registered roles rather than hardcode the five common single-site roles.

Example with a multi-role user

Now imagine:

User roles:
Editor
Instructor

with configuration:

Editor
→ /wp-admin/edit.php

Instructor
→ /instructor-dashboard/

A role-based system needs a deterministic answer.

Redirect After Login resolves this by comparing the capabilities granted by the configured roles and using the destination belonging to the most privileged match.

Test role redirects with real accounts

Do not test only with your administrator account.

Create or use representative accounts for:

• Administrator;
• Editor;
• Subscriber;
• custom roles;
• multi-role users where applicable.

For each account, verify:

1. the login succeeds;
2. the expected redirect fires;
3. the destination loads successfully;
4. the user has permission to use the destination;
5. logout still works;
6. password reset remains functional;
7. protected-page login flows behave as intended.

Test logins that contain redirect_to

Do not test only a direct visit to the login form.

Also test URLs such as:

/wp-login.php?redirect_to=/protected-page/

or the equivalent URL generated automatically by a plugin.

This confirms whether your role rule or requested destination wins according to your intended logic.

Test external destinations separately

If a role is redirected to another domain, verify:

• the configured URL is valid;
• the external host is trusted;
• WordPress allows the destination;
• HTTPS is used where appropriate;
• the destination actually exists;
• no redirect loop returns the visitor to WordPress.

Watch for conflicts between plugins

Several plugins can hook into login_redirect.

For example:

• membership plugins;
• WooCommerce extensions;
• LMS plugins;
• security plugins;
• custom authentication systems;
• role-management plugins.

When several callbacks modify the same filter, hook priorities and callback behavior determine which result survives.

If a login redirect appears inconsistent, inspect whether another plugin also controls post-login navigation.

Do not put redirect logic in multiple places unnecessarily

A common maintenance problem looks like this:

Theme functions.php
    → login redirect

Membership plugin
    → login redirect

Custom plugin
    → login redirect

WooCommerce extension
    → login redirect

The final destination then depends on whichever callback effectively wins.

Centralize the logic where possible.

One clearly documented redirect system is considerably easier to maintain than four independent systems politely overwriting one another.

Check role architecture before creating redirect rules

If your site has accumulated many roles over time, review them before building complex redirect rules around them.

How to audit user roles on a WordPress site explains how to review existing account assignments and identify roles that may no longer reflect the site’s actual workflow.

Redirect rules become easier to understand when the permission model itself is coherent.

Do not confuse custom roles with custom dashboards

Creating a role does not automatically create a dashboard for that role.

Similarly, creating a custom dashboard does not automatically restrict it to one role.

These are separate responsibilities:

Role
→ describes permissions

Dashboard
→ provides interface

Login redirect
→ determines initial destination

Good WordPress application design often combines all three, but they remain independent systems.

Role checks vs. capability checks

For choosing a post-login destination, role checks are often appropriate because the configuration itself is usually expressed per role.

For protecting functionality, capability checks are generally more robust.

For example:

if (
    current_user_can( 'edit_posts' )
) {
    // Allow editorial action.
}

is usually better security logic than assuming only users named “Editor” should be allowed to perform that action.

A site can therefore use:

Role → choose where user lands
Capability → decide what user may do

Common WordPress login redirect mistakes

Assuming every user has exactly one role

Multi-role accounts require a defined conflict-resolution strategy.

Using $current_user too early

The login_redirect filter already provides the authenticated user object. Use that parameter.

Forgetting that $user can be WP_Error

Validate the value before accessing $user->roles.

Redirecting users to pages they cannot access

The redirect URL and the user’s capabilities should make sense together.

Confusing navigation with authorization

A redirect does not protect wp-admin or sensitive functionality.

Ignoring redirect_to

Decide deliberately whether requested destinations or role destinations take priority.

Hardcoding only built-in WordPress roles

WooCommerce, membership systems and custom applications frequently use additional roles.

Accepting arbitrary external redirect URLs

External destinations should be validated and restricted to trusted hosts.

Creating conflicting login logic in multiple plugins

Multiple callbacks on the same filter can produce confusing results.

Testing only with an administrator

A feature designed around roles should be tested with the roles that actually use it. A revolutionary concept, apparently.

WordPress login redirect checklist

• List every role that actually needs a custom destination.
• Include custom plugin roles where relevant.
• Decide how multi-role users should be resolved.
• Decide whether redirect_to should take priority.
• Use the $user parameter supplied by login_redirect.
• Handle WP_Error safely.
• Provide a fallback to normal WordPress behavior.
• Send users only to destinations they can access.
• Validate external destinations.
• Keep login redirects separate from access-control rules.
• Keep login redirects separate from general 301/302 redirects.
• Test each relevant role.
• Test custom roles.
• Test multi-role accounts.
• Test requested redirect_to destinations.
• Check for plugin conflicts.
• Test logout separately.

Related WordPress role and login guides

For the other parts of WordPress role-based access and authentication, continue with:

• WordPress user roles and capabilities, explained
• How to audit user roles on a WordPress site
• Custom WordPress roles vs. combining existing ones
• WordPress Login Security Layers, Explained
• Redirect After Login
• Redirect After Logout
• Access Manager
• Custom Login URL
• Two-Factor Authentication

Final thoughts

WordPress login redirects by role are fundamentally a workflow feature.

They let the site answer a simple question after authentication: where does this particular kind of user actually need to go?

WordPress provides the login_redirect filter for controlling that destination, while the authenticated WP_User object provides the role information needed to make the decision.

The important part is keeping responsibilities separate. Roles can determine which destination is appropriate. Capabilities determine what users are allowed to do. Security controls protect authentication. General URL redirects manage moved public content.

TheOneWP Redirect After Login packages the post-login part of that workflow into role-specific page or URL destinations, including custom roles and deterministic handling of multi-role users. Redirect After Logout handles the opposite end of the session when users sign out.

When those responsibilities are kept distinct, login stops being a generic doorway into WordPress and becomes a deliberate entry point into the part of the site each user actually needs.