28th February 2009
URL Canonicalisation and Normalisation
I’ve been meaning to write about the new rel=canonical tag, which was proposed by Google, Yahoo and Microsoft on February 12. I managed to squeeze some thoughts on it into my presentation and workshop at SES London, and I’ll be speaking more about it at SES New Yorknext month, but before I blogged about it I really wanted to write more about URL Canonicalisation and Normalisation in general.
Canonicalisation or Canonicalization? Normalisation or Normalization?
I’m British, so I say Canonicalisation and Normalisation. Your mileage may vary.
What is URL Canonicalisation?
We’re talking about search engines here, so let’s try a definition that applies generally, but leans towards search:
- URL Canonicalisation
- involves taking a set of different URLs that all serve or lead to the same or similar content, and applying rules to select one URL from that set under which that content should be indexed or presented.
I’ve hyperlinked the terms I think are important to more detail below, but before we go into them let’s try defining URL Normalisation.
- URL Normalisation
- involves taking a single URL and applying a normalisation algorithm to produce a standard form for that URL.
Others define normalisation and canonicalisation as all part of the same thing, but I like to think of them as separate processes. To my way of thinking:
- you can normalise a single URL but you can only canonicalise a set of URLs
- an un-normalised URL will serve the same content as a normalised URL, because it’s the same URL
- all indexed URLs are normalised; not all are canonicalised
- normalisation occurs before canonicalisation
Now let’s go back and look at those hyperlinked terms in more detail.
This is the key to canonicalisation and why it’s needed: the same content is being presented at a number of different URLs. By different URLs, I mean those URLs are really different to each other – they could potentially show different content but (in this case) they don’t. Here is an example set of URLs:
If each of the above URLs served the same, or essentially the same, content, it’s likely that they would be canonicalised to fewer URLs – possibly only one. If they each served completely different content, then it’s much less likely that this canonicalisation would take place. By “or lead to”, I mean that the URL may redirect (e.g. with a HTTP 301 or HTTP 302 redirect) to another URL.
The rules for canonicalisation vary from engine to engine and time to time. Here are a few examples of when canonicalisation will take place …
- If www and non-www versions of the URL exist, then canonicalise
- If the same base URL is seen with different numbers of query parameters, then canonicalise
- If the filename component of the URL matches a known set of index pages (e.g. index.*, default.*, etc.) then canonicalise
- If the home page (“/”) redirects to another page, then canonicalise
… and here are some examples of how canonicalisation will take place:
- Choose the URL with the highest Pagerank (or similar link-based or other off-page criteria)
- Obey rel=nofollow webmaster hint
- Choose the simplest URL (e.g. the shortest URL, or the one with fewest query parameters)
Sometimes only one URL from a set will be indexed, which means that it will always be the candidate URL to be presented in a set of search results. At other times multiple URLs may be indexed, even though they are known to be part of the same canonical set. One of these URLs will be selected to appear in a given set of search results. The URL that is selected may vary (for example, by query or by searcher location) – but only one will ever appear on a given search results page.
Normalisation operates on a single URL rather than on a set of URLs. That single URL may need be supplemented with other data in order for normalisation to take place. For example, un-normalised URLs may be relative or absolute. A normalised URL will always be a fully-qualified absolute URL so, along with a relative URL, the containing URL or tag will need to be known in order for normalisation to take place.
Like canonicalisation rules, the normalisation algorithm may vary from engine to engine and time to time. However, it’s much less likely to vary. Here is an example of the kind of things that are done during normalisation:
- convert a relative URL to an absolute URL
- convert the scheme and the host name components of the URL to lower case
- remove the port component if it matches the default port
- escape characters that should be represented as octets (or a +)
- unescape octets that are better represented as plain characters
- convert all escape sequences to upper case
Here are some examples of each operation:
- In http://www.silverdisc.co.uk/ , a link to “/contact.html” would be normalised to http://www.silverdisc.co.uk/contact.html
- HTTP://WWW.SILVERDISC.CO.UK/contact.html would be normalised to http://www.silverdisc.co.uk/contact.html
- http://www.silverdisc.co.uk:80/contact.html would be normalised to http://www.silverdisc.co.uk/contact.html, because 80 is the default port for HTTP connections.
- http://www.silverdisc.co.uk/contact.html?name=Alan Perkins would be normalised to http://www.silverdisc.co.uk/contact.html?name=Alan+Perkins or http://www.silverdisc.co.uk/contact.html?name=Alan%20Perkins, because a space is not a valid character in a URL.
- http://www.silverdisc.co.uk/cont%61ct.html would be normalised to http://www.silverdisc.co.uk/contact.html, because %61 is better represented as the character “a” in a URL.
- A %2a in a URL would be converted to %2A for consistency
That completes this introduction to URL canonicalisation and normalisation. In the next post, I’ll look at rel=nofollow.