Canonical tag: when you need it, common mistakes and how to check

A canonical URL is the address a site owner names as the preferred version of a page. It is declared in the document head with a link element that has rel="canonical". For files that have no HTML, such as PDFs, the same information can travel in an HTTP Link header.

The limits matter. Google Search Central describes the canonical as a strong signal, not a directive. The search engine compares several clues: redirects, the rel canonical attribute, whether the URL is listed in a sitemap, internal links and HTTPS. When those clues disagree, the final choice may differ from yours.

A canonical also does not block indexing and does not stop crawling. It replaces neither noindex nor robots.txt rules. Its job is narrower: gather the signals of duplicate URLs in one address, so that links and the choice of which page to show are not split between copies.

Background reading: consolidating duplicate URLs in Google's documentation.

Duplicates are more common than they look. One page may open with tracking parameters, with a sort order or a filter, as a print version, with and without www, over HTTP and HTTPS, with and without a trailing slash. To a visitor it is one page. To a crawler it is several.

Typical cases where a canonical fits:

• Tracking parameters. An address ending in ?utm_source=newsletter shows the same content as the clean URL.
• Filters and sorting. A catalogue sorted by price is still the same catalogue.
• Print versions and other copies that live at their own address.
• Syndicated content. If you republish an article on another site, that site can point its canonical at your original. Cross-domain canonicals are allowed.
• Several paths to one page in a CMS: category plus date, a short and a long URL.

Even without duplicates, a self-referencing canonical, where a page points to itself, is considered a safe default for indexable pages. It protects against stray address variants that someone adds to a link or an ad campaign.

If an old address should disappear for good, you do not need a canonical. You need a redirect, covered next.

Both tools consolidate signals, but they behave differently. A 301 redirect moves the user and the crawler: the old address stops being available as a page of its own. A canonical leaves both addresses open and only suggests which one is the main one.

A simple rule:

1. The old address is no longer needed by people (you changed the structure, merged pages, moved to HTTPS): use a 301 redirect.
2. Both addresses must stay alive (tracking parameters, filters, print, syndication): use a canonical.
3. Not sure: first check whether the second address is needed at all. Often it appeared by accident.

A few combinations deserve a warning. A canonical that points at a URL which itself redirects makes the crawler take an extra step and blurs the signal. A canonical that points at a 404 simply does not work. A canonical and a noindex on the same page send mixed messages: one says "gather everything at that other address", the other says "do not show this one". Pick one.

The SEOAudit scanner reports noindex combined with a canonical to a different URL as its own finding, because it is a common reason a page quietly drops out of results.

The basic case. The tag sits in the head and the address is absolute, over HTTPS:

<head>
  <link rel="canonical" href="https://example.com/blog/canonical-guide">
</head>

For a PDF or another file without a head, the canonical travels in a response header:

Link: <https://example.com/files/report>; rel="canonical"

Now a frequent mistake: a relative address. It technically works, but it breaks easily when the page is reached through another host or protocol.

<link rel="canonical" href="/blog/canonical-guide">

The fixed version:

<link rel="canonical" href="https://example.com/blog/canonical-guide">

A page with tracking parameters points at the clean address:

<!-- opened as https://example.com/pricing?utm_source=newsletter -->
<link rel="canonical" href="https://example.com/pricing">

And a pair for a multilingual site. Each language version points at itself, not at another language:

<!-- on https://example.com/uk/about -->
<link rel="canonical" href="https://example.com/uk/about">
<!-- on https://example.com/en/about -->
<link rel="canonical" href="https://example.com/en/about">

If both pages carried a canonical to the English version, the Ukrainian page would be treated as a duplicate and hreflang would stop doing its job.

1. Several different canonicals on one page

This happens when both the theme and a plugin add the tag. A search engine may ignore both. A page should carry one.

2. A canonical outside the head

An element in the body is not honoured. Also check that a script does not inject the tag after load, since the scanner reads the initial HTML.

3. Relative paths and wrong protocols

A relative path, an HTTP address on an HTTPS page, or another host (www instead of the apex) creates a signal that contradicts the rest of the site. The SEOAudit scanner flags a relative canonical and an HTTP canonical on an HTTPS page separately.

4. A canonical to an unreachable address

The target should return 200, be indexable and not be blocked in robots.txt. A redirect, a 404 or a crawl block makes the tag useless. Chains where A points to B and B points to C are better collapsed to a single hop.

5. Every paginated page pointing at page one

Pages two and three of a list contain different items. If they all point at page one, the search engine may never reach the products or articles listed further on. Each paginated page normally carries a self-referencing canonical.

6. Disagreement with the sitemap and internal links

The canonical names one address, the sitemap lists another and the menu links to a third. That contradiction weakens the signal. Align all three. File requirements are covered in the sitemap.xml guide.

The scanner also reports when a canonical leads to a different path or host. That is an observation, not an error, because such variants are sometimes deliberate, for example in syndication.

A canonical rarely works alone. It has to agree with three neighbours.

Hreflang. Every language version should carry a canonical to itself and list reciprocal links to the other versions. If a canonical leads to another language, Google may conclude the alternates are not needed. The details are in the hreflang guide. The scanner checks the conflict between canonical and the hreflang set separately.

HTTPS and host. Pick one form: HTTPS, with or without www. Redirect every other form to it, and make the canonical, the sitemap and internal links use exactly that form. Certificates, the HTTP to HTTPS redirect and transport headers are covered by the security check, and their link to SEO in the article on security headers.

Sitemap. The file should list only canonical URLs that answer 200. Duplicates in a sitemap tell the search engine that those are the ones that matter.

Internal links. If most links on the site point at a variant with a parameter or without a trailing slash while the canonical names another, the signals diverge. Fix the links, not just the tag.

Other crawlers, including those that collect pages for AI search, read the same HTML. A clean canonical therefore helps beyond Google. What SEOAudit looks at for AI crawlers is described on the AI visibility page.

Start with the simplest method and add tools as needed.

By hand

Open the page, choose "View page source" and search for canonical. The same from a terminal:

curl -s https://example.com/page | grep -i canonical

For a Link header, add the -I flag and read the server response. Also test the version with parameters and without the trailing slash: it should name the same canonical address.

In Google Search Console

The URL Inspection tool shows two addresses: the user-declared canonical and the Google-selected canonical. If they differ, look for a conflict in redirects, the sitemap or internal links. This is the most reliable way to see what the search engine actually decided.

With the scanner

The SEOAudit scanner examines the page you submit: whether a canonical exists, whether it is duplicated or conflicting, absolute, not pointing from HTTPS to HTTP, and not combined with noindex to another URL. The comparison ignores www, the trailing slash and query strings. The scanner is passive: it reads one page and a few public resources and does not crawl the whole site, so it will not find duplicates across all your URLs. For that you need a full crawl or Search Console.

To see canonical next to the other checks, open the SEO audit page.