What’s the point in having “www” in a URL?
Solution 1
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.
Solution 2
Note: As of the ratification and implementation (by all current browsers, except possibly MSIE 11, see comments) of RFC 6265 in 2011 the following is no longer accurate, since cookies are by default never set across subdomains.
Historically, one good technical reason to make www.example.com
canonical was that cookies of a main domain (i.e. example.com
) were sent to all subdomains.
So if your site used cookies, they would be sent to all its subdomains.
Now, this often makes sense but it’s positively harmful if you only want to download static resources since it just wastes bandwidth. Consider all the style sheets and images on your website: usually, there’s no reason to send cookies to the server when requesting an image resource.
A good solution is therefore to use a subdomain for static resources, such as static.example.com
, to save bandwidth by not sending cookies. All images and other static downloads can be downloaded from there. If you now use www.example.com
for the dynamic content, this means that cookies only have to be sent to www.example.com
, not to static.example.com
.
If, however, example.com
is your main site, then cookies will be sent to all subdomains, including static.example.com
.
Now this isn’t relevant for most sites but changing your canonical URL later on isn’t a good idea so once you settled for example.com
instead of www.*
, you’re basically stuck with it.
An alternative is to use a whole different URL for static resources. Stack Overflow for example uses sstatic.net
, YouTube uses ytimg.com
etc. …
Solution 3
www
is a subdomain usually used for the web server on a domain along with others for other purposes such as mail
etc. Nowadays, the subdomain paradigm is unnecessary; if you connect to a website in a browser, you'll get the website, or sending mail to the server will use its mail service.
Using www
or not is a matter of personal preference. Opposing points of view can be found at http://no-www.org/ and http://www.yes-www.org/ - however, I believe that www
is unnecessary and just adds more cruft to the URI.
Most servers send the same site either way, but don't redirect. For SEO purposes, choose one, then get the other to redirect to it. For example, some PHP code to do this:
if (preg_match('/www/', $_SERVER['SERVER_NAME'])) {
header("Location: http://azabani.com{$_SERVER['REQUEST_URI']}");
exit;
}
However, some reasons promoting the use of a www
subdomain made by other answerers are great too, such as not sending cookies to static servers (credit Konrad Rudolph).
Solution 4
It's pretty historical. Once upon a time we used to have www.example.com, ftp.example.com, images.example.com, uk.example.com etc which seemed like a logical thing to do and provided a simple method to spread the load between servers.
These days I would just go for example.com for the main site and redirect the www version to that.
The Google Webmaster tools allow you to specify your preferred domain, so make sure you use those too.
See also:
https://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
https://stackoverflow.com/questions/1884157/to-www-or-not-to-www
Solution 5
If you are going to have subdomains for other purposes (blog for instance), you may want to differentiate the sites and have a www
prefix for the regular site. Other then that, the only important thing is to pick one of the two and stick to it (for SEO reasons).
Related videos on Youtube
Comments
-
Quintin Par almost 2 years
Other than for historical reasons, is there is reason to have “www” in a URL?
Should I create a permanent redirect from
www.xyz.com
toxyz.com
, or fromxyz.com
towww.xyz.com
? Which one would you suggest and why?-
Quintin Par about 14 years
-
Khushboo Tahir almost 11 yearsConversely, what's the point in not. For cookie and subdomain purposes on a successful web presence, it's helpful to separate out several processes.
-
Skippy le Grand Gourou over 9 yearsThis answer, though not directly related, seems relevant.
-
-
Konrad Rudolph about 14 yearsBy the way, I really don’t like
www.x
as the canonical URL so personally I would probably use a different URL for static resources if I were to design a big site. -
Joe H. about 14 yearsin the 'early days' you'd rarely see an A record for a domain -- maybe it'd have an MX record, but you rarely had a host there.
-
Philip over 13 yearsYou can provide a "default" CNAME record pointing to the CDN, you don't have to use "www". This allows your DNS server to have SOA, NS, CNAME, etc RRs all for the same domain name.
-
Khushboo Tahir almost 11 yearsHelps with CDN and setting up media.example.com, et al. to use proper subdomains. The cookie thing causes extreme green around the gills and bloating when it rears its ugly head.
-
Greg Hewgill over 10 years@AugustinRiedinger: ANAME records are not a standard DNS RR type. They are proprietary to specific service providers.
-
Augustin Riedinger over 10 yearsBut does this generates any compatibility issue or something? Is there any reason we should not use them (besides not being standard but proprietary)?
-
TomTom over 10 yearsNot ONLY a quirk - it also limits cookies to not be send to every machine but only those in the www domain.
-
Koen. almost 10 years@AugustinRiedinger it is not supported on most DNS servers. But if your provider has a DNS server which supports these features then that shouldn't give any problems with clients.
-
James Haigh over 9 years
http://example.com/
is fully qualified whereaswww.example.com
is not. I prefer the fully qualified approach because it is always recognisable as a URL regardless of whether it'shttps://example.uk/
orhttps://blog.example.eu/
or whatever. It is consistent with specifying the protocol of a secure site as HTTPS;www.example.com
is just a domain and says nothing about which protocol one should use to access it. -
nunya over 6 yearsLooks like no-www.org has reverted to a for-sale parked page where yes-www.org is still going strong. I guess that settles it. Everybody use "www" from now on.
-
Robin Winslow almost 6 yearsThis answer is entirely wrong in every important way. Neither cookies created on the server or with JavaScript on the apex domain (example.com) are shared with subdomains (www.example.com) by default, and vice-versa. However, both the main domain and subdomains can choose to create cookies with
domain=.example.com
, in which case they will be shared with the apex domain and subdomains. Therefore, cookies make absolutely no difference to the question of whether to use www or not. -
Konrad Rudolph almost 6 years@RobinWinslow But setting cookes on
domain=example.com
will set the cookie on the apex domain and on subdomains, and a way to avoid this is to not use the apex domain for HTTP. Though, agreed, another way would be to simply not specifydomain
when setting the cookie. I wonder if this has changed since I wrote my answer (which predates the relevant RFC 6265!) but I can’t be bothered to look it up now. -
Robin Winslow almost 6 years@KonradRudolph yes I think what's happened here is a change in how modern browsers handle cookies. I'm trying to track it down. But the important point is that the default if you simply set cookies on the apex domain, in latest Firefox and Chromium, is that they won't be shared with subdomains. Maybe in older browsers they still will be? I'd like to find a definitive source.
-
Robin Winslow almost 6 yearsAssuming it is a change in standard practice then my comment was unfairly critical, I apologise. But it appears that cookies are no longer a reason to choose www or not, in the vast majority of browsers. Although it would be nice to be able to put exact percentages to that statement.
-
Robin Winslow almost 6 yearsIt looks like the behaviour I describe has been the case since at least 2011 when RFC 6265 was written (more as a summary of current browser behaviour than a statement of how they should work). By now, we can assume that all browsers will be following it. See stackoverflow.com/questions/1062963/… and bayou.io/draft/cookie.domain.html. Given this, I think your answer has been misleading for at least 7 years, although it could have been accurate in some cases at the time of writing. Could you please update it to clarify this fact?
-
Konrad Rudolph almost 6 years@RobinWinslow Yes, will do.
-
Robin Winslow almost 6 years@KonradRudolph actually, according to mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-domains, the undesirable behaviour you described may have existed in IE11 at the time that post was written, and may still - which remains the most recent version of Internet Explorer. That would be pretty significant and worth mentioning, but it would be good to check it first. I can't check easily, as I'm on Ubuntu, but if you could that would be wonderful.
-
Konrad Rudolph almost 6 years@RobinWinslow Ah, unfortunately I can’t either. :/ I will just mention the caveat.
-
Robin Winslow almost 6 yearsMore evidence that IE11 does the bad thing: developer.microsoft.com/en-us/microsoft-edge/platform/issues/…