Many people are confused by this tag and they misuse it. If the tag is used, it must specify a canonical link for that particular page, not the website in general.

The right way to solve this problem is by adding three lines to the server .htaccess file.

Many people are confused by this tag and they misuse it. If the tag is used, it must specify a canonical link for that particular page, not the website in general.

The right way to solve this problem is by adding three lines to the server .htaccess file.

• RewriteEngine on
• RewriteCond %{HTTP_HOST} !^www\.mydomain\.com
• RewriteRule (.*) http://www.mydomain.com/$1 [R=301,L]

(Obviously, leave out the bullets.) In this example, any request for mydomain.com will be changed to www.mydomain.com, and the canonical problem is solved for the entire website without editing each page.

Yes, that code covers the issue of duplicate content in URLs with and without "www," but there are lots of other potential issues for which rel="canonical" is the best response.

But that quote from Bing "Pointing a rel=canonical at the page it is installed in essentially tells us “this page is a copy of itself." Doesn't make sense to me. My understanding is that the message it's supposed to send is more like "If there's any question as to which URL containing this or similar content is to be treated as canonical, please make it this one."

@bobpars - we're talking about advanced canonicalization issues here, not www. vs non-www. Think outside the basics - large e-commerce sites generate tons of duplicate pages due things such as action tracking parameters, dynamically generated product suggestions, special promotions, affiliate links, etc, etc. In those cases, a server side redirect isn't possible, and you should use the rel=canonical tag.

@qwerty - exactly. They seem like entirely different interpretations of the tag, which I found suprising and newsworthy, especially for such a well established & widely used tag.

I was very surprised to read a couple of Duane Forrester's comments regarding Bing's use of rel="canonical" (thanks for pointing this out, Nick).

The first - "that it was never intended to appear across large numbers of pages" - is counterintuitive for exaclty the reason just described by Nick.  Namely, the sites with the biggest canonicalization issues are likely to big ecommerce sites with a large number of pages.  Sure, you can use rel=canonical on a ten-page brochure site, but that's exactly the same sort of site that you should be deal with canonicalization issues better by using other mechanisms.

The second is Duane's advice not to point a rel="canonical" page at itself.  First of all, I would use the same search engine voice Duane does to say that what Bing should think of this as "this is the right URL for this page - thanks, noted!" rather than the redundancy that is suggested by "this page is a copy of itself."

More importantly, there's no realistic way of implementing rel="canonical" in an enterprise environment unless it ends up pointing at itself.  If I wish to inform the search engines that site.com/page.html is the canonical page for site.com/page.html?ref=junk, then realistically I need to encode this rel=canonical statement on page.html, not just when page.html is expressed as page.html?ref=junk - or any possible number of non-canonical forms of the URL.

Let's hope Bing gets their act together on this - or even (gasp!) has a conversation with Google about aligning the search engines' interpretation of this pretty useful tag.

Let's not forget the possibility of consolidating link popularity from all the inbound links using tracking codes, e.g., linking in to http://www.example.com/index.html?tracking=abc123. Without a Canonical Link tag on that page to the effect of, {link rel="canonical" href="http://www.example.com/"}, it would be much harder (impossible?) to disambiguate all the versions of that page with the variations of the tracking code for the purposes of link juice.