Redirect to required page after shopify logout

Our website has two separate landing pages: the default landing page and a custom landing page at /pages/dish-picker. Each landing page has its own account page.

Currently, logging out always redirects users to the default landing page. I want to update this so that users are redirected to /pages/dish-picker instead after logout.

Could anyone provide any solution for this problem??

Not so much with New customer accounts because it goes through Shopify’s own authentication flow instead of /account/logout.

@saurabhv , You can try this:

In Shopify, the logout link usually uses {{ routes.account_logout_url }}, and by default it redirects customers to the homepage after logout.

If you want to redirect users to a specific page (for example: /pages/dish-picker), you can update the logout link in your theme code.

Steps:

  • Go to Online Store > Themes in your Shopify admin

  • Click Edit code on your active theme

  • Search for the logout link (commonly found in header.liquid or account-related snippets)

  • Look for something like:

Log out

  • Replace it with:

Log out

This will try to redirect users to the Dish Picker page after logout.

This may not work in all cases, especially if you’re using the new customer accounts, as return_url is not always supported.

@saurabhv
Hi there, this behavior is expected in Shopify, as it doesn’t natively support custom logout redirects, users are typically returned to the main storefront.

To redirect users to /pages/dish-picker, you have a couple of options:

  1. JavaScript workaround
    Add a script that detects when a user logs out and then redirects:

    if (window.location.pathname === '/account/logout') {
      window.location.href = '/pages/dish-picker';
    }
    
  2. Theme customization
    If your theme includes a customers/logout template, you can modify it to include a redirect.

  3. Apps or middleware
    Some apps can help manage advanced redirects if needed.

This approach ensures users land on your custom experience after logging out.

?? I haven’t actually check this, that’s dumb if shopify left it like that I will have to remember to test it

KLUDGE: if you control the landing page code then just do a redirect there, if iF IF there are detectable traces of the previous context.
Otherwise if no indicators then offer a button for customers to manually use; UX: to avoid creating an annoying situation of false positives or customers wanting to stay on the page they arrive at after logging out of the new-customer-accounts system.
/sighh.


I’d search the .dev forums https://community.shopify.dev/
And raise it as a developer issue as a platform gap over there, if there are no existing threads to join as a quick glane I cant find any for logout just login, so login posts might be what to look over.

That is if the return_to thing doesn’t work like it does with login for some dumb reason
e.g. <a href=“/customer_authentication/login?return_to={{ “/pages/contact” | url_encode }}”>Contact

corporate silo’ing is so absurd.

There’s no native return_to parameter that works on logout for Shopify’s new customer accounts — that parameter only works for login redirects, not logout. The logout flow doesn’t support a redirect destination out of the box.

The practical fix is a small JavaScript snippet in your theme. On the page(s) where you want the custom logout behavior, intercept the logout link click, store a localStorage flag with your target URL, and then on the landing page (homepage) check for that flag and redirect immediately if it’s present. It’s a few lines and handles the gap cleanly without needing an app.

If you’d rather use an app, there are lightweight ones (like Hura Login/Logout Redirect) that handle this with a settings UI — worth it if you’re not comfortable editing theme JS, but honestly the script approach is simpler for a single redirect rule.

@TaskHusky Thanks for the clear explanation — that really helps clarify the limitation around Shopify’s logout flow.

The localStorage approach makes a lot of sense as a workaround, and I appreciate you outlining it so simply. I’ll go ahead and implement the script-based solution for now since it seems lightweight and flexible for our use case.