View Full Version : What is the different between http://www.example and http://example.com
idandone
12-11-2008, 04:16 AM
Hi Guys,
What is the different between http://www.example.com and http://example.com?
I'm looking for technical explanation and also want to understand the SEO affects.
In addition, what happen when I promote a site with inbound links to
"http://www. example . com" and "http:// example . com".
Does the link juice drain to one URL or two different ones?
Thanks
incrediblehelp
12-11-2008, 01:02 PM
Pick one as your main domain that you want to internally link to and you want external websites to link to. Usually people pick the www one. Then 301 redirect the non-www to the www.
You do this to avoid duplication/canonicalization issues with the search engines.
sharonjackson
12-11-2008, 06:47 PM
Search engines see
www.yourdomain.com and
yourdomain.com
as TWO DIFFERENT pages. I use an .htaccess direction to send the non-www one to the www one.
i.e.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com
RewriteRule (.*) http://www.yourdomain.com/$1 [R=301,L]
ErrorDocument 404 http://www.yourdomain.com
The only place this does not work well is on older servers (?) where the host directory is
http_docs or where a previous webmaster has built some weird configuration. Maybe someone else can respond to that.
usmanz
12-11-2008, 06:58 PM
I never bothered about that and I never had any issue with search engines.
Aren't search engines smart enough to know yourdomain.com and www.yourdomain.com are same?
sharonjackson
12-11-2008, 07:10 PM
Well, I have done studying on this specific issue and that is what I learned.
It is a simple enough fix. If you don't believe me, perhaps you could believe the expert who has already commented here...the guy with over 7000 posts.
I would probably listen to him.
SemAdvance
12-11-2008, 07:13 PM
I never bothered about that and I never had any issue with search engines.
Aren't search engines smart enough to know yourdomain.com and www.yourdomain.com are same?
No
The issue is known as a canonical URL issue. When Google sees links to your site in various forms it stores those links and indexes the pages it finds by following those links.
They see http://www.examplesite.com and all the links to it and scores those links and assign PageRank
Next they see http://examplesite.com and all the links to it and scores those links and assigns PageRank
They can also see www.examplesite.com and all the links to it and scores those links and assigns PageRank
As you can see the site then appears as duplicate content and also having this error dilutes your sites true PageRank.
You may not have noticed a problem but that is often due to lack of a very competitive category or competitors with little or no SEO work done.
People forget there are 1,000,000,000s of other sites beyond their own backyard, and what effects one, may or may not effect another.
amnesia
12-11-2008, 08:00 PM
idandone, DNS works like this:
<host>.<domain>.<tld><root>
Where <root> is a dot (usually left out), <tld> is your top-level domain (.com, .net, etc), domain is your actual domain, and <host> is a machine in that domain. Lookups are done by finding authorative servers from right to left. A fully qualified example would be:
Example Web Page (http://www.example.com). or accounting.example.net.
'www' - not by rule but by tradition - is classically the machine name given to a domain's web server (just as the mail server is classically named 'mail', ftp server is 'ftp' and so on). If the sysadmin had been cheeky and named the server 'fart', you'd access the site via http://fart.example.com/ and Example Web Page (http://www.example.com) would be an invalid lookup (unless aliased).
The domain itself with no host (example.com) should really not have a record associated with it, and some hardcore DNS geeks would tell you it is bad form to do so. Technically a lookup on 'example.com' should return an error. But it's very common these days to alias the domain to the web server for convenience.
Whether the search engines treat them as separate sites or not is probably determined by whether they used a CNAME or an A record in the domain's resource file, and also probably varies from bot to bot. It's doubtful that the protocol is taken into consideration as SemAdvance suggested, but I suppose some very poorly written bots might include it.
But the bottom line is it certainly makes no sense to have multiple URLs point to the same resource though, and you should definately use URL rewriting to ensure all of your URLs become something consistent when they are accessed.
amnesia
12-11-2008, 08:16 PM
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com
RewriteRule (.*) http://www.yourdomain.com/$1 [R=301,L]
ErrorDocument 404 http://www.yourdomain.com
The only place this does not work well is on older servers (?) where the host directory is
http_docs or where a previous webmaster has built some weird configuration. Maybe someone else can respond to that.
It has nothing to do with having an older server and the document root is completely irrelevent. The only time this won't work is if a) you aren't running Apache, and b) you don't have mod_rewrite installed.
More importantly that rewrite is pretty sloppy and leaves a lot of holes, here's a better way:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://www.example.com/$1 [L,R=301]
carol
12-11-2008, 08:34 PM
Great, but what if you are on a shared Windows server? Are we out of luck??
ron angel
12-11-2008, 08:36 PM
Pick one as your main domain that you want to internally link to and you want external websites to link to. Usually people pick the www one. Then 301 redirect the non-www to the www.
You do this to avoid duplication/canonicalization issues with the search engines.
I have found the simple way around this is to use the full
SS Richard Montgomery matter (http://www.ssrichardmontgomery.com) on all internal & external links always.
amnesia
12-11-2008, 08:42 PM
Great, but what if you are on a shared Windows server? Are we out of luck??
Apache runs on Windows too. In fact it runs on most platforms.
amnesia
12-11-2008, 08:51 PM
What this is . . . is an example of the Search Engines to properly index the Internet. There is absolutely no need for a search engine to treat the variations differently. When a Internet User enters a URL or a
They *should* be treated differently because they *are* different. Example Web Page (http://www.example.com/index.html) and Example Web Page (http://example.com/index.html) are technically DIFFERENT resources, regardless of if you've configured your web server to load the same document for both URLs.
Think of it like having an 800 number and local number. You still have the same people answering the phone, but two physically different numbers to get to those people.
So a bot should most definately NOT treat two different URLs as the same resource, though an intellegent bot would certainly be able to detect duplicate content and react accordingly.
amnesia
12-11-2008, 09:45 PM
But, it is not example web page and example web page! It is all the variations pointing to a single web page, unless you carry the address further to specify the actual page. If datajam's Internet: Web Site Promotion (http://www.djam-promo.com) Http://djam-promo.com and djam-promo.com all lead to my default home page, then the Search Engines should treat them as the same.
Yes I agree that "http://djam-promo.com" and "djam-promo.com" should be treated the same, because they ARE the same, and the bots will treat them the same. The protocol is not part of your domain and despite the fact that you can happily type domain names in your browser bar without it does not mean anything. Your browser simply uses the default protocol (usually HTTP) if you leave it out. You are simply confusing different components of a URL with different components of a hostname/domain name. A URL is not a domain name and a domain name is not a URL.
What I am saying is that "www.djam-promo.com" is not the same as "djam-promo.com", even if they happen to point to the same resource. It doesn't matter if the returned content from both requests is identical, since they are different URLs they are technically different resources, and it would be programmatically ignorant to treat them otherwise. From a client standpoint, it could be the same file on two distinctly different servers, which means it's not the *same* resource even if it's a *duplicate* resource. Certainly search engines should be (and most are) smart enough to detect duplicate content though, which is how they would treat such an instance.
amnesia
12-11-2008, 09:57 PM
And . . .
If your browser works the same as mine, it does not matter if I use datajam's Internet: Web Site Promotion (http://www.djam-promo.com) datajam's Internet: Web Site Promotion (http://djam-promo.com) or djam-promo.com it takes me to the same place. Shouldn't a Search Engine be smart enough to do the same? Don't you r
It has nothing to do with how your browser works. The fact that "http://www.djam-promo.com" and "http://djam-promo.com" serve you the same page has to do with how your *server* is configured. Your browser just requests the resource and renders the reply.
getmea
12-12-2008, 12:42 AM
It has nothing to do with having an older server and the document root is completely irrelevent. The only time this won't work is if a) you aren't running Apache, and b) you don't have mod_rewrite installed.
More importantly that rewrite is pretty sloppy and leaves a lot of holes, here's a better way:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://www.example.com/$1 [L,R=301]
My site (http://getmea.net) runs on an Apache server and sharonjackson's redirect works.
Question: can you please elaborate on the "holes"? I'm not questioning you; I'd just like to understand the code.
Thanks
freetutes
12-12-2008, 03:51 AM
It is up to you to decide whether you have the www or not. Most people prefer their domain name with www.
As incrediblehelp says you should do a redirection from non www to www or from www to non www. This is to avoid duplication issues with search engines. If you have backlinks to www.example.com and example.com and if you have done the 301 redirection for www or non www version then you will have no problems.
hairtrader
12-12-2008, 04:36 AM
HI,
Interesting topic i have just been involved in actually with my hosting comany. I beleive from the way i read it as long as you set your Google webmasters account setting to a "preffered domain" in your account (for example Hair Products, Hair Straighteners, Tigi, Bed Head, Fudge, Joico, T3 (http://www.hairtrader.co.uk) rather than Hair Products, Hair Straighteners, Tigi, Bed Head, Fudge, Joico, T3 (http://hairtrader.co.uk) ) then google see's it as the same site and auto re-directs all ranking etc to the preffered one.
As standard it is set to "Not preferred" so then a re-direct is required.
The only down side is this only works with google so the other search enignes will possibly see it different.
Thanks
Andy
hairtrader
12-12-2008, 04:40 AM
Sorry for title on links, did not think when i entered the url
inertia
12-12-2008, 05:48 AM
Great, but what if you are on a shared Windows server? Are we out of luck??
I have the same problem as all the sites we develop are asp. Were in the process of moving to dedicated hosting with Isapi.
amnesia
12-12-2008, 09:13 AM
My site (http://getmea.net) runs on an Apache server and sharonjackson's redirect works.
Question: can you please elaborate on the "holes"? I'm not questioning you; I'd just like to understand the code.
Thanks
Yes it works, but only for urls that match the domain by itself, and only in a case-sensitive fashion. "Holes" was maybe a poor choice of words, I simply meant it leaves out a lot of other instances. With her rule, http://MyDomain.com/ would not get rewritten, and neither would http://site.mydomain.com/. By using:
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]
you are saying that anything that does not match http://www.example.com/ (non case-sensitive) will be rewritten, so it covers all bases.
markrchisholm
12-12-2008, 09:28 AM
What this is . . . is an example of the Search Engines to properly index the Internet. There is absolutely no need for a search engine to treat the variations differently. When a Internet User enters a URL or a variation of a URL into their browser, it should take them to the default home page for the URL. A Search Engine should treat such the same. But, . . . It seems that Search Engines are too busy trying to dictate how information should be presented on the Internet, to index the Internet.
When the Internet Community stops building web sites to chase search engine rankings, maybe Search Engines will find a method to index the Internet uniformly and save a whole bunch of us a lot of money. Authors should not be expected to write their books to satisfy search engines and neither should anyone have to write an document to do so.
I am not really anti-search engine, just do not agree with the need to prepare a site to comply with search engine direction only to have spam sites still achieve higher rankings. None of the Search Engines do a competent job of indexing the Internet. Most cost us a small fortune in our efforts to to play their game. You would think, somewhere along the line one of them would come up with the ability to index the Internet as well as a local phone book!
datajam's Internet: Web Site Promotion (http://www.djam-promo.com) datajam's Internet: Web Site Promotion (http://djam-promo.com) djam-promo.com
'example .com' should rightfully be treated different to 'www.example .com' as the 'www' is a sub domain of the domain (just as 'subdomain.example .com' is another subdomain). Just because most servers are set up by the hosting company to point to the same resources doesn't mean that this is always the case or correct.
The problems that can arise from not addressing this issue is not just a split of pagerank/link juice but also duplicate content issues caused by different caches of the same page (and they will not always be synchronised).
This is not meant as a dig, but if you are inexperienced enough the think differently then you will probably not realise the benefit that you will see form fixing the issue.
A simple test is to firstly view both the pages, do they a different page rank? Then view the cache of both pages, do they share a common reference address, do they have the same date?
A simple fix is to set your preferred domain in Webmaster Tools, then look into a mod_rewrite fix.
activeco
12-12-2008, 06:09 PM
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]
you are saying that anything that does not match Example Web Page (http://www.example.com/) (non case-sensitive) will be rewritten, so it covers all bases.
True. So will all other subdomains be unnecessary rewriten to www.
For the rest I agree with you; there should be a difference between domain and www.domain, just as is with any other subdomain, regardless of if they provide the same content.
deepsand
12-12-2008, 07:51 PM
'example .com' should rightfully be treated different to 'www.example .com' as the 'www' is a sub domain of the domain (just as 'subdomain.example .com' is another subdomain). Just because most servers are set up by the hosting company to point to the same resources doesn't mean that this is always the case or correct.
The "www" prefix designates a service type, in this case a web server; it is not a sub-domain.
A single domain may provide multiple services; e.g., both "www" and "ftp" are frequently provided. And, for such, but a single DNS record is required, with the CNAME (Canonical Name) record containing the various aliases.
getmea
12-13-2008, 12:42 AM
Yes it works, but only for urls that match the domain by itself, and only in a case-sensitive fashion. "Holes" was maybe a poor choice of words, I simply meant it leaves out a lot of other instances. With her rule, http://MyDomain.com/ would not get rewritten, and neither would http://site.mydomain.com/. By using:
RewriteCond %{HTTP_HOST} !^www\.example\.com [NC]
you are saying that anything that does not match Example Web Page (http://www.example.com/) (non case-sensitive) will be rewritten, so it covers all bases.
Thanks for the Redirection 101 class :D
activeco
12-13-2008, 04:04 AM
The "www" prefix designates a service type, in this case a web server; it is not a sub-domain.
A single domain may provide multiple services; e.g., both "www" and "ftp" are frequently provided. And, for such, but a single DNS record is required, with the CNAME (Canonical Name) record containing the various aliases.
Not quite so. The 'service' is known as a protocol and there is no www protocol. What you refer to is 'http' (or possibly to the early conventions, see below).
All subdomains including www (you can have completely different site on 'www') could have its own IP addresses, host or A records or be aliases (canonical or CNAME records) pointing to any other (sub)domain, including second level domain as well as a completely different domain (don't abuse this).
If e.g. Apache server use name based virtual hosts, additional configuration directive 'ServerAlias' is needed for this redirection to work.
A short Google guide (http://www.google.com/support/a/bin/answer.py?hl=en&answer=48090) to DNS.
As for why www: It was a convention (http://www.w3.org/Provider/Style/www.html) from early www ;) days.
amnesia
12-13-2008, 02:18 PM
The "www" prefix designates a service type, in this case a web server; it is not a sub-domain.
A single domain may provide multiple services; e.g., both "www" and "ftp" are frequently provided. And, for such, but a single DNS record is required, with the CNAME (Canonical Name) record containing the various aliases.
It is neither a subdomain nor a service, it is a hostname. In the fqdn 'www.example.com', the 'www' part is the name of the machine. It has nothing to do with the service, I could just as easily call it 'website.example.com' or anything else, and I could very happily point 'www.example.com' to my accounting server or 'youdontunderstanddns.example.com' to the main web server. I don't even have to have a machine called 'www' in my network if I don't want. It's tradition, but by no means a law. The service that you are requesting is determined by the protocol, not the name of the host you are connecting to.
amnesia
12-13-2008, 02:33 PM
I want the Search Engine to respond to the average Users browser, not the variations of my domain name. Unless my server is set up to show sub.domains, multiple domains, or other such as .https, .mail, or .ftp why should the Search Engine care at all? I want to have all variations of my domian name point to one page, without being penalized for duplicate content or any other reason. And, why can't I?
Because, as it's been said several different ways by several different people: it's invalid to treat two different hosts as the same resource. Different hosts are different hosts, regardless of if they serve the same content. If you want to avoid duplication penalties, use URL rewriting.
I built my first site before there was a Google. I have been on the Internet since before Windows. So, why should I or anyone else have to march to Google's or any of the others drums to have my sites appropriately indexed?
It has nothing to do with Google. It has to do with the way the Internet works, which I would think you would understand since you apparently have been using the Internet since before there was a world wide web and therefore you are familiar with UUCP and saw the birth of DNS.
activeco
12-13-2008, 02:50 PM
In the fqdn 'www.example.com'...
The fqdn is 'www.example.com.' ;)
amnesia
12-13-2008, 03:07 PM
The fqdn is 'www.example.com.' ;)
nicely caught :)
deepsand
12-13-2008, 07:49 PM
It is neither a subdomain nor a service, it is a hostname. In the fqdn 'www.example.com', the 'www' part is the name of the machine.
While hostname and domain name are frequently used interchangeably, there are in fact technical differences between the two.
A hostname identifies a physical resource; a domain name, a logical one.
Depending on the network, and the service(s) provided by a particular device, its hostname may or may not contain a valid domain name.
See Hostname - Wikipedia, the free encyclopedia (http://en.wikipedia.org/wiki/Hostname)
betterlanguages
12-15-2008, 08:39 AM
We've had problems with this issue with http//betterlanguages.com and http//www.betterlanguages.com, when we researched the issue we realised that the problem was caused by the way our hosting is set up. Our web developer has put redirects from http//betterlanguages.com to the www version. We also took the precaution of providing Google webmaster tools with sitemaps for both versions, you can link the two and tell Google which is the primary domain. In theory this should solve the problem, at least with Google. Anyone else tried this?
Cheers
Mike
betterlanguages.com translation agency (http://www.betterlanguages.com)
deepsand
12-15-2008, 06:40 PM
We've had problems with this issue with http//betterlanguages.com and http//www.betterlanguages.com, when we researched the issue we realised that the problem was caused by the way our hosting is set up. Our web developer has put redirects from http//betterlanguages.com to the www version.
Are you saying that requests for "betterlanguages.com" previously yielded a 404?
betterlanguages
12-16-2008, 07:45 AM
Are you saying that requests for "betterlanguages.com" previously yielded a 404?
Hi deepsand, no both versions of the site (with and without www) previously appeared in the SERPS, we don't appear to have had any penalty for duplicate content, at least on Google. Posting sitemaps for both and then telling Google that www is the preferred domain seem to have done the trick. Our concern was that the current version of the site now only shows with www, and we didn't want to lose links from betterlanguages.com, hope this clarifies.
Kindest regards
Mike
This is the situation with canonical links. Setting a preferred domain simply tells Google that when in doubt, it should display one domain over the other. However, you may still have link juice that is lost if Google sees any difference between the two domains. The only fix to prevent the loss of link juice is to use a 301 redirect from the non-preferred domain to the preferred domain. This guarantees the pages get the maximum possible link juice, since Google acknowledges that link juice carries through permanent redirects. There is no such guarantee with using a preferred domain.
getmea
12-17-2008, 01:18 AM
We've had problems with this issue with http//betterlanguages.com and http//www.betterlanguages.com, when we researched the issue we realised that the problem was caused by the way our hosting is set up. Our web developer has put redirects from http//betterlanguages.com to the www version. We also took the precaution of providing Google webmaster tools with sitemaps for both versions, you can link the two and tell Google which is the primary domain. In theory this should solve the problem, at least with Google. Anyone else tried this?
Cheers
Mike
betterlanguages.com translation agency (http://www.betterlanguages.com)
I think I am sold that same web hosting companies may set up one's site differently every time. For example, I needed to add the above HTACCESS code for my site Getmea.Net (which is hosted for about 2 years), but none required for my newer site 44Skate.com (hosted less than one month). The only "common" HTACCESS code in both is the AddHandler function for treating HTML as PHP.
Same Web Host company...
aloknath
12-17-2008, 04:01 AM
HI, i also using www. but never faced any problem without www. but it's true that 301 redirects to avoid duplication issues..
deepsand
12-17-2008, 01:16 PM
Hi deepsand, no both versions of the site (with and without www) previously appeared in the SERPS, we don't appear to have had any penalty for duplicate content, at least on Google. Posting sitemaps for both and then telling Google that www is the preferred domain seem to have done the trick. Our concern was that the current version of the site now only shows with www, and we didn't want to lose links from betterlanguages.com, hope this clarifies.
Well, if your site was accessible both with and without the "www" prefix, then that simply indicates that the host simply followed the standard procedure of having both URLs point to the local hostname for your web server, so as to avoid throwing 404s to those requests that did not precisely match said an entry in the CNAME record.
It should, therefore, be understood that the problem here under discussion is not caused by ones host, but instead owes to instances of both forms of the URL appearing on site pages, be they on your own site or on those of other sites (IBLs.)
deepsand
12-17-2008, 10:40 PM
Not quite so. The 'service' is known as a protocol and there is no www protocol. What you refer to is 'http' (or possibly to the early conventions, see below).
Just as the distinction between hostname and domain name is one with an important difference, so too is that between service and protocol.
A service is a function or set of functions performed by one or more processes running on a server. A protocol is a set of rules whereby processes communicate with one another. That some service names are identical to related protocols is a matter of convenience, not of necessity.
For example, "ftp" is both a service and a protocol, whereas the "www" service is not a protocol. And, while the "http" protocol is common to "web" services, it is far from being the only protocol employed by such services.
It is by convention that "www" is used as a reference to the services performed by a web server, just as it is by convention that "ftp" is used to refer to those performed by an ftp server. Under this convention, it is assumed that, when employing the "www" prefix, one is requesting the service of a web server; absent such convention chaos would prevail, as users would need to keep track of a plethora of the different prefixes employed by each server whose services they desired.
And, given that the overwhelming portion of servers currently extant are web servers, such convention leads to the practice of hosts being configured so as to, in the absence of a service prefix, default to the "www" prefix when resolving to a specific hostname.