It looks like there’s a lot of momentum behind
rev="canonical" now – and all built up within the span of about forty-eight hours. So, while I disagree with the use of “canonical” for semantic reasons and
rev for the potential of mass misunderstanding and improper implementation, I think I’ll bite the bullet on this one for now, but time will tell what the community ultimately decides.
And all without any special WordPress plugin. For the ID, I’m simply using the WordPress post ID, which means that, if I change to another blogging tool in the future, I will need to maintain my indexes. Note that I’ve implemented it with both the popular
rev="canonical" and my preferred
Chris Shiflett posts about the need for an HTTP header. I think this is also a good idea, for the same reasons he mentions. Chris’s original recommendation is for an
X-Rev-Canonical header, but Stephen Paul Weber mentions the
Link header. I think the
Link header is the right way to go about this, since it offers an HTTP analogue of the HTML
Link is an IETF proposal by Mark Nottingham that is still in the Internet-Draft stage, going through the IETF process for standardization, but it’s current, which is a good thing. If the community chooses to use it, though, it’s interesting to note that that it states:
bq. Applications that don’t merit a registered relation type may use an extension relation type. An extension relation type is a URI that, when dereferenced, SHOULD yield a document describing that relation type.
This means that one should not simply put “canonical” as the value for
rev. Instead, it would be more proper to use something like “http://revcanonical.appspot.com/#canonical” until “canonical” is accepted as a registered IANA relation type. I wonder if the same is technically true of the
rev attributes in HTML.
For now, I’ve decided to cover all bases in my HTTP headers, as well, and you can see this by making a HEAD request to any blog post on my website, as seen in the following: