How to Redirect Users to a Custom Page on Login in WordPress

By default, WordPress sends everyone to the admin dashboard after login — which makes perfect sense for administrators but is a terrible experience for subscribers, customers, or members. Imagine running a membership site where every logged-in user lands on a wp-admin screen they have no reason to be on. That’s friction, and friction costs conversions.

Role-based login redirects let you craft a tailored post-login experience. A subscriber can land on their “My Account” page, a contributor can go straight to the post editor, and an administrator gets the dashboard they expect. This isn’t just a UX nicety — it’s a core element of any membership, LMS, or client portal built on WordPress.

Over eight years building custom WordPress sites, I’ve seen clients lose customers because logged-in users couldn’t figure out where to go. A well-configured login redirect solves this instantly and requires only a few lines of PHP.

The cleanest, most performant way to redirect users after login is with the login_redirect WordPress filter. This hook fires immediately after a successful authentication and before WordPress sends the HTTP redirect header, giving you full control over the destination URL.

Add the following code to your child theme’s functions.php file or to a custom site-specific plugin. Never add it to a parent theme — you’ll lose your changes on the next theme update.

/**
 * Redirect users to custom pages after login based on role.
 *
 * @param string  $redirect_to           The default redirect URL.
 * @param string  $requested_redirect_to The URL the user requested.
 * @param WP_User $user                  The authenticated user object.
 * @return string The URL to redirect to.
 */
function wpdev_login_redirect( $redirect_to, $requested_redirect_to, $user ) {
    // Bail early if $user is not a WP_User object (e.g., on error).
    if ( ! isset( $user->roles ) || ! is_array( $user->roles ) ) {
        return $redirect_to;
    }

    // Redirect administrators to the dashboard.
    if ( in_array( 'administrator', $user->roles ) ) {
        return admin_url();
    }

    // Redirect editors to the post list.
    if ( in_array( 'editor', $user->roles ) ) {
        return admin_url( 'edit.php' );
    }

    // Redirect subscribers and customers to a custom account page.
    if ( in_array( 'subscriber', $user->roles ) ||
         in_array( 'customer', $user->roles ) ) {
        return home_url( '/my-account/' );
    }

    // Default fallback: return the original redirect URL.
    return $redirect_to;
}
add_filter( 'login_redirect', 'wpdev_login_redirect', 10, 3 );

This code is clean and dependency-free. The in_array() checks make it easy to add more roles at any time. The fallback ensures backward compatibility — if a user has a role you haven’t explicitly handled, WordPress uses its own default logic.

If you prefer a no-code solution or need to manage redirects from the WordPress admin without touching files, several reliable plugins handle this well. My top recommendations in 2026 are LoginWP (formerly Peter’s Login Redirect) and Redirect After Login. Both have been consistently maintained and don’t bloat your site.

LoginWP lets you set redirect rules per role, per user, and even per specific page — all from a settings panel. It also handles redirect after registration, password reset, and logout. For sites where a non-technical client needs to adjust redirects without developer access, this is the pragmatic choice.

That said, I always prefer the code approach for projects where I control deployment. Plugins add dependency overhead, and a filter hook is arguably more transparent and auditable than a plugin’s database-stored rules.

The code example above already demonstrates role-based redirects, but let’s dig into the logic more deeply. WordPress stores user roles as an array in $user->roles. A user can technically have multiple roles, so using in_array() is the correct check rather than comparing directly with $user->roles[0].

Here’s a practical mapping I use for membership and LMS sites:

1. Administrator → /wp-admin/ (default dashboard)
2. Editor / Author / Contributor → /wp-admin/ edit.php (post management)
3. Subscriber / Member → /dashboard/ or /my-account/
4. WooCommerce Customer → /my-account/ (WooCommerce account page)
5. Custom “Student” Role (LearnDash) → /my-courses/

If you’re using a membership plugin like MemberPress or LearnDash, those plugins often create their own custom roles. Just inspect $user->roles in a test environment to confirm the exact role slug before writing your conditionals.

Login redirects and registration redirects are handled by different hooks. The login_redirect filter only fires when an existing user logs in. If you want to redirect new users immediately after they register, you need to hook into registration_redirect or use the user_register action combined with a custom redirect.

For WooCommerce sites, the registration flow is often embedded in the checkout or the “My Account” page, and WooCommerce has its own redirect logic via woocommerce_registration_redirect. Always test both flows separately — I’ve seen sites where the login redirect worked perfectly but new registrations still landed on the wrong page because a different hook was needed.

For a typical WordPress membership site, handling both hooks is best practice. Add the login_redirect filter for returning users and registration_redirect for new sign-ups, pointing both to a welcome or onboarding page.

The most common mistake I see is adding the redirect code to a parent theme’s functions.php. When the theme updates, the code is overwritten. Always use a child theme or, better yet, a must-use plugin stored in /wp-content/mu-plugins/ for critical functionality like this.

Another frequent issue is forgetting to handle the case where $user is a WP_Error object rather than a WP_User. This happens when a login attempt fails. The guard clause at the top of the function — checking isset( $user->roles ) — prevents a fatal error in that scenario.

Finally, watch out for redirect loops. If you redirect subscribers to /my-account/ but that page requires login to view and redirects back to /login/, you’ll create an infinite loop. Always test redirect targets as a logged-in user in an incognito window before deploying.