To be or not to be ... Whether to use www on your domain?

For 20 years or so, there has been a discussion about whether to use www in the canonical host name (CNAME) of your website. So, use or not?



Although many use the terms “domain name” and “host name” interchangeably, there is a difference between them, and it’s not just the semantics. I will simplify this description a bit to concentrate on the point.
')
As an IT administrator, your network will be your domain. It is reasonable to give the domain a name. DNS is adapted for this, so you are registering a domain name, for example, example.com . Now, under this domain you will have your own hosts. Each machine with a network connection is considered a host. The WWW document handling machine will naturally receive the www hostname in your domain, so its full domain name (FQDN) will be www.example.com . You will do the same for the rest of the hosts on your network, whether you have a web server or not. So you clean up your network.

To go to a web server in the example.com domain, you should contact the host named www.example.com . By the way, in those days when dinosaurs roamed the Web, virtual hosts did not exist. Each web server served only one web site (at least one IP address). The hostname did not matter if it pointed to the correct IP address.

"Naked domain name", i.e. a domain name without a 'www', like example.com , from the DNS point of view, is called origin. As the popularity of the World Wide Web grew in the mid-1990s, some administrators began to specify the same IP address as the host www. This allows site visitors to simply type example.com in the browser instead of the full host name.

Then came SEO

Since example.com and www.example.com can point to different IP addresses, and from January 1997 to different websites on the same IP address, SEO specialists started telling us that we should choose the canonical name of the host, and the rest must point there (with HTTP status code 301).

It made sense to choose one name. But which one? For SEO, it really doesn't matter. The main thing that was one. But besides SEO, there are other problems. Read on.

How do people understand the URL

When I worked in a marketing agency at the turn of the century, I was worried that people might not understand that they were addressed to the World Wide Web if we omitted part of the www. I mean, we just started skipping “http: //”. In addition, for historical reasons, I personally chose to use the full “correct” host name, i.e. www.example.com .

Today I do not think this is important. People will understand that this is a web address, is there www or not, when they face a well-known top-level domain. Since one version still redirects to another, it does not matter that your canonical host name is www.example.com , and you use only example.com in print advertising for the sake of beauty. At the same time, if you have one of thousands of new top-level domains such as .beer, then it makes sense to add www for the same reasons as you were in marketing at the turn of the century.

No www is easier and more beautiful

I have to admit: example.com faster to type, easier to read and it’s just saving space. Understandably, people began to drop www - and simply specify origin as the canonical host name.

So why is this still arguing?

Why are we still discussing whether to use www or not? Let everyone use what he wants, is it impossible?

Sure you may.

But if you are a website administrator, you probably want to make an informed choice and think over some things in advance. For example, cookies.

Cookies are transferred to subdomains.

Cookies set on behalf of the host will also be set for all subdomains. That is, if the website on example.com sets a cookie, the browser will also send this file when visiting www.example.com . It sounds good, because this is the same site, right? But cookies will also go to cdn.example.com , email.example.com , intranet.example.com , thirdpartyservice.example.com and so on. And many third-party services allow you to use your domain this way.

A cookie installed from www.example.com will not be sent to any “brotherly” host like the ones mentioned above. Your browser understands that these are not “sub-services”, but completely different services that should not get access to your cookies.

Unnecessary cookies hurt performance

The way HTTP and cookies work is that they are sent from the browser with each request to the web server. This means that if your website sets cookies for origin (example.com), this file should also be sent to every request you make, for example, to email.example.com or intranet.example.com . It slows down the connection.

Cookies can be read by third parties.

So, if the website matches the origin (example.com) and uses the CMS system, then after authorization it will issue cookies to your browser to keep the session open. Then, when you visit someinternalservice.example.com , the administrator of this service can read this cookie, copy it, and use it to log into the corporate CMS for example.com on your behalf. The same applies to the email vendor when visiting email.example.com or a CDN provider that loads resources, such as static.example.com , and so on.

If you are concerned about the security of at least something on example.com , be sure to include a 'www' in front of it. Even if this did not convince you to use 'www', I don’t know what can convince. Neither HTTPS nor 2FA will help, since this cookie is a magic token. However, other security measures, such as IP restrictions , may help.

Cookies from subdomains can be shared if you want

If you have a service on a subdomain, for example, sso.example.com , then RFC 6265 allows you to set a cookie for origin and sso.example.com it with example.com or www.example.com . Thus, giving up a “bare domain” as a host name actually gives you more flexibility.

DNS Restriction

Speaking of flexibility, we need to get back to talking about DNS.

In DNS, there is a restriction that origin must be an A-record, that is, point to a fixed IP address.

When your site grows large and you move it to a hosting site or want to send it to a firewall or DDoS protection service, you use the CNAME record to send the hostname to another non-permanent hostname that the provider manages depending on your traffic and needs.

But if the site is hosted on a bare domain (example.com), you can not do this. However, there is no problem to specify the host name with 'www' in CNAME. So if you want any scaling flexibility, now or in the future, you should set the host name to 'www' from the very beginning.

Conclusion: choose www

It is important whether you use www or not. I agree that bare domains look more beautiful, but this is just a practical question for the browser address bar. You can use www.example.com as the canonical host name, and elsewhere just use the bare domain. Users will still be redirected to the right place.

But important arguments favor the use of a full host name with 'www': for performance, security, and flexibility.

So once and for all, put an end to the discussion: opt for 'www'!