Is there any downside to having both point to the same place?
You'd still have to choose your preference, either to redirect to non-www or www. I prefer www, but that's just me
To www or not to www?
11–20 of 23 posts
Re: To www or not to www?
#12I'm surprised at the www supporters. Do not do this. Down the road, you will want to use subdomains (app.example.com, dashboard.example.com) and choosing www out of the gate will make it more complicated then it's worth. If HTTPS is required, then a certificate with www will always get in the way, get a non-www and add a subject alternative name, or get a wildcard.
It is much, much easier to redirect all non-www traffic to www if a subdomain is not specified then otherwise and a wildcard or SAN-enabled certificate will make it much more flexible in the future.
Re: To www or not to www?
#13Is there any downside to having both point to the same place?
You mean having both serve the same content? Yeah, the downside is SEO. Google picks up both versions and labels it duplicate content.
You can put a canonical meta tag on each page, but as I understand you lose a few percent of the page's value. 301 redirect is the only way to conserve all of the value.
Not an expert, just repeating stuff I've been told by our SEO guys.
Re: To www or not to www?
#14With "www". That makes it a lot easier to add in CDN support, DNS based load balancers, and a ton of other tools down the line. Why? Because you need your domain root to have all sorts of other stuff in it- MX records, SPF keys, and various other things. A lot of CDNs and DNS based tools work really well by utilizing CNAMEs, which you can't do on the root. Putting your website on "www" keeps is as a separate isolated…
I'm not sure I understand this advice. The domain root can still have the CNAME, TXT, SPF, MX records, etc. while pointing the zone root to the website's IP. These are all just different record types within the zone, right?
I think he's saying, if in the future you want to route web traffic through a CDN, using a CNAME, instead of directly at a specific server, using an A record, you're going to struggle if you're using the root name, as you can't have root CNAMEs.
Damn good reason too! I can't think of a good way round it. Do people like CloudFlare configure using CNAMEs? If they do, this strongly weights my decision, (along with the 'non expert users like www.' argument - though I think as long as you use a .com you're probably okay there).
Re: To www or not to www?
#15Earlier quoted context omitted.
I'm not sure I understand this advice. The domain root can still have the CNAME, TXT, SPF, MX records, etc. while pointing the zone root to the website's IP. These are all just different record types within the zone, right?
I think he's saying, if in the future you want to route web traffic through a CDN, using a CNAME, instead of directly at a specific server, using an A record, you're going to struggle if you're using the root name, as you can't have root CNAMEs. Damn good reason too! I can't think of a good way round it. Do people like CloudFlare configure using CNAMEs? If they do, this strongly weights my decision, (along with the '…
CloudFlare actually hosts the DNS of the domains using them, except for people who pay for the premium accounts. Then they rely on CNAMEs.
You hit what I was saying spot on. It's not just a matter of CDNs either, there are a lot of services where using CNAMEs become important.
Re: To www or not to www?
#16I'm surprised at the www supporters. Do not do this. Down the road, you will want to use subdomains (app.example.com, dashboard.example.com) and choosing www out of the gate will make it more complicated then it's worth. If HTTPS is required, then a certificate with www will always get in the way, get a non-www and add a subject alternative name, or get a wildcard. It is much, much easier to redirect all non-www traf…
No matter what you have to support both www and the straight domain, because different users will try different methods to get to your site and you don't want to lose traffic. Because you have to set up both no matter what, I don't see any reason why supporting WWW as the canonical domain for webpages is going to add any complications, and as I explained above it solves a ton.
In addition, the SSL stuff is irrelevant. You can use "www" under a wildcard cert just as easily as you can "app" or "dashboard", and if you're doing it right you're going to need to setup SSL on both anyways. Why does choosing WWW make it more complicated, and how will a "www" certificate get in the way?
Re: To www or not to www?
#17Is there any downside to having both point to the same place?
No as long as you 301 to one of them.
Re: To www or not to www?
#18Just map both to the same site. Problem solved.
Google might categorize it as duplicate content. So you should always pick a main URL and redirect from the other version to the main URL.
Re: To www or not to www?
#19Is there any downside to having both point to the same place?
You mean having both serve the same content? Yeah, the downside is SEO. Google picks up both versions and labels it duplicate content. You can put a canonical meta tag on each page, but as I understand you lose a few percent of the page's value. 301 redirect is the only way to conserve all of the value. Not an expert, just repeating stuff I've been told by our SEO guys.
According to Matt Cutts, who works with the Google Search quality team, you actually lose some of the link value passed through a 301 redirect.
Re: To www or not to www?
#20As a technical person, I can recognize a URL when I see it and prefer the non-www version for brevity's sake. But many non-technical people cannot understand if something is a website URL without the WWW in front of it. It's probably best to add WWW if your target audience is normal humans.
that may have been the case 5 years ago, but i think technical literacy has gone up, and anything ending in .com .net or .org will be recognized as a website. Most people under 30 would recognize any name.tld as well since twitter use has popularized url shorteners with unusual tld.