Summary

  • In February 2009, Google offered publishers a small HTML declaration for duplicate pages: rel="canonical" could name the URL they preferred in search. The company's own announcement called it a strong hint, not a command. The publisher could nominate; the indexer would still choose.
  • RFC 6596 later formalized the relation and named its dangerous edge. If page two of an article points to page one, an indexer may treat the second page as a duplicate and disregard its distinct text. A tidy URL label can become an editorial eraser.

The webmaster got a ballot

A product page might have one clean address and several unruly cousins. A category filter adds a parameter. A tracking campaign adds another. A session identifier produces yet another URL for essentially the same goods. Before the search engine could decide which one to show, the publisher had to tell it which address was meant to stand for the set. Google's 12 February 2009 announcement offered a line in the duplicate page's HTML head: <link rel="canonical" href="...">.

The line looked like a nameplate. It was actually a request to the index. Google said properties such as link popularity could be consolidated on the preferred URL and search results could show that version. A visitor following the duplicate address was still asking for that page; the tag was not an HTTP redirect. Its immediate audience was the machine sorting pages for discovery.

Google put the limit in its launch interview. Was the tag a hint or a command? A strong hint, the company answered, to be weighed with other signals. This was a bargain between two parties with different inventories. The publisher knew which URLs it had made and which one it wanted to promote. The indexer had crawls, links, redirects and its own duplicate clusters. The publisher could send a ballot. It could not count the votes.

The 2009 promise acquired a longer reach

The original Google post used a shop selling Swedish fish. One URL held the product; others added category, tracking or session parameters. That example matters because it describes duplication generated by the site's own machinery, not a search engine inventing a second page. The site had multiplied its address space and wanted one public representative.

The post also records a change that is easy to smudge in retrospect. Its original answer said a canonical suggestion could work across subdomains but not between wholly different domains; for a move between domains, it recommended a permanent redirect. An update dated 17 December 2009 said cross-domain canonical support had arrived. The launch and the later extension are different dates. The distinction is the history of a tool expanding its jurisdiction, not evidence that the original promise was unlimited.

In April 2012, RFC 6596 gave the relation a formal description: a referring resource may designate a preferred IRI for duplicative content, or for content contained within a larger target. It described the HTML element and an HTTP Link header, which can carry the declaration for resources that do not have an HTML head. It also spelled out potential behavior: an application may process only the target, transfer link properties and display the target address. The RFC was informational; its words described a relation and consequences, not an order to every crawler.

Where the label can eat the story

The RFC's multipage example is the useful stress test. Suppose page one and page two each hold different sections of a long article, while a view-all page contains both. Pointing each component to view-all has a coherent claim: the target contains the component's text. Pointing page two to page one tells the indexer that the first page represents material it does not actually contain. RFC 6596 warned that page two could then be marked duplicative and its material disregarded. One copied template line could make the middle of a story vanish from search processing while every page still loads in a browser.

The same document advises one canonical relation per resource and warns against targets that return errors, redirect permanently, or themselves point elsewhere. For a malformed chain or a missing target, an application may ignore the declaration and use its own heuristics. Here the familiar word “canonical” is almost a joke at the operator's expense: it sounds like an authority stamp, but its receiver can decline the stamp and reach for another record.

Google's current account of canonicalization keeps the division visible. Google clusters similar pages, chooses a representative using signals, and may select a different page from the one the publisher proposed. That account describes today's practice; the 2009 launch post already stated the essential limit in plainer language. The publisher's preference is an input to a running index, not a deed to a search result.