Canonical tags: 7 common mistakes and how to fix them

By Holifan, approved 2026-10-23. Drafted with AI from the sources listed below, checked against them automatically, with code examples tested, and approved by the site owner.

This guide is for site owners, developers, and SEOs who manage duplicate or similar pages. You’ll learn how to use canonical tags correctly, avoid the mistakes that undermine them, and troubleshoot cases where Google chooses a different canonical URL than the one you specified.

What is a canonical tag and why use it

According to RFC 6596, the canonical link relation designates an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content. More informally, it is the author’s preferred version of a resource.

Specifying a canonical URL helps you indicate which URL should appear in search results, group signals for duplicate pages, simplify content statistics, and optimize crawling. For example, you might want visitors to land on https://www.example.com/dresses/green/green-dress.html instead of a URL with tracking parameters. Grouping signals means that links to duplicate pages — mentions, backlinks, social shares — are credited to the canonical URL instead of being split across variants.

Google supports four methods to communicate a canonical URL, in order of how strongly each one can influence the outcome: a permanent redirect (strongest, because it removes the duplicate entirely), a rel="canonical" link annotation (strong), and sitemap inclusion (weak — a hint, not a directive). The methods stack: using more than one increases the chance your preferred URL wins.

How to specify a canonical URL

The rel="canonical" link element works only for HTML pages. For non-HTML content such as PDF or Word files, use the equivalent HTTP header instead — Google supports this for web search results.

HTML link element:

<link rel="canonical" href="https://www.example.com/dresses/green/green-dress.html">

HTTP header, for non-HTML files:

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

Add this same link to the canonical page itself too (a self-referential canonical) — it is not just for the duplicates.

7 common mistakes

1. Mixing signals across methods

Don’t specify different canonical URLs for the same page using different techniques — for example, one URL in the sitemap and a different one in the rel="canonical" link. When signals disagree, Google has to decide which one to trust, which is exactly the ambiguity canonicalization is meant to remove.

2. Using robots.txt to hide duplicates

Blocking a duplicate URL in robots.txt doesn’t canonicalize it. Google may still index a disallowed URL without being able to see its content (because it can’t crawl it), which is worse than letting it compete as a normal duplicate.

3. Using noindex instead of canonical

Adding noindex to stop a duplicate from being selected as canonical blocks that page from Search entirely. If you want Google to consolidate signals toward another URL, use rel="canonical", not noindex.

4. Relative paths or URL fragments

Use absolute URLs in the rel="canonical" link, not relative paths — https://www.example.com/dresses/green/green-dress.html, not /dresses/green/green-dress.html. Relative paths technically work, but they break if the page is ever crawled from an unexpected host (a staging subdomain, for instance). Fragments (#section) are not supported as canonical targets at all.

5. Adding hreflang, media, or type attributes to the canonical link

rel="canonical" annotations that carry an hreflang, lang, media, or type attribute are ignored for canonicalization — Google only reads the plain href. If you need to point to a mobile variant or a translated version, use a separate rel="alternate" link instead:

<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/dresses/green-dresses">
<link rel="canonical" href="https://example.com/dresses/green-dresses">

6. Letting HTTPS/HTTP conflicts undermine the signal

Google prefers HTTPS over an equivalent HTTP page by default — but four specific problems override that preference and make Google fall back to HTTP instead: an invalid SSL certificate, insecure dependencies on the HTTPS page, the HTTPS page redirecting through HTTP, or the HTTPS page itself carrying a rel="canonical" to the HTTP version. A correct TLS certificate and HSTS are not enough on their own if any of these four are also true. Keep HTTP versions out of your sitemap and hreflang annotations — list the HTTPS URLs only.

7. Internal links still pointing at the duplicate

Link internally to the canonical URL, not the duplicate — consistent internal linking is itself a canonicalization signal, independent of the rel="canonical" tag. If your own navigation and footer link to ?sort=price variants while the tag claims the plain URL is canonical, you’re sending Google two different preferences.

One more hreflang-specific rule: if you use hreflang annotations, the canonical page in each entry should be in the same language as that entry, or the closest available substitute — not an unrelated language’s canonical.

How to verify the chosen canonical

Use the Search Console URL Inspection tool to check which page Google considers canonical, and whether that choice makes sense for users coming from Search. If the canonical Google picked lives in a Search Console property you don’t own, you won’t see any of that page’s traffic in your own property — a common source of “missing traffic” confusion that has nothing to do with the tag itself.

After fixing an issue, use “Request Indexing” in the URL Inspection tool to ask Google to re-evaluate the page. This is subject to quotas, so reserve it for your most important URLs. Even after a fix, Google may hold pages in a duplicate cluster for up to two weeks; pages split out faster when the difference from the rest of the cluster is clear and significant.

Troubleshooting when Google selects a different canonical

When the selected canonical differs from your preference, the cause is usually one of these, roughly in order of how often each comes up:

Missing localization annotations. If you serve the same content to different regions without hreflang, Google may fold the variants together. Add hreflang annotations so each regional URL can surface on its own.
Incorrect canonical elements from a CMS or plugin. Some CMS plugins point rel="canonical" at the wrong URL by default. Inspect the rendered HTML with your browser’s developer tools, not just the template source, since plugins often inject or override the tag at render time.
Misconfigured servers. A server can be set up to return content from example.com for a request to an unrelated host, or two unrelated sites can serve identical soft-404 pages that Google fails to recognize as errors — both confuse canonical selection in ways that have nothing to do with your tags.
Malicious hacking. Some site compromises insert a 3xx redirect or a cross-domain rel="canonical" into the HTML <head> or HTTP headers, usually pointing at spammy content. Google’s systems can end up selecting that injected URL instead of the real one on the compromised site — a canonicalization problem that is really a security incident, and needs to be fixed by removing the injected code, not by adjusting your own tags.
Syndicated content. rel="canonical" is not recommended for syndication partners, since syndicated pages are often meaningfully different from the original. The effective fix is to have syndication partners block their copies from indexing, not to rely on canonical tags across domains.
A copycat site. In rare cases Google selects a URL on a site hosting your content without permission. Contact the site’s host to request removal, and if needed, file a takedown request under the DMCA.

Sources

Check your own site with the Meta Tag & Open Graph Analyzer.