Redirecting users by role in WordPress is useful when different types of users should land in different places after logging in. An administrator may need the WordPress dashboard, an editor may need the Posts screen, a customer may need an account page and a member may need a private frontend area.
WordPress normally decides where a user goes after authentication based on the login request and the requested destination. That default behaviour works well for many websites, but role-based workflows often need something more specific.
You can implement role-based redirects with the login_redirect filter or use a configurable system when administrators need to manage destinations without editing PHP.
TheOneWP’s Redirect After Login module provides that configurable layer by allowing login destinations to be assigned according to user role while keeping the underlying WordPress authentication and permission system separate.
This guide explains how login redirects work, how to redirect WordPress users by role safely, what happens when a user has multiple roles and which mistakes can create confusing or insecure login flows.
Why redirect WordPress users by role?
Not every WordPress user needs to arrive at the same screen after logging in.
Consider a site with several user groups:
- administrators manage the site;
- editors create and review content;
- authors work mainly with their own posts;
- customers manage orders and account details;
- members access private frontend content;
- custom roles use a dedicated application interface.
Sending every one of these users to:
/wp-admin/is often unnecessary.
A customer may be better served by an account page, while an editor may benefit from going directly to the content screen they use most frequently.
Role-based login redirects make the post-login experience better match the user’s actual workflow.
How WordPress login redirects work
During the login process, WordPress determines a URL to use after authentication.
Plugins and themes can modify that destination through the login_redirect filter.
The filter receives three values:
$redirect_to
$requested_redirect_to
$userThe official WordPress login_redirect documentation explains the values passed to the filter.
$redirect_tois the URL WordPress currently intends to use;$requested_redirect_tois the destination originally requested during the login flow;$useris the authenticated user object when authentication succeeds.
This means your code can inspect the authenticated user and return a different destination when appropriate.
A basic role-based redirect example
Suppose administrators should go to the WordPress dashboard while subscribers should go to a frontend account page.
You could use:
add_filter(
'login_redirect',
function (
$redirect_to,
$requested_redirect_to,
$user
) {
if (
! $user instanceof WP_User
) {
return $redirect_to;
}
if (
in_array(
'administrator',
(array) $user->roles,
true
)
) {
return admin_url();
}
if (
in_array(
'subscriber',
(array) $user->roles,
true
)
) {
return home_url(
'/my-account/'
);
}
return $redirect_to;
},
10,
3
);The important part is that the callback returns a URL rather than performing the redirect manually.
The login_redirect filter exists specifically to modify the destination WordPress will use after login.
Why use the $user parameter instead of $current_user?
Inside the login_redirect filter, use the $user parameter passed directly to your callback.
The WordPress documentation notes that the global current-user state may not be the most reliable source at this point in the authentication flow.
A safer pattern is:
add_filter(
'login_redirect',
function (
$redirect_to,
$requested_redirect_to,
$user
) {
if (
! $user instanceof WP_User
) {
return $redirect_to;
}
// Work with $user here.
return $redirect_to;
},
10,
3
);See the official login_redirect hook reference for the underlying implementation.
Redirect administrators to wp-admin
WordPress provides admin_url() for generating administration URLs.
For example:
return admin_url();You can also target a specific administration screen:
return admin_url(
'edit.php'
);or:
return admin_url(
'post-new.php'
);The official admin_url() documentation explains how WordPress generates administration URLs.
Using WordPress URL helpers is preferable to hardcoding a full production URL because the domain, protocol or installation structure may change.
Redirect frontend users to an account page
For a frontend destination, you can use home_url().
For example:
return home_url(
'/account/'
);A subscriber redirect might therefore look like:
if (
in_array(
'subscriber',
(array) $user->roles,
true
)
) {
return home_url(
'/account/'
);
}This keeps the destination tied to the current WordPress installation instead of embedding the production domain directly in PHP.
Redirect editors to the Posts screen
If editors mainly work with posts, you can skip the generic dashboard:
if (
in_array(
'editor',
(array) $user->roles,
true
)
) {
return admin_url(
'edit.php'
);
}An editor will then land directly on the Posts screen after login.
Redirect authors to create a new post
An author-focused workflow could send users directly to the new-post screen:
if (
in_array(
'author',
(array) $user->roles,
true
)
) {
return admin_url(
'post-new.php'
);
}This can reduce unnecessary navigation when the user has a specific purpose inside WordPress.
A complete role-based redirect example
A more complete implementation might look like this:
add_filter(
'login_redirect',
function (
$redirect_to,
$requested_redirect_to,
$user
) {
if (
! $user instanceof WP_User
) {
return $redirect_to;
}
$roles =
(array) $user->roles;
if (
in_array(
'administrator',
$roles,
true
)
) {
return admin_url();
}
if (
in_array(
'editor',
$roles,
true
)
) {
return admin_url(
'edit.php'
);
}
if (
in_array(
'author',
$roles,
true
)
) {
return admin_url(
'post-new.php'
);
}
if (
in_array(
'subscriber',
$roles,
true
)
) {
return home_url(
'/account/'
);
}
return $redirect_to;
},
10,
3
);The final:
return $redirect_to;is important because users whose roles do not match one of your rules should normally retain the destination WordPress had already chosen.
What happens when a user has multiple roles?
A WP_User object exposes assigned roles through:
$user->rolesSome plugins and custom systems allow users to hold more than one role.
For example:
[
'editor',
'shop_manager'
]If your redirect logic checks both roles, you need to decide which one wins.
Consider:
if (
in_array(
'editor',
$roles,
true
)
) {
return admin_url(
'edit.php'
);
}
if (
in_array(
'shop_manager',
$roles,
true
)
) {
return home_url(
'/store-dashboard/'
);
}An account matching both conditions will use the first matching rule.
The order of your checks therefore becomes a priority system.
Define an explicit multi-role priority
For sites with several custom roles, make the priority deliberate.
One clean approach is an ordered destination map:
$destinations = [
'administrator' =>
admin_url(),
'shop_manager' =>
home_url(
'/store-dashboard/'
),
'editor' =>
admin_url(
'edit.php'
),
'author' =>
admin_url(
'post-new.php'
),
'subscriber' =>
home_url(
'/account/'
),
];Then resolve the first matching role:
foreach (
$destinations
as $role => $destination
) {
if (
in_array(
$role,
(array) $user->roles,
true
)
) {
return $destination;
}
}Now the array order explicitly defines which role takes precedence.
Role-based redirects become easier to manage through configuration
Hardcoded PHP is perfectly reasonable for a small site with stable rules.
It becomes less convenient when:
- custom roles are added frequently;
- destinations change over time;
- multiple administrators manage the site;
- multi-role priority needs to be adjusted;
- the redirect rules belong to site administration rather than code deployment.
TheOneWP’s Redirect After Login module moves this role-to-destination mapping into a configurable WordPress interface.
The underlying concept remains the same:
Authenticated user
→ inspect role
→ resolve matching destination
→ redirect after successful loginShould you redirect based on roles or capabilities?
For navigation and workflow rules, checking a role can be reasonable.
WordPress permissions themselves, however, are fundamentally based on capabilities.
The official WordPress Roles and Capabilities documentation explains how roles group capabilities and how those capabilities determine what users can do.
Examples include:
edit_posts
publish_posts
manage_options
edit_usersFor authorization decisions, capability checks are usually more appropriate than testing a particular role name.
For a UX rule such as deciding where a specific type of user should land after login, role-based logic can still be the correct abstraction.
Roles describe groups; capabilities describe permissions
This distinction becomes especially useful on sites with custom roles such as:
content_manager
agency_client
premium_member
support_agentThe role name describes a group or workflow.
A capability such as:
edit_postsdescribes what the user is allowed to do.
Use roles to describe role-specific behaviour.
Use capabilities to enforce permissions.
For the broader permission model, see WordPress user roles and capabilities, explained.
Do not use a redirect as access control
This is one of the most important rules in this guide.
Redirecting a subscriber away from wp-admin does not itself create a security boundary.
Likewise, redirecting a member to:
/member-dashboard/does not make that page private.
A redirect controls navigation.
Authorization controls access.
Those are separate concerns.
A role redirect does not grant permissions
The reverse is also true.
Sending a subscriber to:
/wp-admin/edit.phpdoes not grant permission to edit posts.
WordPress still evaluates that user’s capabilities when the administration screen loads.
The redirect destination and the authorization system remain separate layers.
Respect explicitly requested redirect destinations when appropriate
WordPress login URLs can include a destination through the redirect_to parameter.
For example:
wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Faccount%2Forders%2FThis can happen when somebody attempts to access a protected page before authenticating.
If your role-based redirect always overrides the requested destination, the user may log in successfully and then be sent somewhere unrelated.
A typical broken flow looks like:
User opens protected order
↓
WordPress asks user to log in
↓
User logs in
↓
Role redirect ignores requested order
↓
User lands on generic account pageWhether your implementation should preserve $requested_redirect_to depends on the site’s workflow.
Give requested destinations priority when useful
One possible strategy is:
add_filter(
'login_redirect',
function (
$redirect_to,
$requested_redirect_to,
$user
) {
if (
! $user instanceof WP_User
) {
return $redirect_to;
}
if (
! empty(
$requested_redirect_to
)
) {
return $requested_redirect_to;
}
if (
in_array(
'subscriber',
(array) $user->roles,
true
)
) {
return home_url(
'/account/'
);
}
return $redirect_to;
},
10,
3
);Now an explicitly requested destination takes priority, while the role redirect acts as a fallback.
This is not automatically the right behaviour for every site. The requested destination still needs to be appropriate for the authenticated user.
Do not blindly trust redirect destinations
A requested redirect value should not become a way to send authenticated users to arbitrary external destinations.
WordPress login handling performs its own redirect validation, but when you build custom redirect flows elsewhere, use WordPress’s redirect-validation helpers rather than treating request values as trusted URLs.
For manual redirect logic, see the official wp_safe_redirect() documentation.
Inside login_redirect, you normally return the chosen destination and let WordPress continue its authentication flow.
Do not call wp_redirect() inside login_redirect unnecessarily
This is unnecessary:
add_filter(
'login_redirect',
function (
$redirect_to,
$requested_redirect_to,
$user
) {
wp_redirect(
home_url(
'/account/'
)
);
exit;
},
10,
3
);The filter expects your callback to return a destination URL.
Use:
return home_url(
'/account/'
);and allow WordPress to complete the normal login process.
Avoid redirect loops
A redirect rule can accidentally send a user into a loop.
For example:
login
↓
/member-area/
↓
page requires another authentication condition
↓
wp-login.php
↓
/member-area/
↓
repeatCommon causes include:
- redirecting to a page the user cannot access;
- redirecting to a page that immediately sends the user back to login;
- conflicting plugins;
- role rules overlapping with membership rules;
- incorrect authentication checks;
- redirecting users away from pages needed to complete authentication.
Always test the final destination while logged in as the actual role being configured.
Do not test only as an administrator
Administrator accounts can access almost everything, which makes them poor test subjects for role-specific workflows.
Create or use representative test accounts for:
- Administrator;
- Editor;
- Author;
- Subscriber;
- each important custom role.
Then test the login process in a private browser window.
This gives you the real authentication flow without an existing Administrator session masking permission and redirect problems.
Redirect custom WordPress roles
Custom roles can be handled exactly like built-in roles.
Suppose your site has:
premium_memberYou can redirect it with:
if (
in_array(
'premium_member',
(array) $user->roles,
true
)
) {
return home_url(
'/premium-dashboard/'
);
}The important value is the role key, not necessarily the human-readable label.
The WordPress interface might display:
Premium Memberwhile the actual role key is:
premium_memberHow WordPress roles fit into this
WordPress includes a role and capability system that groups permissions and assigns them to users.
The standard roles commonly include:
- Administrator;
- Editor;
- Author;
- Contributor;
- Subscriber.
Plugins and custom code can register additional roles.
Role-based redirect systems should therefore avoid assuming that every WordPress installation contains only the built-in role set.
Create or modify roles separately from redirect rules
If the site’s user model requires custom roles, define those roles and permissions independently from the login destination.
TheOneWP’s Role Manager can be used to manage role definitions and capabilities, while Redirect After Login handles the separate question of where those users should land after authentication.
The responsibilities are different:
Role Manager
→ defines role and permissions
Redirect After Login
→ defines post-login destinationThis separation helps keep the site’s access model understandable.
Do not create a custom role only to get a redirect
A redirect requirement alone does not always justify creating another WordPress role.
If two groups have identical permissions but need different navigation flows, consider whether another user attribute or application-level distinction would be more appropriate.
Roles should primarily represent meaningful permission or workflow groups rather than becoming labels created solely because a redirect rule needed another condition.
If you do need a new role, see Creating a custom WordPress role safely before modifying the site’s permission model.
Redirect users after logout separately
Login and logout redirects are related, but they are separate workflows.
You may want:
Administrator login
→ /wp-admin/
Administrator logout
→ /
Member login
→ /member-dashboard/
Member logout
→ /goodbye/The logout destination should be configured separately rather than assuming the login redirect controls both directions.
When a configurable redirect system is better than PHP
Custom code is appropriate when the rules are stable, version-controlled and maintained by developers.
A configurable interface is often more useful when:
- administrators need to change destinations;
- the site contains several custom roles;
- redirect rules change with business workflows;
- developers should not be required for small destination changes;
- multi-role priority needs to remain visible and documented.
TheOneWP’s Redirect After Login module is designed for this use case.
It turns the role-to-destination relationship into configuration rather than requiring every change to become a PHP deployment.
Should login redirect logic live in functions.php?
It can, but that does not always make it the best location.
A redirect rule placed inside the active theme’s functions.php disappears when the theme changes.
If the behaviour belongs to the site’s application logic rather than its presentation, a small custom plugin is usually a cleaner location.
For example:
wp-content/
└── plugins/
└── site-login-rules/
└── site-login-rules.phpwith:
<?php
/**
* Plugin Name: Site Login Rules
*/
defined(
'ABSPATH'
) || exit;
add_filter(
'login_redirect',
function (
$redirect_to,
$requested_redirect_to,
$user
) {
if (
! $user instanceof WP_User
) {
return $redirect_to;
}
if (
in_array(
'subscriber',
(array) $user->roles,
true
)
) {
return home_url(
'/account/'
);
}
return $redirect_to;
},
10,
3
);Now the login behaviour remains independent of the active theme.
Do not interfere with authentication recovery flows
Login systems may interact with:
- password resets;
- two-factor authentication;
- custom login endpoints;
- membership plugins;
- WooCommerce account flows;
- single sign-on providers;
- security plugins.
A role redirect should apply after successful authentication without interfering with the steps required to authenticate successfully.
This is another reason to keep redirect logic focused on destination selection rather than trying to make it responsible for the entire login system.
Common mistakes when redirecting WordPress users by role
1. Hardcoding the full domain
Avoid:
return 'https://example.com/account/';when this is sufficient:
return home_url(
'/account/'
);2. Using the current-user global inside login_redirect
Use the $user object passed directly to the filter.
3. Forgetting custom roles
Do not assume every account must use one of WordPress’s built-in role names.
4. Ignoring multi-role accounts
Define which matching role takes priority if a user has more than one configured role.
5. Redirecting to inaccessible pages
The destination should make sense for the user’s actual permissions.
6. Using redirects as security
A redirect changes where the browser goes. It does not replace authorization.
7. Ignoring requested destinations
Blindly overriding redirect_to can send users away from the resource they were originally trying to access.
8. Putting permanent application logic in a theme
If the redirect belongs to site behaviour rather than presentation, a plugin is usually a better home.
9. Creating redirect loops
Test every configured destination using the actual target role.
10. Creating roles purely as redirect labels
Keep the site’s role model tied to meaningful user groups and permissions rather than allowing navigation rules to distort the authorization structure.
A practical WordPress role redirect pattern
For a typical site, a clean implementation might be:
add_filter(
'login_redirect',
function (
$redirect_to,
$requested_redirect_to,
$user
) {
if (
! $user instanceof WP_User
) {
return $redirect_to;
}
/*
* Preserve an explicitly requested destination.
*/
if (
! empty(
$requested_redirect_to
)
) {
return $requested_redirect_to;
}
/*
* Role destinations ordered by priority.
*/
$destinations = [
'administrator' =>
admin_url(),
'editor' =>
admin_url(
'edit.php'
),
'author' =>
admin_url(
'post-new.php'
),
'subscriber' =>
home_url(
'/account/'
),
];
foreach (
$destinations
as $role => $destination
) {
if (
in_array(
$role,
(array) $user->roles,
true
)
) {
return $destination;
}
}
return $redirect_to;
},
10,
3
);This pattern provides:
- validation of the authenticated user object;
- support for explicitly requested destinations;
- role priority;
- WordPress URL helpers;
- a fallback to the normal WordPress destination.
Testing your role-based redirects
Before deploying redirect rules to production, test each configured role.
A useful test sequence is:
- Create a representative user account.
- Assign the target role.
- Open a private browser window.
- Visit the normal login page.
- Authenticate with the test account.
- Confirm the final destination.
- Verify that the destination is actually accessible.
- Test a login containing a
redirect_toparameter. - Test accounts with multiple roles if your site allows them.
- Test logout and re-login separately.
This catches problems that can remain invisible when every test is performed through an Administrator session.
Using Redirect After Login in TheOneWP
TheOneWP’s Redirect After Login module is designed for sites where these rules should be managed as WordPress configuration rather than hardcoded PHP.
The manual implementation and the configurable implementation solve the same underlying problem:
User authenticates
↓
WordPress identifies the user
↓
role-based rule is resolved
↓
appropriate destination is selected
↓
normal permissions still applyThe module is particularly useful when redirect rules need to remain visible to site administrators or change independently from theme and plugin deployments.
It does not replace the WordPress role and capability system.
It simply controls the navigation step that follows successful authentication.
Role redirects should improve workflow, not replace permissions
Redirecting users by role in WordPress is ultimately a workflow and user-experience decision.
It allows each type of user to arrive where they are most likely to continue working:
Administrator
→ dashboard
Editor
→ content list
Author
→ new post
Customer
→ account
Member
→ private frontend areaThe cleanest custom implementation uses WordPress’s login_redirect filter, works with the authenticated WP_User object, defines predictable behaviour for multiple roles and preserves WordPress’s normal destination when no custom rule applies.
When those destinations need to be managed without editing PHP, TheOneWP’s Redirect After Login module provides the same role-based concept through configuration.
Most importantly, keep redirects separate from authorization.
A role redirect decides where a user lands.
WordPress roles and capabilities decide what that user is actually allowed to do.
For the underlying APIs, refer to the official WordPress login_redirect documentation and the WordPress Roles and Capabilities documentation.