For 20 years or so, there has been the debate over whether you should use www or not in your web site’s canonical hostname. So should you use www or not?
Some historical background
Even though people often use the terms “domain name” and “host name” interchangeably, there is a difference, and it’s not just about semantics. I will simplify this description a bit, to get a point:
As an IT administrator, your network would be your domain. It would make sense to give the domain a name, and DNS accommodated for this, so you would register a domain name, e.g. “example.com”. Now, under this domain you would have your hosts. Each network connected machine was considered a host. The machine for serving World Wide Web documents would naturally get the hostname “www” under your domain, and thus given the fully qualified domain name (FQDN) “www.example.com”. You would do the same for all the other hosts in your network, whether you had a web server or not. This is how you kept the hosts in your network organized.
To go to the web server in the “example.com” domain, you would then go to the host with the name “www.example.com”. By the way: Back when the dinosaurs roamed the interwebs, there was no such thing as virtual hosts. All web servers served a single web site (at least per IP address). It really didn’t matter what hostname you used, as long as it pointed to the correct IP address.
The “naked domain name”, i.e. your domain name without “www” – like “example.com” is in DNS terms called “the origin”. As the World Wide Web grew popular in the mid 1990’s some administrators started pointing the origin to the same IP address as the www host. This would let website visitors type only “example.com” in their web browsers, instead of the full hostname “www.example.com”.
Then came SEO
Since the origin, “example.com”, and the hostname, “www.example.com” can point to different IP-addresses – and since January 1997 to different web sites on the same IP-address – people knowledgeable of SEO started telling us that we had to choose a canonical hostname and that the other should point there (with a HTTP 301 response code).
Also, it kind of made sense to choose one. But which one? For SEO it really doesn’t matter at all. As long as you choose one. But there are other concerns than SEO. Read on.
Humans’ understanding of an URL
When I worked at a marketing agency just after the turn of the century, there was a real concern that people might not understand that it was a World Wide Web address if we left out the “www” part. I mean, we had just started to leave out “http://”. Also, because of the legacy, I personally preferred to go with the full “correct” hostname, i.e. “www.example.com”.
Today, I don’t think this is a matter at all. People will understand that is is a web address whether you have the www or not, if you have a commonly known top level domain. Since one version redirects to the other anyway, it doesn’t matter if your canonical hostname is “www.example.com” and you use just “example.com” in print advertising, since it looks better. Likeweise, if you have one of the thousands of new top level domains, like .beer, you might want to include the www for the same reasons as we had in marketing a long time ago.
Non-www is prettier and easier
I have to admit: “example.com” is shorter to type, easier to read out (how do you read out “www” on a single breath anyways?) and it simply takes less space. It is fully understandable that people started dropping the “www”-part and just went with the origin as the canonical hostname.
So why is www or not still an issue?
Why are we still debating this now? Can’t people just use what they prefer, and the rest of us leave them to it?
Yes, of course.
But you see, if you’re an administrator of a web site, you probably want to make an educated choice. Because as with most things on the internet, not everything was thought through when we started using them. Things like cookies.
Cookies are passed down to subdomains
Cookies set from a hostname, will also be sent to all subdomains. I.e. if the website on “example.com” sets a cookie, the browser will also send this cookie when visiting “www.example.com”. Sounds like a good thing, since it’s the same website anyway, right? But the cookie will also be sent to “cdn.example.com”, to “email.example.com”, to “intranet.example.com”, to thirdpartyservice.example.com and so on. And a lot of third party services let you use your domain exactly like this.
A cookie set from “www.example.com” will *not* be sent to any “sibling” hosts like above. Your browser understands that they are not “subservices” but completly different services, and should not get access to your cookies.
Unnecessary cookies hurts performance
The way HTTP and cookies work, is that they are sent from the browser for each and every request to the web server. This means that if your website sets a cookie for the origin (“example.com”) this cookie will also have to be sent to every request that you make to e.g. “email.example.com” or “intranet.example.com”. This slows down the communication and leaves your with a worse user experience.
The cookies can be read by third parties
So, if your web site is located at the origin (“example.com”) and have a login to a CMS, the CMS will issue a cookie to your browser to keep you logged in for at least the session. Then, when you visit “someinternalservice.example.com”, the administrator of that service can read that cookie, copy it and use it to login to the corporate CMS for “example.com” as you. The same thing applies to your email service vendor when you visit “email.example.com”, your CDN vendor when you visit “example.com” which loads assets from e.g. “static.example.com” and so on.
If you’re concerned about the security of whatever you have on “example.com”, make sure you slap a “www”- in front of it. If that doesn’t help you choosing whether you should use www or not, I’m not sure what will. Neither HTTPS nor 2FA will help you out, since that cookie is the magic token. Other security measures, like IP restrictions will however help.
Cookies from subdomains, can be shared – if you want to
Now, if you have a service on a subdomain, like “sso.example.com”, RFC 6265 allows you to set a cookie for the origin and making it shared with “example.com” or “www.example.com”. So avoiding the “bare domain” as a hostname, actually gives you more flexibility.
DNS origin can’t be a CNAME
Talking about flexibility, we have to circle back to talking about DNS again.
There is a limitation in DNS which says that the origin, must be an A type record, which means it has to point to a fixed IP address.
When your site grows large and you move it to an hosted service, or wants to point it to an Web Application Firewall or a DDoS mitigator, you might want to use a CNAME type record, to point the hostname to another flexible hostname that the vendor manages depending on your traffic and needs.
Now, if your website is hosted at the origin (“example.com”), you can’t do that. But there is no issue with the “www” hostname being a CNAME record. So if you want any scaling flexibility, now or in the future, you should go with the www hostname from the beginning.
Conclusion: Go with www
It does matter if you use www or not. I agree that the origin domain name looks prettier, but that is just a practical matter in the address bar of the browser itself. You can use “www.example.com” as your canonical host name, but everywhere else, you can just use the bare domain. It will redirect the users to the correct place anyways.
But there are important matters that says you should use the full hostname with the www: Perfomance-wise, security-wise and in terms of flexibility.
This should end the “www or not”-debate once and for all: Go with www!
Are you using WordPress and want to move your existing site to a www domain? If so, check out the post “ Move your WordPress site from non-www to www domain” and follow the easy steps to moving your WordPress site.