Direct answer
Use WooCommerce's login redirect filter and store a page, not a URL. When an account logs in through the WooCommerce account form, check that account's primary role. If it is customer, return the permalink of one published page of this site. For every other role, and for any missing, unpublished, or uncertain target, return the incoming redirect unchanged. Never touch wp-login.php, wp-admin, sessions, or passwords, and test with a real customer account, not your administrator account.
Redirect After Login for WooCommerce follows that page-only boundary. Free sends customer logins to one chosen page. Pro adds one logout page, one after-registration page, and page choices for up to ten roles, each stored as a page ID.
The default landing is My Account, and core has no setting
WooCommerce's official My Account page guide describes the account dashboard as the customer's central page. It is also where the account form sends a successful login, and core exposes no setting for a different landing. A merchant who wants customers on the shop page has three very different options:
| Approach | What it configures | Main failure surface |
|---|---|---|
| One page from a dropdown | A single stored page ID | Correct role check at login time |
| General rule engine | Role rules, precedence chains, URL fields | Mis-ordered rules and staff locked into the wrong flow |
| Pasted code snippet | Theme files | Update drift, syntax errors, no safe fallback |
Public support reports show both the demand and the failure mode. One merchant asked how to send logged-in customers to the shop page instead of the my-account endpoint and was pointed to a paid extension because core has no option. A new store owner reported login-redirect rules failing on a fresh WooCommerce setup. A separate topic asks a redirect plugin to exclude administrator roles from its rules, which shows why customer-only targeting must be the safe default. These reports document individual incidents only. They do not establish that every store or plugin behaves the same way.
Let WooCommerce own authentication
WordPress and WooCommerce verify the password, build the session, and choose the default landing. A helper should only answer where a verified customer goes next. That rule prevents several dangerous shortcuts:
- Do not intercept wp-login.php, wp-admin, or any session handling.
- Do not touch passwords, two-factor, captchas, or the login form.
- Do not accept a typed URL; store a published page ID of this site and derive its permalink.
- Do not redirect administrators, shop managers, or any role the setting does not explicitly cover.
- Do not build conditional rule builders, precedence chains, or per-user rules.
- Do not run cron, queues, or remote checks at login time.
WooCommerce's current class-wc-form-handler.php source shows how the account form processes login. The lesson is ownership: WooCommerce owns authentication; a narrow plugin can own only one redirect answer.
Answer the filter in one lookup
The safe algorithm is short:
- Read the stored page ID.
- Confirm the just-authenticated account's primary role is customer.
- Confirm the page still exists and is published.
- Return its permalink.
- On any doubt, return the incoming redirect unchanged.
Pro follows the same shape with bounded additions: one logout page, one after-registration page, and explicit page choices for up to ten roles. An exact role mapping wins over the customer default, and administrators are never redirected.
Why a page ID and not a URL
A typed URL can be mistyped, can rot when a slug changes, and can point anywhere on the internet. A stored page ID can only refer to a published page of this site, and its permalink is derived fresh at login time. If the page is deleted or drafted, the setting fails closed and the native landing returns. The merchant never sees a URL field, and the store never carries an open redirect.
Pick one page and prove it
- Create or choose the published page customers should land on, such as the shop page.
- Open WooCommerce > Redirect After Login.
- Pick that page from the After login send customers to dropdown and save.
- Log in as a test customer through the account page.
- Confirm the login lands on the chosen page.
- Log in as an administrator and confirm native behavior is unchanged.
- Unpublish the target page, repeat the customer login, and confirm the native My Account landing returns.
Use a real customer-role account for the test. An administrator account proves nothing about the customer path, because administrators are never redirected.
Add Pro mappings without a rule engine
Pro keeps the same page-ID model and adds three bounded choices: one logout landing, one after-registration page, and page picks for up to ten roles. Precedence is one sentence long: an exact role mapping wins over the customer default, and administrators are never redirected. There is no condition builder, no chain to order, and no per-user rule. If Pro or its license check is unavailable, the valid Free customer redirect keeps working with no fatal error and no public remote request.
Diagnose a wrong landing
| Symptom | Check first | Safe expected result |
|---|---|---|
| Customer still lands on My Account | Saved page ID, published state, account form versus wp-login.php | Account-form customer login lands on the chosen page |
| Administrator was redirected | Never by design; inspect any other redirect plugin | Staff logins follow native behavior |
| Two plugins fight | Which filters run on the same hook | One bounded answer per login |
| Landing broke after a page edit | Page deleted, drafted, or trashed | Native landing returns with no error |
| Redirect loop | A target page that itself forces a login | Filter fails closed on uncertain state |
| A mapped role stays native | Whether the account's primary role matches the mapping | Only mapped roles move; the rest stay native |
| Logout landing did not change | Pro logout page setting | Logout follows only the chosen Pro page |
| Registration landing unchanged | Pro after-registration page setting | Registration uses its own separate Pro page |
Start with the stored page and the account's role. A rule engine adds precedence questions on top; one page ID removes them.
Test the negative space
The most important checks prove what did not change:
- Administrator, shop-manager, and unmapped-role logins keep native behavior.
- wp-login.php and wp-admin flows are untouched.
- A deleted or unpublished target returns the native landing with no fatal error.
- A malformed stored value returns the incoming redirect unchanged.
- WooCommerce missing causes no fatal error and registers nothing.
- Pro or the license API unavailable leaves the Free customer redirect working.
- Deactivation removes the filter and restores the native landing immediately.
- A forged or malformed user or redirect value returns the incoming value unchanged.
- Update, downgrade, rollback, and uninstall preserve every page and owned setting.
Release acceptance for this product should run those drills on a real WordPress and WooCommerce installation before any store trusts it with live logins.
Resource boundary
A redirect answer needs one autoloaded option read, one role check on the just-authenticated account, and one permalink lookup, all inside the login request. It needs no cron event, custom table, query, remote request, JavaScript, stylesheet, or idle work. Logins are rare events in a store's traffic; the filter should still do nothing when it has nothing to decide.
Ordinary page views never run the filter at all. Repeat any benchmark on the real hosting stack before a high-traffic launch.
Common mistakes
Redirecting every role
Staff then fight the rule on every login. Cover the customer role first and let managers keep their native flow.
Storing a typed URL
A typo breaks the landing, and an external host breaks trust. A page ID can only point inside this site and fails closed when the page disappears.
Testing with the admin account
The customer path and the staff path are different by design. Test both with separate accounts.
Building a rule stack for one routing need
Every extra rule is a future support ticket. One dropdown solves the common case.
Leaving a campaign landing on after the campaign
A page chosen for a promotion outlives its purpose. Revisit the dropdown when the campaign ends, or point it at a permanent page like the shop.
Market boundary
The official WooCommerce Marketplace lists two current paid login-redirect offers, Redirect After Login, Registration & Logout and Redirect User After Login and Register, each at $29 per year. WordPress.org also has established general-purpose redirect plugins. That proves a paid category exists. It does not prove demand for a one-dropdown product. StoreFixKit Pro is $39 per year for a single site; measure StoreFixKit installs, completed setups, paid conversions, refunds, and support load rather than inheriting a competitor's numbers.
FAQ
Why do customers land on My Account after login?
The account form sends a successful login to the account dashboard by default, and WooCommerce core exposes no setting for a different landing.
Can I send customers to an external URL?
No. The setting stores a published page of this site only, so a target can never point outside the store and never depends on typed text.
What happens if I delete the landing page?
The filter fails closed. Customer logins land on the native My Account page until a new published page is chosen.
Focused plugin
Use the one-job implementation.
Send customer-role logins from the WooCommerce account form to one published page you pick from a dropdown, while administrators, shop managers, wp-login.php, and registration keep native behavior.