User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

And when is it better to structure your website's content one way or the other?

Note that I have seen there's already a related question, Domain Strategy From a UX Perspective, which has some great info ... but I don't see that really addressing the difference or applicability between subdomains and subdirectories.

Bonus question: How would we visualize in a sitemap in relation to The subdomain is considered an entirely separate website, right? So would and be at the same level of hierarchy?

share|improve this question
Traditionally and can be two different computers sometimes even at other sides of the world. It's just that the computer at has the adressbook for all subdomains. – Pieter B Jan 16 '14 at 9:03
Can you elaborate on what you mean by this? – in_flight Jan 16 '14 at 13:51
A subdomain is not part of the site, but can and should be considered a different computer/location/server, a subdirectory should be considered part of a site on the same server as other subdirectories on that site. – Pieter B Jan 16 '14 at 14:07
@PieterB What sense does it actually make with cloud and cluster servers? I mean if we both type there is a very low probability that we are on the same server, and the same goes with,,… – Pierre Arlaud Jan 16 '14 at 14:38
@ArlaudPierre Mostly a way of how you view things. and are subdomains of the .com domain. and are in the same way subdomains of domain. – Pieter B Jan 16 '14 at 15:12

I'm not so sure there's a huge difference from a UX stand-point. If anything, it makes it more difficult. Let's say a user is on your site and is at, and he wants to go to your homepage. Users often clear the address bar, so he would click in the address bar, clear the end of the URL, and be left at, which may not be where he wants to be.

Take the alternative you have, the user can quickly get to the homepage by clearing the end of the address, and if they wish to remain is /sub/, they can keep that part there.

Using sub-directories though written like that has more to do with programming rather than UX, take a look at this similar question on StackExchange -

Besides the fact that from a security standpoint it is a bit easier to isolate an app within a subdomain, I will just comment on what I think is the biggest difference between the two.

Pro's for subdomains:

  • You can isolate configuration (for for example apache) per-domain.
  • It will be easier to migrate parts of your application to other machines. Sub-directories won't really give you this flexibility.
  • Instead of having to use a $baseUri variable in every html template, you can just assume the root of the app is always /.


  • It will be much more annoying to quickly setup staging or temporary development environments. For every 'app' you will now need DNS of hosts-file entries and webserver configuration. With subdirectories you could drop the app in a directory, and go!
  • If you do ever have the requirement to deploy your application on a different system where using / is because of some odd policy not possible, some rewriting might be in order.

My advice:

Make sure you can always do both, which will give you the best of both worlds. Every part of your app should have a configurable base uri that is always respected. As long as you make sure you can always go both ways, then who cares what you do? it's just a url and it can always be changed.

Although it can look nicer, it can be worse for the user in terms of UX.

share|improve this answer
The Opera browser has a gesture to make it easy to go "up one level" without having to fiddle with editing the URL: drag up then left. It is very frustrating when content is not structured in a way that makes it easy to access similar/related content if I end up on an orphan page (such as when someone sends me a link to an image). – cimmanon Jan 15 '14 at 15:35
@cimmanon - I never knew about that, sounds like a handy feature. Unfortunately not all of the browsers have that though, so we can't rely on it when developing websites. – Mike Jan 15 '14 at 15:45
One point against separate sub-domains is that you will have problems with CORS when doing AJAX calls between sub-domains. For example, jQuery can call from anywhere in, but browser security will block calls from to, unless the application/server is configured properly and the user is using a modern browser. Even http: vs https: differences are enough to trigger CORS issues! – David Keaveny Jan 16 '14 at 4:29

Thematically, a subdirectory is clearly part of the main site. A subdomain is an area that may be related to the main site, but doesn't really fit as part of the main site. There's no hard rules for what goes where, it is dependant on how content/functionality is being organized and who is doing it.

The benefit of the subdomain approach is that it can be managed as a separate site, using a different technology, front/back end, or configuration. The subdirectory approach is more sensible when the content or functionality is part of a cohesive whole.

share|improve this answer
That's much clearer to me, the way you distilled it, so thank you for that. And as @Mike brought up in his answer, which approach you choose seems to be a question of managing the site, more than anything else. I do think subdomains can be the more usable option over subdirectories, in a certain context ... but that's an exploration for another day. Anyway, so in a sitemap or visualization then, would a subdomain (by nature of the prefix "sub") be below the main domain, or on the same level, as it's managed separately? – in_flight Jan 15 '14 at 18:29
Just a note (not specific to your answer, but I think it's more like a comment than an answer), and say are two sites. Therefore, except you explicitly allows it, you cannot make Ajax calls from one to another - they will be blocked for xss reasons. On the other hand, and are the same site. – aforaudrey Jan 15 '14 at 22:25

Each website should get its own host.

Website? A collection of webpages that share a design (e.g., header and footer) and main navigation.

Host? A registered name, e.g.:,,,

This is not a technical requirement (!), but I think it’s an assumption that many users have (at least those with a basic understanding of URIs). And not only users, but also tools. And breaking with this advice would break those tools for their users. For example:

  • Password managers (as implemented by browsers) typically work on host level, not path level. Different websites may require different kinds of accounts. If you’d had several websites on the same host, password managers may try to fill in login data for the wrong website.
  • JavaScript blockers (like NoScript) typically work on host level, not on path level. Different websites may require different kinds of scripts. If you’d had several websites on the same host, a user could not allow scripts for only one of those sites.
  • Same goes for many other tools like cookie blockers (e.g., Cookie Monster), Referer controllers (e.g., RefControl), etc.
  • One might like to block a specific website with a hosts file (which works on host level, not path level) or similar mechanisms. If you’d had several websites on the same host, all of them would be blocked.

Your "bonus question" about sitemaps: Typically, a sitemap contains all URLs of a (= a single) website. So each website should get its own sitemap. Of course you could create a sitemap listing all websites (and their pages) of your company/etc., for example:

Our sites

share|improve this answer
I highly appreciate you answering the "bonus question"! – in_flight Jan 16 '14 at 16:48

As per my experience and understanding, the decision of structuring content on a website depends on the nature of it. For example, if I were to start a website on the product called "Faadu", my approach would be:

  • For the product homepage, I would try to own the domain
  • For the blog page, I would pick a subdomain like since a blog is a separate entity than the product page.
  • To put content on the a special feature, for instance, the AI feature that my product offers, I would choose Alternatively, if I would like to blog about it, I would use I would not use, since, it's a part of the product and not a separate entity.

In terms of UX, I agree with @Mike that it wouldn't differ or matter much, unless the user tries to predict the parent URI. Hope this helps.

share|improve this answer

From a UX perspective is preferable to .

It is worth noting that '' is a subdomain(primary) of ''. It is an indicator to the user that what follows is a domain name.

I doubt many users understand the difference between URLs, TLDs, subdomains and directories but they will place a greater level of subconscious trust it the pattern off 'www' . 'domain' . 'com' . This is a pattern they will recognise. (I do not have any data for this!)

Many big companies do many different things and should not be heralded as examples of best(or worst) practice. A whole heap of companies entirely ignore the UX aspect of their URL and look at the issue from a Search Engine Optimisation point of view.

The primary reason for the choosing between directory and subdomain will be technical/structural depending on how you want you network to run and operated.

There is also the issue of email and the sender/originator but I do not think the original question is questioning this.

share|improve this answer
A project I worked on a couple years ago gave clients a subdomain to access their content and theme it. We setup for them, and they told all of their users that their website was So yeah, users don't get subdomains (or that www is a subdomain). – cimmanon Jan 15 '14 at 21:11
@cimmanon lol! I had the same thing happen. I told them was the site they could use until theirs was up (DNS had to propagate, and theirs was an add-on to mine). They advertised it on Facebook as – Mike Jan 15 '14 at 22:50
@Mike you mean you said and they understood it with www :P Interesting typo, are you a normal user too? – Pierre Arlaud Jan 16 '14 at 14:42
@ArlaudPierre Nope, they advertised it as the right URL, but it looked so unprofessional because of the – Mike Jan 16 '14 at 15:42

In all honesty, from a front-end UX perspective - I think it's a marketing thing. Here's what I mean. redirects to - but, Gmail is easier to market and remember for a user.

Both and redirect to redirects to

From a server perspective, subdomains are a good way to isolate various configurations easily (and can actually aid in the user experience):

Apple markets the "Developer" program, which is connected to "iTunes Connect". And developers can create marketing for the iAd network using the "iAd Workdbench". And, last but not least on the list, if a user types in - (s)he will be redirected to the subdomain.

And, there is always:,, etc. - basically every exchange in the stack exchange network except stack overflow, which has its own domain.

There is also the argument that it might be easier for a user to hit the period (ring finger and used more often - muscle-memory) versus the forward-slash (pinky and used less often). Also, visually, subdomains are better from a designer perspective than the slash.

And, there is the argument against having www. as part of the root domain.

To sum up. The end domain name is pretty irrelevant from a user's perspective, in my experience. Instead, the entry domain is the part you want to care about. is a great entry domain - short, sweet, and marketable - but that's now where you go as a user. as an entry will be a good one when the marketing picks up - then using the exchange listing - then bookmarking that specific exchange (at which point the domain becomes URL structure becomes moot). Domains aren't necessarily created to house the website - they may just be to help a user get to the right place (,, for example).

share|improve this answer
I agree there's a marketing/branding element to it, but it'd be interesting to do some quantitative research into how users think about/perceive these domain differences ... and see whether it really is irrelevant. I know in higher education, for an example, many universities will have their main domain, and then break out entities like or with subdomains. I wonder if this makes for a better user experience by fostering a sense of digital place and modularizing what would otherwise be a massive information architecture. – in_flight Jan 16 '14 at 13:58

protected by Community Oct 15 '14 at 13:06

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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