[cyberferret]

The author seems adamant that blog.domain.com is a worse setup than domain.com/blog - I've seen this argument go back and forth a lot, with both sides claiming advantages and disadvantages.

I am interested to hear the consensus from HN users as to which is better, and why.

[ldoughty]

From a cloud perspective, it's easier (by a tiny bit of work) to point a subdomain to a service over pointing a folder.

E.g. blog.example.com pointing to a static website while project.example.com points to a server.

If you want both to be under the same domain and use a CDN for only one of them, you still have to configure the pass through of all others... But if it's only one subdomain, CloudFront no longer needs to know about non-Cloudfront endpoints.

I run my Hugo site on S3+CloudFront for a be penny a month (if that), despite also having a $5/month server... It protects my site from going down if one if the 5 WP sites I lazily host for friends gets directly attacked and someone pops a shell + container break out.

[zirobi]

It's not a matter of one being objectively better than the other but which suits your needs.

The basic distinction, from a purely SEO perspective, is that blog.domain.com will be treated as its own entity whereas domain.com/blog will be treated as part of the main domain.com entity.

The question you have to ask yourself is whether you want to bolster the "value" of your main domain or if you want your blog to be an asset in its own right.

There is no right or wrong answer — there is simply what's best for your situation.

[michaelbuckbee]

Objectively better for SEO - and in particular if this isn’t a personal blog, but say a marketing site for your SAAS and then an accompanying blog. Having them in separate domains with very similar content hurts you

This has been fairly well beaten into the ground at this point.

[toddmorey]

I’d say objectively safer. Google is getting better at reconciling content split across subdomains as coming from a common source. Some Google experts have called it pretty much a solved problem, but I don’t think the data plays that out just yet. I do believe there will soon be a time that subdomain vs subfolder won’t matter for SEO. Just not quite there yet.

[matsemann]

As he said, a sub domain is often considered a separate domain when it comes to SEO. His other arguments about naming seems rather hand-wavy, though.

Security-wise, a subdomain can also be a different origin. Which is often positive, so a flaw in your blogging software doesn't allow someone to extract cookies or so from the main site.

[chrismorgan]

Using a subdomain will only protect host-only cookies (those lacking a domain=… parameter). Cookies that specify a domain deal in subdomains rather than origins, so blog.example.com will be able to see any domain=example.com cookies.

This is why using a completely separate domain can be wise if you’re using a third party to host your blog. At Fastmail when we shifted our blog to Ghost(Pro), we moved the blog from blog.fastmail.com to fastmail.blog, so that they definitely can’t get any cookies we may happen to set on domain=fastmail.com (even though our login cookies are domain=www.fastmail.com and thus safe anyway; defence in depth, and all that; by contrast, our product Topicbox does store its cookies on domain=topicbox.com, so the protection of using topicbox.blog is real there).

[jrockway]

I feel like x.example.com is preferred over example.com/x because it is simpler to move the files around (when you want the same app/bundle of static files to be y.example.com). Browsers by default will make <a href="/foo/bar.html"> into x.example.com/foo/bar.html when served from x.example.com, but it won't make it into example.com/x/foo/bar.html when served from example.com/x/; something else has to make sure the URLs are correct. The options available to make links work are to generate correct links in the first place (CGI back in the day provided enough information to make this possible, but modern reverse proxies have no way to convey this), never use absolute paths in links (restrictive), or to have some machinery intercept the document, parse the HTML, and rewrite links (super flaky). If you are always going to be at exmaple.com/x/ and never need to change the base URL, you can make it work. If you are making something reusable that people download and self-host, you will pull all your hair out making the /x/ case work well. Therefore, people tend to prefer the subdomain approach. It's just easier, because of an implicit base URL assumed by browsers (and even things like grpc clients). When you try to override defaults, it's like rolling a stone up an infinitely long hill. This is that, I think.

For your blog, it doesn't matter. You can hard-code the entire URL in every link and it will probably never go wrong. Applications are harder. Applications that various people are going to self-host are hardest.

[wbl]

Reverse proxies do pass the host header which is all you need.

[jrockway]

I'm talking about the case where your application is being served at, say, localhost:1234 but the reverse proxy thinks it's example.com/some/sub/path; as far as I know there is no header that says "add /some/sub/path to every URL you generate". (Yes, Host tells you the base is example.com.)

[mytailorisrich]

What is the business justification for creating a blog on your website?

In general I would think that it is to create contents and SEO, in which case I believe that it is better to host it under the website's domain. On the other hand you may be targeting a different audience from your main site/product. For example Uber, Netflix at al have "engineering blogs" these days, which clearly have no relation to their product but perhaps rather aimed at being a recruitment tool. In such case you might want to use different domains (which incidentally is what both Uber and Netflix do).

I see people commenting on the technical aspects but the differences are minor and the business goals should be driving the decision.

[WA]

If you host PHP software like phpBB on a VPS on forum.example.com and have your static website hosted on Netlify under blog.example.com, it's easier to do this with subdomains.

Of course, you can have a load balancer under example.com that acts as a reverse proxy for your forum unter example.com/forum, but the easier setup with different languages/software/servers is to use subdomains imho.

[johnchristopher]

I have some reasons to prefer domain.com/thing now :

- You don't have to add and manage subdomain

- You don't have to stop and restart the reverse-proxy of your VPS

- Only one cert to deal with (I use traefik w/ automatic LE renewal but that implied more things to set up on the chain)

But I still use blog.domain.com because I find it prettier. And when I need to type it in the URL bar it's just $service<tab>.domain<tab><enter>.

Now the SEO crowd has other requirements that make their choice more valid than my own (one user, one set of idiosyncrasies).

[bovermyer]

Those three concerns are one-off operations with minimal time investment, even if you don't automate most of the process.

[johnchristopher]

There are not one-off since I'd have to perform them every time.

[bovermyer]

Every time? I'm confused. How frequently are you setting up new blogs? If it IS frequent, why have you not automated the process?

[johnchristopher]

I am frequently setting up new services for try out which are not blogs (e.g.: vpn, online bookmarks manager, chat services, file syncing services, etc.). These require different setting in the reverse proxy and a different subdomain.

[diafygi]

blog.domain.com is much better from a security perspective since logged-in session cookies from your main domain won't be sent in blog requests (different origin).

That provides protection for if someone manages to get a malicious script into your blog, they can't start making authenticated requests (since it isn't the same origin).