
Ask HN: Subdomains versus Directories? - dawson
I want to start a blog (and a number of projects). Which is better, domain.com/blog or blog.domain.com and why?
======
bhickey
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.

------
cagenut
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.

------
bl4k
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...](http://www.christonium.com/SearchEngineMarketing/subdomain-directory-seo))

~~~
rubyrescue
i don't think you can say SEO counts to your main domain in the same way as
subfolder - at least there's no empirical evidence in the link above that
subdomains are better or even the same as subfolders in terms of backlink
value.

if my clients are REALLY worried about SEO, i always recommend subfolder. if
they don't care or don't expect tons of backlinks to their blog, subdomain is
generally easier to manage so i recommend that.

~~~
bl4k
to clarify, I said 'pro on subfolder', meaning an advantage of being in a
subfolder is that you get the SEO.

I was listing the benefits of subdomain/subfolder and on subfolder seo is the
only one I could think of

~~~
rubyrescue
oh, sorry about that. well then we're in total agreement.

------
bphogan
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.

------
stevelosh
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.

~~~
stanleydrew
Or you could just click the links.

~~~
detst
Most blogs make this difficult by not having an easily-discoverable link back
to the main site. They link back to the root of the blog and maybe have a link
back to the main site hidden away somewhere, which takes more time to find
than editing the URL by hand.

It's frustrating but could be solved regardless or sub-domain/sub-directory
preference.

------
petercooper
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.

------
Spoutingshite
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.

------
megamark16
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.

------
terra_t
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.

------
petervandijck
\- 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, ...).

------
dchest
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.

------
chrisbroadfoot
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?)

------
beagle3
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.

------
daleharvey
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...](http://particletree.com/notebook/subdomains-development-sucks/)

~~~
devicenull
Reason #2 really isn't a good one. It's pretty simple to setup subdomains
locally (just use your hosts file to configure something like
dev.whatever.yourdomain.com to point to localhost). Every webserver I know of
supports name based virtualhosts, so it's not even like you need multiple IP's

~~~
daleharvey
you cant use wildcards within your hosts file, so you have to manually edit
your hosts file for every new subdomain you want to use, I have had a huge
hassle doing the same. particularly when you want 1. dynamically generated sub
domains, 2. to test a lot of subdomains.

Unless you want to run bind of course

~~~
andrewvc
just have your regular DNS use localhost as a wildcard subdomain, say
*.development.mysite.com

~~~
daleharvey
I think its pretty important for most people development setups to work
offline

~~~
andrewvc
Well, then setup bind. It's not the end of the world :). That, or just use
/etc/hosts, it's more of a pain, but for testing you just need a handful of
URLs.

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

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

