WWW vs. Naked Domain?

When starting a new website, is it better to choose domain.com or www.domain.com?

This article is part of my Confessions of an Unintentional CTO book, which is currently available to read for free online.

At the start of every new project, we web developers face a question: “Should the website be accessible at www.mywebsite.com or mywebsite.com?” The answer, as argued on www.yes-www.org, is that there are compelling reasons to choose the www version over the naked domain.

For one, there is efficiency vis-à-vis cookies. Many web applications serve static assets from separate subdomains (e.g. your image files might be hosted on static.mywebsite.com). The motivation for this division of labour is that it frees up your main server for dynamic requests, i.e. requests that cause your web application code to give the processor a workout. Generally speaking, there’s no need to send cookie data to the server hosting your static files (static.mywebsite.com). Indeed, doing so would be wasteful of network bandwidth—which is exactly what happens when you make your website accessible from the naked domain instead of “www”. Why does this happen? Because of a rule in RFC 6265 that naked domains send all their cookies to subdomains, whereas subdomains do not need to send cookies to other subdomains.

The second reason not to use naked domains is that they inhibit your ability to avail of convenient DNS-level fallback solutions when working with server providers like Heroku. If one of your Heroku servers happens to fail—perhaps because of a denial of service attack—you’d very much like if Heroku diverted valid web requests to an unaffected clone of the server under attack. In order for Heroku to carry out this rescue job, it needs to be able to remap your domain’s IP address at the DNS level. This is only possible when your domain is hosted on a subdomain (such as “www”). The technical reason for this is that subdomains (but not naked domains) are allowed to have CNAME records in the DNS. These CNAME records can point to endpoints on Heroku’s system (such as myapp.herokuapp.com) rather than being limited to pointing at a fixed IP address, as happens with naked domains that can only employ A records. The CNAME record from your “www” setup furnishes Heroku with a “space in the middle” of the request, allowing Heroku to take redirection actions on your behalf.

How About Responding to Both WWW and the Naked Domain?

Not a good idea. If you allow for both possibilities, this would lead to duplicate content, a cardinal sin in the SEO world that could fatally damage your rankings in Google. (Check out my book on online marketing for programmers if you want to know a lot more.)

What you should do instead is intercept all requests to your naked domain with a 301 leading to the cardinal “www” domain. This is not only SEO-friendly, but it also keeps your website accessible on both domains.


More Articles:

Textmate to VIM

Where I explain how to reproduce over 110 commands from Textmate in VIM.


Taking Data Integrity Srsly

Data Validity Spot Checks, No-Delete Policies, Database Constraints, and Care with NULLs vs. FALSEs etc.


A Guide to Testing Web Applications for Developers Who Care about Overall Profitability

Presented in the form of 10 axioms