Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Other than for historical reasons, is there is reason to have “www” in a URL.
Should I do a permanent redirect from www.xyz.com to xyz.com or xyz.com to www.xyz.com? Which one would you suggest and why?

share|improve this question

migrated from stackoverflow.com May 27 '10 at 9:30

This question came from our site for professional and enthusiast programmers.

    
Related: stackoverflow.com/questions/1109356/… –  Quintin Par May 27 '10 at 8:17
    
Conversely, what's the point in not. For cookie and subdomain purposes on a successful web presence, it's helpful to separate out several processes. –  Fiasco Labs Sep 15 '13 at 20:34

8 Answers 8

up vote 117 down vote accepted

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.

share|improve this answer
10  
+1: Excellent technical reason why! –  Donal Fellows May 27 '10 at 8:11
3  
You 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. –  Chris S Oct 28 '10 at 1:19
    
How come nobody mentions the ALIAS (or ANAME records) in this kind of topic? Doesn't it achieve the same results as the CNAME on nakeddomain (except from the cookie issue...)? –  Augustin Riedinger Feb 27 at 10:44
1  
@AugustinRiedinger: ANAME records are not a standard DNS RR type. They are proprietary to specific service providers. –  Greg Hewgill Feb 27 at 16:57
    
But does this generates any compatibility issue or something? Is there any reason we should not use them (besides not being standard but proprietary)? –  Augustin Riedinger Feb 27 at 20:21

One good technical reason to make www.example.com canonical is that cookies of a main domain (i.e. example.com) are sent to all subdomains.

So if your site uses cookies, they will be sent to all its subdomains.

Now, this often makes sense but it’s positively harmful if you only want to download static resources. 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. …

share|improve this answer
8  
By 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. –  Konrad Rudolph May 27 '10 at 8:19
    
Helps 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. –  Fiasco Labs Sep 15 '13 at 20:36

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).

share|improve this answer

I'd do the first. The www convention comes from the early days of HTTP where www.cmu.edu and cmu.edu were very likely different machines.

share|improve this answer
8  
in 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. –  Joe H. May 27 '10 at 12:27

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).

share|improve this answer
1  
I can't find reference at the moment, but it could also have effects on the same origin policy. –  Kobi May 27 '10 at 8:09
    
Yes it will, unfortunately. You can't AJAX to www.example.com from example.com or vice versa without something like JSONP. –  Delan Azabani May 27 '10 at 8:12

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:
http://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
http://stackoverflow.com/questions/1884157/to-www-or-not-to-www

share|improve this answer

Here is another minor perspective.

By not having www, there is a minor downside when it comes to text-based media, whether printed or online, and that is getting it recognized as a web address. In print, it’s usually pretty obvious that example.com is a web address, and you can add styling touches to highlight that. But plain text online? Not so easy. The chances are that if you send a plain text message – whether email, tweet, Facebook post, SMS or whatever – it will recognize a URL beginning with http:// or www. but won’t recognize one without either of those. So in order to make the URL into a clickable link, you have to either put www. or http:// on the front, and of the two, www. is shorter, less clunky to look at and easier to read.

share|improve this answer

For system/network engineers, "www" == "http" == "tcp/80". This nomenclature is interchangeable, because it's easy.

So it makes sense to manipulate "http" traffic at the DNS level, by manipulating hosts or hostnames based on the "www" naming convention.

It is also an easy way to use shorthand when talking about a specific ip:port socket.... I.e. "do you see www open on eth5?" would really mean "do you see tcp/80 open to the world and accepting incoming connections on the nic that registered with kernel as eth5?"

In other words, there is a lot going on behind the scene, and the ww nomenclature is very useful IMHO. Especially when talking about caching and ELB (I.e. hey Joey, how many healthy ww's do you see on site xyz?).

Obviously, ww's would have "ww" in their hostname, as db's have "db" in their hostname. It is important to get this right from the get go. Once a naming strategy is in place, it's hard to change it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.