Let's say a user successfully logs into my web application. At this point there is no need for the “Sign up” and “Log in” pages to be visible anymore in the navigation, but what if they still try to access those pages by just typing the URL?

At the moment I am just redirecting everyone that's logged in, and trying to visit those pages, to the homepage (or the landing page they would usually see after a successful login) without further notice.

What would be a good way of handling requests to pages which logged in users would have no reason to visit from a UX point of view?

  • 1
    What I do is tell them "You're already logged in, go back to <homepage>?" where <homepage> is a link to the homepage. Obviously they want to get there so I just want to let them know they don't need to be there, and give them an easy-out to get where they should be.
    – Seiyria
    Commented May 13, 2014 at 15:17
  • Does your website impose account uniqueness? If not it is reasonable for a logged in user to create a new account... if you find it akward anyway just tell him: log out before creating a new account.
    – Bakuriu
    Commented May 13, 2014 at 17:09

5 Answers 5


If users find themselves trying to get to the Log In and Sign Up page by typing the URL in manually than they really must want to get there for some reason. I would first make sure that you have a log out button somewhere readily available on the app so that if they did log out they could proceed to that page. However, I think that you are doing it correctly in re-directing currently logged in users to the homepage if they try to return to the Log in and Sign up page. I'm sure the log in and sign up page really have nothing else to offer except the function they are designed for, so you're thinking ahead and showing the user where they in fact want to go instead. If they really have a desire to go to those pages, then allow them to log out and re-log in. Just an idea, hope it helps.

  • 4
    Good answer imho. I like to add that it's not necessarily for a reason users go to the login page. It could be the browser auto-completing the URL the user is typing, and this could very well be the login. So, statistics don't necessarily tell the whole story.
    – Ruudt
    Commented May 13, 2014 at 15:36

You could create an alternative design for those pages for logged-in users.

The Log In page could say “You’re already logged in!”, and then offer useful options for what to do next (e.g. go to the home page, log out).

The Sign Up page might offer a link to the page where they can edit their details.

As mentioned elsewhere, this is (probably) an edge case, so the current experience probably isn’t hurting you any. It would be interesting to find out how many users visit the Sign Up or Log In page when already logged in, if possible.


If the user is typing in the "Log in" or "Sign up" URL I'd take them there (principle of least astonishment), though a "Log out" button on each page might be nice.

If the user is getting to these pages because of URL completion or bookmarks then I'd try to design the URLs to minimise that:

  • Have the application entry point be a Homepage (e.g. /) and have that page redirect to /login (with a link to /signup) if the user is not yet logged in.
  • Once the user has logged in or signed up make sure the user is redirected back to the Homepage (e.g. /) and not forwarded to the Homepage[1].
  • The /login or /signup pages should never be advertised or linked to directly from outside the application, so the user never has to type in, copy and paste, memorise or bookmark these URLs.

[1] Sometimes you see a web application perform an internal forward to the Homepage after login which results in the Homepage being displayed but the URL still showing /login. The user thinks they're bookmarking the homepage but they're really bookmarking the login page.


The logout link should be worded like "log out and sign in as a different user" since that is what they probably want to do if they are accessing the login page.

  • 1
    Welcome to UX.SE -- the best answers that get the most votes and provide the most value are usually supported by some justification and/or external references to research or examples that support your argument. Can you elaborate on why your approach is correct? Commented May 13, 2014 at 16:46
  • I think this should be a comment to my question, rather then an answer. Commented May 13, 2014 at 16:52

I believe it's common that the root path of your web application (like http://www.example.com) contains the option to log in, or sign up, if you're not already logged in, and the homepage if you are logged in. This means that there is no log in page to reach unless you log out first, regardless of what url you try to type.

  • That doesn't really make sense. For instance, in IIS, the root of your application is controlled by the defaultDocument node of the Web.config. Your default document could be Index.htm, Index.html, Default.asp, Default.aspx, Login.aspx, Home.aspx, Main.aspx, etc. That said, after the user logs in ... they can still get to the default document page by nav menu or manually editing the URL. I believe the OP wants to handle that scenario, basically what to do when someone hits those default document / login pages after they've already been logged in. Commented May 13, 2014 at 20:12
  • What I'm referring to is the behaviour you can see on several sites including, for example, facebook. Visiting www.facebook.com, you see a login page. After being logged in, typing www.facebook.com in the address field results in you seeing the same page as when you just logged in. You don't need to have a separate url for the login page.
    – Buhb
    Commented May 14, 2014 at 6:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.