As 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.
With "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 service and makes adding those services easier down the line.
This. Don't use your zone apex name as your main site. You will regret it. If visitors come to the non-www version of the site send them a 301 redirect.
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).
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.
There's no penalty for redirecting an entire root-level domain to a subdomain, as long as your sitemap and internal linking strategy all point to the subdomain.
From Google's perspective, the problem with 301s is that they take longer to load (since you've got to request two separate URLs) and they make your URL structure less stable. Neither of those is a problem if you make it clear to Google that your content belongs on a subdomain.
I'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.
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?
22 comments
[ 3.2 ms ] story [ 65.8 ms ] threadBut 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.
Problem solved.
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 service and makes adding those services easier down the line.
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).
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.
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.
From Google's perspective, the problem with 301s is that they take longer to load (since you've got to request two separate URLs) and they make your URL structure less stable. Neither of those is a problem if you make it clear to Google that your content belongs on a subdomain.
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.
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?