A canonical tag is a line of HTML that tells search engines which URL should count as the original when the same content is reachable at several URLs. It lives in the <head> of the duplicate pages and points at the one preferred version, called the canonical URL. The syntax is a single link element: <link rel="canonical" href="https://example.com/preferred-page/" />. Search engines treat that element as a strong signal, not an order: Google still compares it with redirects, sitemaps, and internal links before choosing which URL to index. This guide covers where duplicates come from, how to write the tag correctly, what happens when signals disagree, and how to verify the result.

Why duplicate URLs happen

Most duplicate URLs are accidents of how websites work, not copied content:

  • Parameters. Sorting, filtering, tracking, and session parameters create new URLs with the same content, such as /shoes?color=blue or /shoes?utm_source=email.
  • Host variants. www.example.com and example.com are different hosts, so both can serve the same site.
  • Protocol variants. The http:// and https:// versions of a page are different URLs, even on the same host.
  • Trailing slash and case. /page, /page/, and sometimes /Page may all return the same content.
  • Print and format versions. Print-friendly pages and PDF versions repeat the main content at their own URLs.

Left alone, a search engine guesses which version represents the content, and links and reporting split across the group. A canonical tag names the version you want indexed.

Correct canonical syntax

Put one canonical element in the <head> of every duplicate page, pointing at the same preferred URL:

<head>
  <title>Blue Running Shoes</title>
  <link rel="canonical" href="https://example.com/shoes/blue-running-shoes/" />
</head>

The element only counts in the <head>, and each page should carry at most one. The target should return a successful response, be indexable, and hold content that duplicates or contains the pointing page's content, per RFC 6596. For non-HTML files such as PDFs, the same instruction can be sent in an HTTP header: Link: <https://example.com/file.pdf>; rel="canonical".

Tested example: canonical tags on live pages

These values were captured from live HTML. The Wikipedia value is exactly self-referencing: the canonical matches the page URL character for character.

$ curl -sL https://en.wikipedia.org/wiki/Canonical | grep -i canonical
<link rel="canonical" href="https://en.wikipedia.org/wiki/Canonical">

$ curl -sL https://www.bbc.com/ | grep -o '<link rel="canonical"[^>]*>'
<link rel="canonical" href="https://www.bbc.com" data-next-head=""/>

$ curl -sL https://developer.mozilla.org/en-US/docs/Web/HTML | grep -i -A2 canonical
<link rel="canonical" href="https://developer.mozilla.org/en-US/docs/Web/HTML" />

All three declare the page itself as canonical, the normal pattern for an original page.

Absolute URLs beat relative URLs

RFC 6596 allows a relative canonical target, and Google states that relative paths are supported. Google also explicitly recommends absolute URLs, warning that relative paths can cause problems, for example if a staging copy gets crawled and its canonicals resolve against the wrong host. Prefer the full form:

<!-- Prefer this -->
<link rel="canonical" href="https://example.com/shoes/" />

<!-- Avoid this -->
<link rel="canonical" href="/shoes/" />

Be consistent about every character: https rather than http, your chosen host variant, and your trailing-slash convention. A canonical that differs in some small detail from the URL you link to internally is a conflicting signal, even if a human sees no difference.

Self-referencing canonicals

A self-referencing canonical points to the page itself. Google recommends including one on the canonical page, and the live examples above show the pattern in production. It removes ambiguity: copies may arrive with extra query strings, but the page still names its clean version as canonical. If your system generates canonicals automatically, check it outputs the page's own final URL, not a draft or staging variant.

Canonical chains and loops

A canonical chain happens when page A canonicalizes to page B, and page B canonicalizes to page C. A loop happens when two pages canonicalize to each other. Search engines may follow a short chain, ignore it, or pick a different URL than expected, so chains weaken the signal.

The following is a labelled example, not a captured result. It shows the shape to avoid:

Example (hypothetical):
/page-a/ -> /page-b/ -> /page-c/   (chain)
/page-x/ -> /page-y/ -> /page-x/   (loop)

Fix chains by pointing every duplicate directly at the final canonical URL. Fix loops by choosing the real original and making the other page point to it. Redirect chains create the same confusion; see how to fix redirect chains and loops.

When signals conflict, which one wins?

Google's documentation describes canonicalization inputs as signals of different strengths, not guarantees. In Google's own ordering, redirects and rel="canonical" annotations are strong signals, while sitemap inclusion is a weak signal. The methods also stack: consistent signals reinforce each other.

  • Canonical vs. redirect. A redirect is decisive in a way a canonical is not, because the duplicate no longer serves content at all. Expect the redirect target to win over a conflicting canonical. Use a redirect when the duplicate should go away, a canonical when it must stay reachable.
  • Canonical vs. sitemap. Listing a duplicate in your sitemap suggests it is a preferred, indexable page, which works against a canonical pointing elsewhere. Keep only canonical URLs in the sitemap.
  • Canonical vs. internal links. Google advises linking internally to the canonical URL rather than to duplicates. If your links point to the parameterized version while the canonical names the clean version, the signals disagree.

No combination forces an outcome: Google can choose a different canonical than the one declared. The goal is to make every signal you control agree.

Canonical vs. 301 redirect vs. noindex

Method Mechanism When to use it
rel="canonical" A hint in the page (or HTTP header) naming the preferred URL; the duplicate stays live The duplicate must remain reachable, for example a parameterized, print, or syndicated version
301 redirect The server sends visitors and crawlers to the target URL; the duplicate stops serving content The duplicate should be retired, merged, or moved permanently
noindex A robots directive asking engines not to index that page The page should stay live for visitors but out of search results, such as an internal search or thank-you page

Google does not recommend noindex for choosing a canonical within one site: it blocks the page from search entirely rather than consolidating it. Pick one primary method per duplicate set, then align the other signals.

Paginated, AMP, and syndicated content

Paginated content. Give each page in a sequence its own self-referencing canonical. Do not canonicalize page 2 and later pages to page 1: they hold different content, so treating page 1 as their duplicate can drop them from consideration.

AMP pages. An AMP variant should canonicalize to the regular HTML page, and the regular page should reference the AMP version with the AMP alternate annotation. If AMP is the only version, it still needs a self-referencing canonical.

Syndicated content. When another site republishes your article, ask for a cross-domain canonical on their copy pointing to your original. RFC 6596 permits the target to live on a different host. Not every partner will add one; a link back is not a substitute, and outcomes vary by engine.

How to verify a canonical

Verification has two parts: confirming the tag exists and is consistent, and checking which URL the engine actually selected. The second can differ from the first, and no check promises an indexing outcome.

View the source. Search the HTML source for rel="canonical". Confirm there is exactly one, in the <head>, with the absolute URL you intended.

Run a checker. A checker reports the canonical alongside the final URL after redirects, so mismatches are easy to spot. Running Wikipedia's Canonical article through the analyzer behind our SEO Checker returned this trimmed result:

{
  "input_url": "https://en.wikipedia.org/wiki/Canonical",
  "final_url": "https://en.wikipedia.org/wiki/Canonical",
  "status": 200,
  "canonical": "https://en.wikipedia.org/wiki/Canonical"
}

The canonical equals the final URL, so the page is self-referencing and no canonical issue was flagged. The opposite case is just as easy to check. https://example.com returns no canonical at all, and the same analyzer flagged it directly:

$ curl -sL https://example.com | grep -i canonical
(no output)

Analyzer issue: "No canonical URL declared" (Medium)
Evidence: No <link rel="canonical"> was found.

A missing canonical is not an error by itself, since engines will still pick a version, but the choice is left entirely to them.

Check Search Console. The URL Inspection tool reports both the canonical you declared and the one Google selected. If they differ, work through the conflicting signals above. Our website SEO audit guide puts these checks in context with status codes and internal linking.

Frequently asked questions

Is a canonical tag required on every page?

No. A page without one can still be indexed, because the engine chooses a canonical on its own. A self-referencing canonical is still recommended: it states your preference and protects the page when copies appear at other URLs.

Can a canonical point to a different domain?

Yes. The target may live on a different host or domain, the mechanism used for syndicated content. It should hold the same or a superset of the content, and works best when the other site cooperates.

What happens if a page has two canonical tags?

Conflicting declarations make the signal unreliable, and engines may ignore both. Use exactly one per page, and check templates and plugins: a common cause is a plugin adding a second tag next to one the theme already outputs.

Does a canonical stop a page from being crawled?

No. Crawlers still fetch the duplicate to read its canonical, and may return to it. A canonical consolidates indexing signals; it is not a crawl block, and robots rules should never be used as a canonicalization method.

How long does a canonical take to be respected?

There is no fixed timeline to promise. The engine has to recrawl the duplicates, process the signal alongside the others, and update its selection. Keep signals consistent and check URL Inspection after recrawling.

References

Related reading: duplicate metadata.