Sites such as gmail.com and outlook.com both redirect away from their original 'pretty' URLs, only to replace it by an unreadable and unpredictable one. Outlook seems to actively add a server to the URL:


So it might be for load balancing purposes. Gmail.com, however, doesn't, but it redirects to mail.google.com.


Why do these site not just use their clean domain names, the ones users use to reach the website, when this would improve usability by:

  • Allowing the user to see at which site he/she is in a glimpse
  • Increase loading speed by not forcing an uncached 302 redirect
  • 2
    Outlook.com is probably a bad example; they're still half on old Live.com infrastructure. No idea if/how much they'll change, but they've been criticized for the live.com URLs/old Live.com design found in certain parts of the new Outlook.
    – Ben Brocka
    Aug 9, 2012 at 18:52
  • 5
    The examples are one-task applications. I don't need the URL to tell me I'm logged into Gmail. I also can't 'deep link' via a Gmail URL anyways, so it's not useful for that either.
    – DA01
    Aug 9, 2012 at 21:17

5 Answers 5


There are various reasons for this, amongst them:

  • Bookmarks - I love the ability to drag and drop the browser address icon to my desktop to mark an important email.
  • History - Looking through your history can be the quickest way to find an email you read half an hour ago. You need an encoded url to achieve this.
  • App versioning - when rolling out a new version of an app (particularly if not all users are upgraded at once), a sub folder within the domain can be the most logical way to go about it (consider a guest user and a page on the old system for which you want to generate 404 in the new one).
  • Referrals - If, for example, I get a percentage from each purchase that was made through me referring to Amazon; Amazon have to provide a url that I can copy and paste in a forum. You must have an encoded url for this.
  • Cookie Disabled Browsing - to allow sites to work when cookies are disabled, the easiest method is to include an encrypted session id in the url.
  • State - generally speaking, when the user session expires, a redirection to a password page will occur, but the user is expecting to return to the same screen before she was redirected. There are, however, other strategies to achieve this (albeit slightly more complicated from a programmer point of view).
  • .htaccess - many site admins are very accustomed to this powerful tool, but its real power can only be realised if there are descriptive urls.

Google's URL is made of:

[Mail sub domain][App][Multiaccount ID][folder]


  • [mail.google.com] means you are using the mail service of google.
  • [App] is currently /mail, but you could also get there /a in the past for google apps.
  • [Multiaccount ID] ie /u/0 facilitates the ability to log in with more than one email.
  • [Folder] is the folder you are on, whether #inbox, #starred, etc. So you can target (or bookmark) a specific folder/label.

With Gmail, it also counts that google uses a one-login-for-any-google-site system. For that, cookies needs to be accessed, but they are only available for the exact domain which has set it. That's why any google product will redirect you to a nother shared url which stores the login details, and than redirect back to the app.

Problems with clear URL

Personally, I'm facing an opposite problem - I have a system that only uses the clean domain name and the rest is updated via ajax. The problem with this is that some users want to bookmark a page they access frequently - and can't.

Also, and from bitter experience, products like google analytics are useless without descriptive urls.

This is to an extent that on AJAX based sites that can work with only one clean url, the programmer is likely to search for the ability to update the address bar url without reloading the page, same like how GitHub works.

  • I'd always wondered what all that gunk is in the gmail url, very enlightening!
    – fredley
    Aug 15, 2012 at 12:39
  • 2
    For the ajax/url problem, you want to have a look at the -new-javascript history api.
    – Lg102
    Aug 15, 2012 at 19:31

I have always thought that 302/301 redirects not to be painful for big names like Google or Microsoft. Some browsers even cache these responses so it is virtually no time penalty.

From my experience optimizing efforts for larger sites would be focused on compressing resources, merging them to avoid multiple requests, lazy loading, etc.

As for glimpses at URLs to figure out where you are, I always thought favicons were made for this. I would say putting a lot of information onto a 16px16 square has been perfected. Just take a look at Smashing Magazine's article about good favicons.

On devices where URLs can make or break UX, like phones or tablets, they are often hidden altogether replaced by a large icon, or put in the application store.

  • 2
    I thought the OP's question was actually 'why' (do they do it, in the first place).
    – Kris
    Aug 11, 2012 at 13:56

I can't answer for outlook, but I suppose Google believes that mail.google.com could e.g. show the user he is on a google page and using a google product. Of course you know that Gmail means google mail, however the word Google is not contained in Gmail.

Furthermore, it is consistency, meaning you have maps.google.com, translate.google.com, ... and mail.google.com. So, if you want to go to your calendar, you do not have to think very long, but you'll try probably calendar.google.com -> and there you are.

As for the URl, technically Google spreads its services over a vast number of ip addresses (domains) and servers they own, you will never recognize this as a user. They load and save content in the background and they do not have to change the URl in the browser for that.

  • The product.google.com pattern isn't always there, though: http://www.google.com/analytics/
    – Lg102
    Aug 15, 2012 at 15:00

That is a tough question, I think the answer is probably the result of some committee design and data/site architect process in which way too many stakeholders were asked what their opinions was. The end result was a messy standard that does the job (sort of). Imagine the politics inside Google or Microsoft.

Below are some reasons why you might want to have a crazy url (or have variables in the string)

  • Security, I'm not sure how this works, but if you google ?shva= you will find that this means 'should have valid authentication'. I know you don't have that on yours, but it is on my gmail url*.
  • Javascript
  • Useful for linking to that exact page. Sometimes you will see ?page=4
  • Saving variables in the url for testing or otherwise. From ?id=64855&owa=1 I know that your id is 64855 and and your are using Outlook Web Access.
  • Analytics (tracking codes, etc)
  • A way to deal with caching, if your render a page with /image.jpg?x={random_number}, browsers won't cache the file because they think it is a different file everytime it load
  • An easy way to report on A/B testing (totally guessing here, I have never done A/B testing)

You should try messing around with those _GET variables and see what happens.


I can't speak for Google or Microsoft but, in many cases, the people involved don't care very much about meaningful urls or, more often, believe that their users don't care. Sometimes, it's not that they decided to have an ugly, unreadable url; it's that they didn't give the matter any thought at all.

Two practical reasons for redirecting though:

  1. Many web development frameworks (notably Microsoft's ASP.NET) make it very hard to have readable URLs. It takes a lot of effort to do the right thing. Sometimes the least bad thing is to redirect a nice url to an ugly one.
  2. Cookies can't be shared across domains. I'd guess that google redirects everything to *.google.com so that cookies will still work across properties.

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.