The Canonical Tag

The canonical tag is a link element with rel="canonical" that says which URL represents a page's content. The thing to know about it from the first line: indicating a canonical preference is a hint, not a rule. Google may choose a different page. This lesson covers the syntax, the two ways to supply it, the rules from the documentation and the traps, including pagination and PDFs.

The wider picture of duplicates is in the lesson on duplicate content. Here it is the tag itself. The basis is Google's page on consolidating duplicate URLs.

Syntax

<!-- In the head of the duplicate /dresses/green-dresses?sort=price -->
<link rel="canonical" href="https://example.com/dresses/green-dresses" />

<!-- The same on the canonical page itself (self-referential canonical) -->
<link rel="canonical" href="https://example.com/dresses/green-dresses" />

Google recommends adding the same self-referential element to the canonical page itself. If it has a mobile variant at a separate URL, a rel="alternate" element with a media condition is added as well.

Placement rules

• Only in the head. The element is only accepted if it appears in the head section of the HTML, so at least the head must be valid HTML;
• absolute URLs. Relative paths are supported but can cause problems, for example if a test site is unintentionally allowed to be crawled. A good example is a full address with protocol and domain;
• one method, not two. The HTML element and the HTTP header are both allowed, but using both at once is more error prone: one can give one URL and the other a different one. Choose one;
• JavaScript. If the element is added by script it must be injected properly; better to set it in the source HTML and not change it with script. More in the lesson on JavaScript and SEO.

The HTTP header: the only route for PDFs

If you can change the server configuration, the canonical URL is given with a Link response header with rel="canonical". It works for non-HTML documents such as PDF files, which the HTML element cannot do. A typical case is content published in several formats, each at its own URL: for a .docx file you can return a header pointing to the PDF version.

HTTP/1.1 200 OK
Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"

As with the element, absolute URLs are needed. Google supports this method for web search results only.

Canonical and redirect: not about "weight"

A common comparison says canonical passes "about 100%" of link weight and a 301 "90-99%". Those figures are not in the documentation, and the methods cannot be compared by them. The documentation compares them differently: a redirect and rel="canonical" are both strong signals, a sitemap a weak one. The difference is practical:

• redirect — when the duplicate should go: use it when you want to get rid of existing duplicate pages. A user no longer reaches the duplicate. For the quickest effect, use server-side redirects;
• rel="canonical" — when the duplicate must stay accessible: filters, sorting, variants;
• sitemap — all pages listed are suggested as canonicals, and Google decides which are duplicates by similarity. Convenient for large sites, but a weaker signal.

Permanent and temporary redirects differ, and that is covered separately in the lesson on redirects; chain targets are visible in the redirect checker.

Traps

• Pagination. For a sequence of pages Google says directly: do not use the first page of a paginated sequence as the canonical page; give each page its own canonical URL. Each ?page=n page is a separate page to Google, not a duplicate of the first;
• hreflang, lang, media and type inside rel="canonical" are not used for canonicalization: alternate versions are specified with other annotations, such as rel="alternate" hreflang. Language versions count as duplicates only if the primary content is in the same language;
• noindex instead of canonical. Google does not recommend using noindex to prevent selection of a canonical page within a site: it completely blocks the page from Search;
• Contradictions. One URL in the sitemap, another in rel="canonical": you should not specify different canonical URLs for one page by different methods;
• Relative paths and URL fragments (a fragment cannot be given as canonical).

What is not in the documentation

Claims that no source supports: passing "about 100%" of weight, loss "on a chain A to B to C", and "contradiction" of canonical to a noindex page as a separate rule. That does not mean the opposite is true. It means it is safer to rely on what the documentation says: a hint, the head, absolute URLs, one method, one URL per page.

How to check

1. Open the page in the page analyzer and make sure there is one canonical, in the head, leading to an absolute URL.
2. Crawl the site with the crawler: find pages with no canonical, with relative paths, and with different URLs in the header and the HTML.
3. Check that pagination pages each point to themselves.
4. Through URL inspection in Search Console compare the declared and the Google-selected canonical; in bulk, through the URL audit.
5. If Google chose another page, look for conflicting signals: redirects, the sitemap, internal links, the protocol.

Checklist

1. Canonical is set in the head, not the body.
2. URLs are absolute, without fragments.
3. One method is used: element or header.
4. The canonical page references itself.
5. Pagination pages do not point to the first.
6. PDFs and other files use the HTTP header.
7. Internal links and the sitemap lead to the canonical URL.

Mistakes

• Treating canonical as a command rather than a hint.
• Pointing every page of a paginated set at the first.
• Placing the tag in the body or breaking the head with invalid HTML.
• Giving different URLs in the header and the HTML.
• Blocking duplicates in robots.txt instead of using canonical: that is in the lesson on robots.txt and canonical.

What comes next

Next is SEO in a CMS: how to set these rules up in a content management system. The line between blocking crawling and canonical is in the lesson on robots.txt and canonical, and URL rules in the lesson on URL structure.