
Should you use www or not in your domain? (2017) - amingilani
https://bjornjohansen.no/www-or-not
======
quintin
[https://serverfault.com/questions/145777/what-s-the-point-
in...](https://serverfault.com/questions/145777/what-s-the-point-in-having-
www-in-a-url)

" One of the reasons why you need www or some other subdomain has to do with a
quirk of DNS and the CNAME record.

Suppose for the purposes of this example that you are running a big site and
contract out hosting to a CDN (Content Distribution Network) such as Akamai.
What you typically do is set up the DNS record for your site as a CNAME to
some akamai.com address. This gives the CDN the opportunity to supply an IP
address that is close to the browser (in geographic or network terms). If you
used an A record on your site, then you would not be able to offer this
flexibility.

The quirk of the DNS is that if you have a CNAME record for a host name, you
cannot have any other records for that same host. However, your top level
domain example.com usually must have an NS and SOA record. Therefore, you
cannot also add a CNAME record for example.com.

The use of www.example.com gives you the opportunity to use a CNAME for www
that points to your CDN, while leaving the required NS and SOA records on
example.com. The example.com record will usually also have an A record to
point to a host that will redirect to www.example.com using an HTTP redirect."

~~~
cortesoft
A lot of DNS providers these days will give you a pseudo-cname on apex...
basically having the dns resolver do a lookup of another dns name and return
that as an A record for the apex.

~~~
paulddraper
Yes. AWS Route 53 can do this for root or non-root records. They call these
"ALIAS" records.

~~~
pluc
Those only work for AWS services though, CloudFlare CNAME flattening works
with any endpoint by providing some sort of HTTP proxy

------
crazygringo
The reasons given for using www are honestly very weak, just edge cases
really.

As far as cookies are concerned, keeping them on the origin ensures they get
passed to all subdomains, which is usually a benefit, as opposed to a problem
-- which you'll discover when you need to restrict API requests on a subdomain
only to logged-in users, for example. And as long as you're keeping your
cookie payload small, like a session ID or two, there's zero worry about a
performance hit.

And as far as a CNAME needing to point to another domain instead of an IP, has
that ever been an issue for anyone? Genuinely curious. I'd never even heard of
that until now.

Honestly, simpler is better and "www." is an unnecessary vestige from another
era. I dropped it from my sites starting a couple years ago. (Obviously with a
redirect in case anyone ever types it.)

~~~
ericpauley
CNAME is absolutely an issue, especially when using managed hosting. Many
hosts require that you CNAME since they move around IPs. (e.g. Heroku) so
unless you put a provider in front of them that integrates with your DNS you
need www.

~~~
hacknat
You can add AWS, Azure, and GCP to this list. Most people don’t want to lay
out the money for a static IP, and why should they?

~~~
yegle
Not true for App Engine: we have a fixed set of IP addresses to be used in
A/AAAA record.

Disclaimer I work on App Engine.

~~~
hacknat
This FAQ on App Engine specifically says you guys can’t map a static IP to a
site:

[https://cloud.google.com/appengine/kb/](https://cloud.google.com/appengine/kb/)

~~~
paralelogram
App Engine uses four anycast IP addresses:

[https://www.bing.com/search?q=ip%3A216.239.32.21](https://www.bing.com/search?q=ip%3A216.239.32.21)

[https://www.bing.com/search?q=ip%3A216.239.34.21](https://www.bing.com/search?q=ip%3A216.239.34.21)

[https://www.bing.com/search?q=ip%3A216.239.36.21](https://www.bing.com/search?q=ip%3A216.239.36.21)

[https://www.bing.com/search?q=ip%3A216.239.38.21](https://www.bing.com/search?q=ip%3A216.239.38.21)

------
no_gravity
Let's take a look what the top sites according to Alexa do:

[https://www.alexa.com/topsites](https://www.alexa.com/topsites)

    
    
        Google: www
        Youtube: www
        Facebook: www
        Baidu: www
        Wikipedia: www
    

I see a trend here...

Would be interesting to go through the whole list and get a broader statistic.

Let's look at some of the newer/hipper sites on the list:

    
    
        Reddit: www
        Instagram: www
        Netflix: www
        Twitch: www
        Spotify: www
    

So all 10 out of 10 major sites I visited redirected me from the non-www to
the www version.

~~~
glenneroo
I wonder how much that has to do with Chrome and Firefox (and probably other
browsers?) prepending www (and https).

edit: I guess both of mine have some plugin doing this?

~~~
hacknat
Not at all. A browser would never do this. It would break a lot of sites!

~~~
jeroenhd
Actually, Firefox does prepend the www subdomain but only if it fails to
resolve a domain. When I mistype a website (exmaple.com) I often end up at
www.exmaple.com if I don't interrupt Firefox.

Chrome is moving towards the opposite though, hiding the www subdomain in the
browser bar.

------
jpswade
I wrote about this over 10 years ago and it mostly still holds true today...

See: [https://wade.be/yes-www/](https://wade.be/yes-www/)

I still think the best argument for keeping www is from Heroku:

"Root domains are aesthetically pleasing, but the nature of DNS prevents them
from being a robust solution for web apps. Root domains don't allow CNAMEs,
which requires hardcoding IP addresses, which in turn prevents flexibility on
updates to IPs which may need to change over time to handle new load or divert
denial-of-service attacks.""

See:
[https://web.archive.org/web/20110628072339/http://status.her...](https://web.archive.org/web/20110628072339/http://status.heroku.com:80/incident/156)

Like most things in technology, if Amazon, Facebook and Google are all doing
it, it's probably for good reason...

~~~
sneak
These days almost all dns providers support dns-server-resolved CNAMEs (ANAMEs
as they are known). I don’t think this is really much of an issue anymore.

~~~
ericpauley
AWS Route 53 doesn't support this for external CNAMEs, just aliases for amazon
resources.

------
paulsutter
He gives two reasons to default to www:

\- Cookies are passed down to subdomains / unnecessary cookies hurt
performance / cookies may be read by third parties

\- DNS origin can’t be a CNAME (must be an A-type record, that points to a
static IP address)

He is using the non-www like everyone else, of course. We always list out the
practical reasons that www is better, just before we choose non-www.

~~~
shawn
_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._

Granted, his blog was knocked offline by HN. But would a CNAME have saved
their Wordpress site?

FWIW, [https://ycombinator.com/](https://ycombinator.com/) redirects to
[https://www.ycommbiator.com](https://www.ycommbiator.com), as does Reddit.

------
vortico
A domain is a marketing tool as much as anything else on your web page. If
customers see a "www." in the address bar, it slightly dilutes the visibility
of your brand in the main domain. I believe this is more important than any
technical issue listed.

~~~
wolco
Does it dilute or position your brand? www for most gives the initial
impression of web/technical/site to the average person. Removing www dilutes
the association to those concepts. Using the www in print removes the need to
include [http://](http://) otherwise domain.io might be confusing.

~~~
jamieweb
Using www probably helps for the newer gTLDs, as the average non-technical
user may not realise that something like ".productions" or ".hockey" is a
valid domain.

In the past I've heard of non-technical users adding ".com" to the end of one
of these gTLDs, which obviously takes them to a completely different website.
I wonder whether anybody has used this as a form of pseudo-typosquatting or
phishing?

~~~
dmurray
Anyone who paid $200k for their gTLD probably already bought the .com for the
same name, or at least it's owned by someone bigger than a typosquatter.

~~~
jamieweb
Good point actually, I might look into this and see.

------
nobody271
Should you use your turn signal in the turn lane when it's already implied? If
yes, what about a two lane when you are in the outside lane? Did you know when
you turn you are supposed to go into the closest lane and then change lanes
again as opposed to driving through the close lane?

My point is web developers will do whatever they want. Technically you should
use www for your website. But if your domain is known for being a website the
www is implied and you could make an argument for leaving it out. But no one
cares. This isn't linux where you can force users to follow obscure rules to
get your software to work. You simply just won't get that traffic. And that,
is justice!

So we all know the answer already. Redirect [https://](https://) to
[https://www](https://www) or vice versa depending upon on your inclination.

~~~
bjterry
You should always use your turn signal even when it's already implied, because
that implication is not obvious from every vantage point near an intersection
to people who are potentially crossing your path (and who may already be
moving towards your path at speed).

~~~
bhandziuk
What about an on ramp? There's no signal and no intersection. Just a road
diverging from another.

~~~
wolco
But you signal when you merge.

~~~
bhandziuk
Sure but when you merge you're taking an action. You're changing lanes.
Otherwise if you're in a turn lane/on ramp you're just following the lane. For
you the lane is going straight.

------
bhartzer
As we move towards using more not-COMs and “dot whatevers”, right now it’s
actually better to use a www since many non-technical people may not know that
alphabet.xyz is a domain name. So in any offline marketing I’d definitely add
www to the beginning of a not-com.

For SEO purposes, if traffic is just clicking from one site to another, like
from a search engine, the url doesn’t matter. But it does pay to be
consistent, though. The main issue can be duplicate content isssues, so you
should choose one version. Same goes for all 4 versions, though, if you add
http vs https into the mix. Choose one.

I can see www not being needed to tell the non-techies that a not-com is a
domain name or web address as they get more used to not-coms. I senior taking
another 5 years until we get there.

~~~
patrickmcnamara
Alphabet actually uses 'abc.xyz' which looks even less like a domain name.
Using 'www' would probably ruin that domains aesthetic though.

~~~
snowwrestler
I doubt that Alphabet cares if anyone goes to that website, though. I don't
think it has been updated since the day it launched, has it?

All their public services default to subdomains, including www.

Although technically Google Search should probably load at search.google.com
if it were going to be consistent with the URL convention of all their other
services.

------
update
> Conclusion: Go with www

Am I missing something or is OP using a non-www domain? I'm using Chrome fyi
(mentioned because I know safari messes with the address bar)

~~~
RKearney
Safari doesn't mess with my address bar. Chrome on the other hand felt it
necessary to remove any instance of www or m anywhere in the domain of the URL
before it was rolled back due to backslash. www.m.www.example.www.example.com
would show up as example.example.com in Chrome before the rollback.

~~~
Dylan16807
You know part of that was a bug, right?

And Safari defaults to not even showing 90% of the URL, from what I can find.

------
throwaway2016a
No mention of iframes and cross domain Javascript for some reason. One
potential attack vector if you allow user defined content on subdomains is
that they can embed an iframe of your primary domain and they use Javascript
to read the contents and execute code in it. Which they cannot do if the
subdomains are different unless the page inside the frame explicitly sets
"document.domain"

Of course you can get a similar effect by using the "X-Frame-Options" header
but if you are doing something like allowing user-defined content it is best
to have layers and do different subdomains AND X-Frame-Options.

Basically if you have an application that allows users to host Javascript,
either use a completely different domain or make sure your root domain doesn't
host any meaningful content or have cookies that are used for security or
privacy.

------
amingilani
The biggest reason to not use the apex domain is because a CNAME on the apex
will render other records unreadable, and ANAMEs suck. They're great reasons.

However, Cloudflare already offers something called CNAME flattening for apex
domains and there's already an AAAA record type that works like a CNAME but
without all the problems they cause.

Granted, not all DNS providers support this, but if they do, is there else
anything wrong with using the apex domain? Isn't the cookie problem a solved
problem?

------
amelius
I'm using wwww just to fool everyone.

------
wnevets
Seems like everyone is focusing on reasons why you should use www and why
those reasons aren't important. Any reasons why you shouldn't use www besides
3 less letters in the domain name?

------
unilynx
The no-CNAME-at-root issue is long overdue for a fix, but it looks like
potential solutions are still in the discussion phases

My vote is for just letting CNAMEs work at the root, apparently a lot of DNS
software already lets you get away with it:
[https://mailarchive.ietf.org/arch/msg/dnsop/awmoLxtbQtQhSt9K...](https://mailarchive.ietf.org/arch/msg/dnsop/awmoLxtbQtQhSt9KDTr9JASy49k)

------
ToFab123
Yes, because when trying to give en url to an elderly or a non-technical, I
find that, they often gets confused if it doesn't start with www.

------
JeremyBanks
Site is down. Mirror:
[https://web.archive.org/web/20181111141630/https://bjornjoha...](https://web.archive.org/web/20181111141630/https://bjornjohansen.no/www-
or-not)

------
JoshuaAshton
Lots of people are saying "Root domains don't allow CNAMEs" and other such
things, but let's be real. Every DNS provider under the sun supports CNAME
flattening.

------
b1r6
For my own domains, I have a large number of subdomains and a less-important
root page. Because of that, I redirect www -> non-www. It makes me think "this
is the root."

------
qwerty456127
www is an atavism that doesn't make any sense today (as today the majority of
web documents are generated dynamically, a URL is meant to identify a document
rather than to locate it physically and public DNS and IP addresses rarely
have 1-to-1 relation to a physical web server). Nevertheless many people still
enter web addresses with www. Whenever somebody requests a URL with www it
should just redirect to without www.

------
joshstrange
I wrote about using a CNAME on your root a fews years ago that covers the MX
(email) records and problems it can cause. [https://joshstrange.com/why-its-a-
bad-idea-to-put-a-cname-re...](https://joshstrange.com/why-its-a-bad-idea-to-
put-a-cname-record-on-your-root-domain/)

------
drudru11
So it looks like chrome’s decision to hide the stable URL prefix is a good
idea now.

Interesting.

The technical reasons really make me lean towards using www.

------
bmalehorn
The article makes it sound like you have to choose between two options:

1\. users see example.com in the address bar

2\. hosting on www.example.com

However you can get the best of both worlds. If you go to amazon.com, you will
see amazon.com in the address bar. Yet your browser makes requests only to
www.amazon.com; the content is hosted on www.amazon.com.

Does anyone know how they pulled that off?

~~~
alangpierce
I think this is just a Chrome UI thing (which a lot of people complained
about): [https://www.digitaltrends.com/computing/chrome-69-will-
displ...](https://www.digitaltrends.com/computing/chrome-69-will-display-www-
url-but-chrome-70-will-change-that/)

For me, the "www" shows up in Chrome 70 and Firefox. Chrome 72 hides the www
again.

------
tabtab
Don't advertise your domain with "www", BUT make it handle it if entered that
way by a user. Another advantage of "www" is that word-processors and text
editors can auto-recognize it as URL if it starts with "www".

------
gargalatas
It's very very weird that you approach the problem from the userland (all of
you) rather than from the administration angle. No it's not a marketing or a
web designer problem. First of all it's an administration problem. WWW implies
the protocol. FTP implies the protocol. MAIL implies to protocol and goes like
this. You like it or not this is the main purpose of this usage because back
in the day http was not the most famous protocol. Other protocols like FTP for
example was very very famous and important too. But even today, when we see
"www." in an FQDN we automatically understand that [http://](http://) is
implied. But also a very serious reason is the computer science reason. It'a a
matter of tidyness and a right theoretical approach the usage of WWW. When a
DNS issue will come up no one marketing guy or designer will be there to help
you, you poor admininstator.

So please leave this decision to the admins and the way they established it.
With WWW!

~~~
jodrellblank
_It 's very very weird that you approach the problem from the userland (all of
you) rather than from the administration angle._

Is that really weird at all? "you take the pain so your customers have things
more pleasant" is a common idea.

None of your customers care if you are doing "the right theoretical approach
to the usage of www" if your competitor isn't. They'll simply go to your
competitor, who does the thing they want.

e.g. "CNAMES at the root of DNS" which is mentioned in this post; you can find
any number of greybeards lecturing you on how wrong it is, but when you face
your customers and they say "Amazon Route 53 DNS lets us do it", what does it
matter how wrong it is? Explaining to them how Amazon has built something
custom and non-standard, won't make them happier. They'll just use Amazon.

~~~
gargalatas
Are we talking about a small shity startup with a CEO that knows everything or
a big serious company like google where scientists debate of what is right or
wrong?

~~~
avarun
There are no "scientists" at Google debating whether things are right or
wrong. As with all companies, it is the product and business leaders of the
company that make this decision, and they make it based on what attracts the
most users.

------
koshak
In the honor of bikeshedding once a year someone writes an article on the
www/non-www topic.

The truth is: 1\. No one cares 2\. Choose one of two and stick to it 3\. Care
to maintain a redirect from the second option to the chosen one.

Cheers!

~~~
amingilani
I'm sure they do and I'm also sure you've heard it discussed ad-nauseam. But
it was fairly new for me :)

------
marcus_holmes
I'm grappling with this question at the moment.

The problem is that Let's Encrypt doesn't support wildcard certs, so having a
single cert for the origin and allowing connections on "www." is not possible.
This is a problem because a request on "[https://www."](https://www.") will be
rejected completely rather than redirected to the origin (or vice versa). In
other words, I have to choose one, and the other one won't work at all and
can't be redirected (for https, but I'm auto-redirecting from http to https as
well, so for everything). Obviously, the marketing gains from not having a
"www" outweigh any other considerations at this point, so no "www".

As I understand it, anyway. I could be wrong. I hope I'm wrong, and have just
misunderstood how this all hangs together.

~~~
susam
You can create a certificate with "example.com" as the subject and
"www.example.com" as subject alternative name (SAN).

Here is an example certbot command:

    
    
      certbot certonly -n --agree-tos -m example@example.com --webroot -w /var/www/example.com -d 'example.com,www.example.com'
    

The argument to the `-d` option defines all the subject alternative names.

~~~
djsumdog
Yea, this is what I do. I wrote a script to automate the process too:

[https://github.com/sumdog/bee2/blob/master/dockerfiles/CertB...](https://github.com/sumdog/bee2/blob/master/dockerfiles/CertBot/certbot-
domains.py)

------
omerh
With www Optional wize: easy dns handling and wildcard ssl will serve any
other future sub domain dns. Seo wise: google prefers it And if I’m not
mistaken there and rfc for it. I can look later

~~~
omerh
Sorry for the typos. _Operational wise

_ There is an RFC for using www

------
DFHippie
You should use 'www' so you can say "sextuple-u".

------
janaagaard
> Conclusion: Go with www

But the site hosting the article does not use www...

------
systematical
This is such an unimportant question. We use www at work and redirect non-www
to www. We could just as easily change that if we needed to. But it doesn't
really matter either way.

------
arrty88
What do the URL shortner services go with?

------
pwpwp
Why isn't he using www for his site?

------
stock_toaster
If only http used srv records instead.

~~~
LinuxBender
That would be great, but it does not appear to be included in http 3.0. At
least, google does not agree it is needed, so it won't likely be. It can only
be added in a major protocol version.

------
dexterdog
The bigger question for him is: should you use a CDN to handle your HN DDoSes?

~~~
system2
The writer is a typical "do what I say, don't do what I do".

------
the_clarence
No. Chrome, safari have removed these from the url bar, www has no meaning
anymore.

------
gaius
Yes of course www. We should resist all attempts to deprecate URLs so the
entire web will be hidden behind Google's search box. SEO is a plague.

~~~
saagarjha
[http://example.com](http://example.com) is a valid URL.

------
austincheney
The article suggests using WWW for DNS compatibility, but...

Everything it mentions in prefer for WWW can be solved by a combination of
static IP and CDN. My site's domain, for example, has a domain with a static
IP and the site is served by HTTPS. Certificate resolution for the HTTPS goes
to CloudFlare which also serves as a CDN for everything retrieved from the
domain. CloudFlare provides firewall and security options as a feature of its
CDN capabilities.

Because I am already solving for all the DNS and application concerns
mentioned by the article I choose to use the more sane approach and simply
drop use of a default subdomain.

EDIT:

I also detest cookies. They can store virtually nothing at 4kb per domain and
the cookie API is horrible. Instead I use localStorage for all storage
concerns and share explicitly anything that needs to be shared via XHR, which
currently is nothing.

~~~
hacknat
Not everyone can get a static IP for their site and if everyone did we would
be out of IPs.

~~~
Avamander
Everyone can get a static IPv6 IP.

~~~
system2
Good luck typing it.

