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

Original author: Bjørn Johansen
  • Transfer
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. To do this, fit DNS system, so you register 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 a host name in your domain www, so its fully qualified domain name (FQDN) will bewww.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 the web server in the domain example.com, you should contact the host with the name 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 'www' is example.com, from a DNS point of view, 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 enter in the browser simply example.cominstead of the full host name.

Then came SEO


Since example.comthey www.example.comcan point to different IP addresses, and from January 1997 to different websites at the same IP address, SEO specialists started telling us that the canonical name of the host should be chosen, and the rest should be pointed to there (with the 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 www.example.com, and you only use in print advertisingexample.comfor 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.comtyping is faster, 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 site does not example.comset 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 also go to the cdn.example.com, email.example.com, intranet.example.com, thirdpartyservice.example.comand so on. And many third-party services allow you to use your domain this way.

A cookie set from the host 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.comor 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.comon your behalf. The same applies to the email vendor when visiting email.example.comor the CDN provider that loads resources, for example static.example.com, and so on.

If you are worried about the security of at least somethingexample.com, then be sure to include a 'www' before 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.comRFC 6265 allows you to set a cookie for origin and share it with example.comor 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 the www.example.comcanonical name of the host, and in other places 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'!

Also popular now: