To www or not to www – Should you use www or not in your domain?

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.

48 thoughts on “To www or not to www – Should you use www or not in your domain?

  1. I disagree. It also seems that you disagree with yourself, since you don’t use www in your own domain name ;)

    Ugliness nuffilies all that stuff you said above.

    And you could of course use a different subdomain and get all of those technical advantages. I do that with ryan.hellyer.kiwi. I do not use http://www.ryan.hellyer.kiwi ;)

    1. I knew that people would point out that I don’t use www myself, and you’re far from the first in line to so.

      If you print “geek.hellyer.kiwi” on the side of the buses in Berlin together with your face, do you think people will understand that it is a web address?

      BTW, I’m in the process of rebuilding my entire site and hosting infrastructure, so I’ll do the domain switch when I launch that. Will probably be on a new domain too.

        1. I’m “always” recreating it :-) In regards to www or not, I switched. And because of reasons, I switched back. Lesson learned: Whatever you decide to go for, stick to your decision :-)

          1. Just read the part that you switched, then switched back. Shouldn’t you update the article then?

      1. Does the rationale hold for Germany? On the buses of Berlin we may fear www seems too similar to “Wehe wehe wehe wenn ich auf Ihren Endpunkt sehe”. It is not an English world after all.

  2. Nice post! Thank you. Looking forward to seeing your new site setup on W.ordPr.es/s!

    I’m the guy who just let that one go. I have enough fun with ‘rdpr.es’ and wasn’t using ordpr.es, so I figured I wouldn’t be greedy and let it go.

    To answer your question, “How do you read out “www” on a single breath anyway?” …peeps tend to say “dub-dub-dub” on this side of the pond/s.

    ***BTW, I figured you’re free not to post (and/or delete) this comment if you’d rather not tip off your pending new website/url; I actually wanted to send you an email, but have not seen your email address anywhere.***

    Also, no doubt you’ve checked it out, but playing with our WordPress domain name hacks (wo.rdpr.es/s and w.ordpr.es/s) in no way violates WordPress’ trademarks for urls which are explained here: https://wordpress.org/about/domains/

    Cheers!

    *my website is currently off-line while I change web hosts.

  3. I’ve been going back and forth with myself on this for two decades. However, I now apply a data-driven approach to this. My findings, based on site with less than a million monthly visits of technically minded people, is that non-WWW URLs get shared more often and receive higher click-through rates from search engine result pages than the same page served with-WWW. I have no idea why this is, but suspect people are more likely read shorter URLs. As there is less information in a shorter URL, I believe that people are also more likely to read and remember relevant keywords in the URLs. I at least think that the readability of the shorter URL my help explain why I see higher numbers of shares for these addresses.

    I’ll see if I can’t cook up some more scientific experiments with this and get some actual numbers. What I’ve done in the past was to redirect 50 % of visitors to the non-WWW variant and 50 % to the with-WWW variants. (Search engine bots where always given the same variant of the same URL, but with a 50-50 mix.) The URL’s without WWW was far more likely to end up being shared than the WWW variant.

    1. That is really, really interesting. I would love to see some actual numbers on it.

      By the way: ~90% of all traffic to this site is from search engines. When I moved to www, the traffic almost immediately dropped ~20%. Now, almost two months later, it is still ~10% lower than what is was before I moved.

        1. There were SEO issues, and then some technical issues. Also I found out that I personally like without www better.

          Lesson learned: Whatever you go for, never ever change 😊

          1. You advocate against no-www but in the end you decided to go no-www yourself. Even after stating (in a previous comment) that you were restructuring your website and changing to www in the process.

            Perhaps you could revisit the article and share your, perhaps, new opinion? I mean, you’re advocating no-www, but your keep using no-www on your own website!?

          2. Lesson learned: Whatever you go for when you launch a new website: Don’t change later 🤪

  4. Great post Bjorn! I have always used the traditional www on my websites but I’ve started to notice a lot of major brands just using their name only. Thanks for breaking down the difference and the effect of cookies on sub domains. I think I’ll just stick to the www for now.

  5. Well explained. I really didn’t think that 2nd level domain cookies could be propagated on subdomains… Weird and scary WWW again :) … Thanks!

  6. Thank you so much, Bjørn. It has been a while since I was last faced with “to www.” or “not to www.” but here I am, setting up another website a few years down the road. My instincts have always told me to go with the “www.”. Your explanation is precise and delivered in a readable style. That part about the cookies was an eye opener. Got it. Thanks again.
    ~Wendy in Canada

  7. 1.- Actually, there are several DNS providers that allow CNAME-like records for root doamin (for example NS1 and Cloudflare).

    2.- According with specification (http://www.ietf.org/rfc/rfc2965.txt), you can set a cookie with a empty domain parameter and the cookie will be valid only for current host-request. So, if the current host request is example.com and the cookie is set with a empty domain parameter, the cookie is not shared with any subdomain, including www. But be aware that domain=example.com is like domain=.example.com (with a preceding dot) and the cookie willn be shared with any subdomain. if you want a cookie only for root domain, the cookie must be set from a root domain request and with empty domain parameter.

  8. Hello Bjørn great article. I have just recently been updating website and have discovered a lot of authority on my domain without www. I just started using webmaster tools and have set the preferred domain to be www is that all I have to do? to transfer the trust factory will google do the rest?

  9. I would say the game changes with HTTP/2 again. With H2 you should ideally host everything on your main hostname (ie. no cdn.example.com and images.example.com) and the header compression makes the cookie data redundancy go away. So if you use HTTP/2 (you should) I’d say go without www and put everything on example.com.

  10. Another reason to go with www is when you use the same domain in Active Directory. With AD the origin has to point to a domain controller and that’s not necessarily where you want to host your website

  11. ‘(how do you read out “www” on a single breath anyways?)’

    Do what the Kiwis do; “dub dub dub dot example.com” :)

  12. Good arguments, especially cookies.

    But I still prefer no www.

    If you use cloudflare they do some magic so you can still set it with a cname and send your traffic wherever you’d like.

    1. “Solved” would be whether you trust all devs on all apps throughout your domain to have 100% control over this, and that you trust all your users to use browsers compliant to this standard.

      There have been at least three standards on handling cookies, that I know of, used by browsers: The original Netscape implementation and two RFCs. Microsoft just recently (in 2018) started following the same practice as other browsers, and only in Windows 10 RS3 (for Edge) and RS4 (for IE).

      Please reference this article from Microsoft regarding cookies in IE/Edge: https://blogs.msdn.microsoft.com/ieinternals/2009/08/20/internet-explorer-cookie-internals-faq/

    1. Yes. I did at one point change it, but changed it back. My recommendation is that you stay with whatever you currently got. For new sites, it is something to consider, but for existing sites: don’t change it.

  13. Thank you for this article, I was thinking of changing my url to www. But with the comments I have read so far I think I would stick to using no www on my domain name. All thesame, this article was helpful.

    1. Yes, I highly recommend that you stick with whatever you currently got, unless there is a technical reason why you HAVE to change it.

  14. “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.”

    Umm, I get your point for other third party hosting services (like AWS ELBs or GCP’s LBs), but I’ve been using Cloudflare since 2012 on naked domains (for small sites) and I’ve never had an issue while also leveraging Cloudflare’s load balancing edge node capabilities, but for an app or website that dynamically needs ELBs, yeah it could prove problematic.

    Here’s some magic for S3 buckets using CNAME Aliases on bare domains :) I used to run a website like that. https://support.cloudflare.com/hc/en-us/articles/360020991331

    Back to the overall question, I was more concerned at cookie setting at www. vs bare domain and does the performance really affect that much? I’ve seen some pretty high end sites like buffer.com and kinsta.com go without www. in front and it looks like 100x more appealing and more likely to me remembered. Many big sites like Airbnb still use www. I guess there is no right and wrong here, but whichever one a site goes with they should stick with it to avoid losing SEO and putting in more work for nothing (and possibly downtime too with 301 redirects, TLL delays or misconfigured DNS entries). I think massive sites like Google/YouTube/Facebook (dealing with millions-billions of active users a day) should all go with www. for the cookie issue, but for small-large (not massive) traffic sites it just seems like a negligible optional point.

    With HTTP2, domain or subdomain sharding is now irrelevant, since HTTP2 has multiplexing built in for like 6+ requests at once.

    I wanted to know if every HTTP requests sends the same amount of cookies for each requests, do you know? I tested it by visiting a single image on my bare domain site but it only used one cookie and that was Cloudflare, so it wasn’t using any other cookies, but not sure if it plays out differently when you access the site as a whole from just the root domain. https://stackoverflow.com/questions/1336126/does-every-web-request-send-the-browser-cookies

    https://blog.webf.zone/ultimate-guide-to-http-cookies-2aa3e083dbae

    All of this time wasted researching this could have gone into theme design :( Sigh, #TechLife But I guess it’s good to know the details. Some examples of sites/screenshots of cookies etc would be a nice evaluation rather than just seeing text all the time, haven’t really seen a video topic on this either that isn’t SEO related.

    Btw, you need disqus :P

    Thank you! One of the best writeups on this topic and I’ve been to many sites on this issue.

  15. Thanks very much indeed Bjorn! Very clearly explained. This article made total sense to me and has sorted out a dilemma that I have for years. You are a legend.
    I am just launching a new website for which your considerations are potentially going to be an issue down the track. So happy I found your article.
    I was surprised that people have disagreed with you as there aren’t many large internet companies that don’t take your line of thinking! I checked the websites of the largest businesses that I use online – and without exception – all are using www.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.