Ask HN: Subdomains versus Directories?

There are security implications to this decision.

JavaScript uses a security model called the same-origin policy. There are differences in the implementation between different browsers but here's the gist: JS may modify the DOM if-and-only-if the domain containing the script shares the domain of the DOM. Loosely, the check is done by comparing document.domain strings. If the strings match, everything is kosher.

You can truncate document.domain by lopping off period delimited prefixes. Even if you lop foo.com down to the TLDs, you won't be able to do the same trick and cut bar.com down and get scripts to run in the same context.

If you're hosting content on blog.example.com and example.com, an attack on blog.example.com could truncate the document.domain down to 'example.com' and execute malicious script on the primary domain.

I would recommend using blog.example.com and www.example.com, but never example.com.

I like to think of it this way: left of the "/" is for systems/operations, right of the "/" is for code/content/development. So if you're going to put something on a separate subdomain it should be for mechanical reasons, such as using a different cdn or a different hosting stack. Think of it from a workflow perspective. To add /blog to your site goes through your existing code publishing workflow. To add blog.domain.com to your site means involving server configuration or a third party web interface, etc.

pro on subdomain because:

* a lot of blogging apps/readers etc. look for feeds at standard endpoint urls such as /feed.xml /xmlrpc etc. all the plugin urls etc. will also be at the standard urls

* you can set auth cookies for the subdomain so you can isolate logged in commenters etc. (you can have path=/blog on cookies but most blogging apps don't support it).

* sep analytics (also possible on sub-dirs but you can visitor track and x-ref between domains).

pro on folder because:

* SEO counts to your main domain (see : http://www.christonium.com/SearchEngineMarketing/subdomain-d...)

Subdomains are the way to go.

After 5 years of trying to house web applications within subdirectories of subdirectories of sites for our university, we've grown tired of the endless configuration nightmares that many apps require. Sticking a new folder of static pages somewhere is trivial, but configuring Rails apps, forums, third party services, and other things we purchase to work properly at the subdirectory level is so much more painful. It often involves reverse proxy settings and content rewriting, which doesn't always play nice if the directory structure is uneven.

So now we have subdomains. We have a wildcard set up that forwards to our app servers, we have scripts that create the vhost file and tap Apache to restart, and no proxies need to be modified to allow /foo/bar/baz to go to server1.foo.com.

When I managed a handful of apps, subfolders were nice Everything under www was great for SEO and everything else. But the fact is that users don't care about URLs, our sites on subdomains get found by search engines because we link to them, and if we need to move foobarapp to another more powerful box (or to the cloud) it's WAY easier.

Directory please, because it makes the URLs nice and hackable. I can hit Cmd+L, right, alt-backspace to remove the 'blog' part of the URL instead of screwing around trying to select the subdomain (and dot!) to get back to your main site.

I hate this even more for sites like GitHub pages, which use http://name.github.com/project/ for the pages and http://github.com/name/project/ for the repo. Trying to rewrite the URL to get from one to the other is an exercise in fiddly copypasting.

A big pro for using a subdomain is it's easier to host it on a separate server, or even on Tumblr or the like (by pointing the record to them). This could be key if you have a webapp with a custom server configurarion running on your main domain. It could also mean your blog stays up if your main site goes down - ideal for status updates, etc.

I prefer the subdomain method. It keeps things separate. In our case it allows me to run our custom CMS for our website and separate Wordpress instance for our blog...no interdependencies of any type.

YMMV.

I just moved all my users over from directories to subdomains for my project AppRabbit and I think it's done a lot in terms of ease of use. They used to have to type apps.apprabbit.com/myapp/ but now they can just go to myapp.apprabbit.com. It's the same thing, but different, and it just feels much better. Setup was a little tricky to figure out, but in the end it's pretty much the same thing, as far as the app code is concerned, apache handles all the heavy lifting. It actually made things easier on a few fronts because before I had to inject the user's app name into the path for things like redirecting to the login page, etc, so this change made things like that easier.

One thing that I don't get now, or at least I'll have to work for it, is sharding my setup, when I get to that point. Before I figured I could just move people to app1.apprabbit.com, app2.apprabbit.com, etc, but now I will have to handle the redirecting in my configs when I get to the point where I need to split things out for performance. On the other hand, this makes it that much easier to move a big customer off of a shared host and give them their own server without changing anything public facing.

In the end it definitely has it's perks and drawbacks, but I wanted subdomains, and so far I haven't had any problems with them.

From my viewpoint it comes down to manageability. I've got scripts that make it take < 2 minutes to set up a new domain or subdomain on my server, and each one of those is in it's own directory so it can be copied, backed up, or moved to another server easily. If, on the other hand, you're using somebody else's hosting system, subdomains could be a big pain.

For one project of mine, I'm keeping my images on a separate domain so I can switch to a different system for hosting images... For instance, host them on a single-threaded web server or move them to S3/CloudFront.

Similarly, if a project involves different technology than the main site or if it may involve different technology in the future, that's a good reason for a subdomain. If you might want to host it differently, that's a good reason for a subdomain.

I don't know what to tell you about S.E.O.; a few years ago there were some people who made subdomains by the hundred because they thought they got S.E.O. advantages from that -- S.E.'s like keywords in the domain. My understanding is that keywords in subdomains used to be unreasonably powerful, people exploited them, and now there's not so great. S.E.'s also appear to have depth limits on the crawls they do a single host, so multiple hosts might also be a way to get more pages indexed. On the other hand, there are powerful ways to get monolithic sites indexed too. Other people think it's better to put all your eggs in one basket so you can get a higher score on one host.

The truth is that people outside the S.E.'s don't know what the real rules are, and the S.E.'s will change them next year.

- Domain.com/blog might be better for seo, but it's probably not a big deal unless you are hoping to get lots of seo juice via your blog.

- blog.domain.com is easier to manage (easier to use third party service, easier to keep code updates separate, ...).

The rule that I use:

- everything user-generated that you have little control over (for example, forums or blogs with badly moderated comment section) goes to subdomains.

- everything you control goes to subfolders.

Thus, if you can keep your blog free of spam, it should go to subfolder.

Subdomain. An advantage that I didn't see below is that you can change the DNS to point the subdomain to a different server.

So, you could use domain.com for your projects, and point blog.domain.com to a hosted service (Posterous?)

Personally, I prefer subdomains, because I often type URLs into the bar. People who google everything wouldn't know the difference anyway.

Over the last 2 years, every big organization switched to folders (it used to be mail.google.com and finance.google.com, and now it's www.google.com/mail and www.google.com/finance; the only google exception I'm aware of is news.google.com). I remember reading an article about that having something to do with ease of geobalancing or something.

more aimed towards building web apps than deciding where to put your blog, but someone from wuffoo strongly recommended against subdomains

http://particletree.com/notebook/subdomains-development-suck...

Whichever is easiest with your setup. The important thing is to actually write - don't get too caught up in the technical details.

Hypothetically, if I have my blog at "example.com/journal", how can I host it on Posterous/Tumblr/etc?