Canonical tags: telling Google which URL is the main one

When the same content is reachable at several addresses, Google picks one to show in search. This guide explains how that choice is made, how rel="canonical", redirects and sitemaps tell Google which URL you prefer, and what to check when Google picks a different one.

This guide follows Google Search Central's own pages: What is canonicalization, How to specify a canonical URL with rel="canonical" and other methods and Fix canonicalization issues. Quotes are from those pages; where we add our own practice, we say so.

What a canonical URL is

Google defines canonicalization as "the process of selecting the representative –canonical– URL of a piece of content." When Google indexes a page it works out the page's main content. If several URLs show the same or very similar main content, Google clusters them and picks one, the canonical, as "the most complete and useful for search users". The canonical is crawled most often; duplicates are crawled less, "in order to reduce the crawling load on sites."

The canonical is also what Google uses "as the main source to evaluate content and quality", and search results usually point to it. Google's example of an exception: a mobile user may be shown the mobile URL even when the desktop page is the canonical.

The most important sentence on the topic: "indicating a canonical preference is a hint, not a rule." A canonical tag tells Google what you prefer. Google weighs it with other signals and can still choose differently.

Why the same page ends up on several URLs

Google lists the usual causes of duplicate content:

  • Region variants: separate URLs for, say, the USA and the UK with essentially the same content in the same language.
  • Device variants: a separate mobile and desktop version of a page.
  • Protocol variants: the HTTP and HTTPS versions of a site.
  • Site functions: sorting and filtering a category page, each producing its own URL.
  • Accidental variants: a demo or test copy of the site left open to crawlers.

Tracking parameters add more. Google's own example is a product page reached as https://example.com/dresses/cocktail?gclid=ABCD instead of its clean address. Google is clear that "some duplicate content on a site is normal and it's not a violation of Google's spam policies." The cost is practical: visitors may wonder which page is the right one, and your performance data is split across addresses.

Do you need to set one?

Not strictly. Google says none of the methods are required and "your site will likely do just fine without specifying a canonical preference", because Google will pick a version itself. It gives four reasons to state a preference anyway:

  • to choose which URL people see in search results;
  • to consolidate signals, such as links, from the duplicates into one URL;
  • to make metrics for one piece of content easier to track;
  • so Googlebot spends its time on new or updated pages instead of duplicates.

If your CMS doesn't let you edit the page's <head>, Google suggests looking for a search engine settings page in the CMS. Google's troubleshooting page also names CMSs and CMS plugins as a source of incorrect canonicals (see below).

The methods, strongest first

Google lists three methods "in order of how strongly they can influence canonicalization", and notes that they stack: using two or more increases the chance your preferred URL is shown.

MethodHow Google rates itUse it for
Redirect"A strong signal that the target of the redirect should become canonical"Retiring a duplicate URL for good. Google: "Use this only when deprecating a duplicate page."
rel="canonical" (HTML element or HTTP header)"A strong signal that the specified URL should become canonical"Duplicates that must stay reachable, such as filtered or parameter URLs. The element works only for HTML; the header also covers PDFs.
Sitemap inclusion"A weak signal"Naming canonicals across a large site. Google still has to find the duplicates itself.

For redirects, Google says all permanent methods have the same effect, but server-side (HTTP) redirects work quickest. Its example is a page reachable as example.com/home, home.example.com and www.example.com: pick one and redirect the others to it. Status codes and redirect chains are covered in our 404s and redirects guide, and sitemap format in our robots.txt and XML sitemaps guide. In a sitemap, every listed URL is "suggested as canonicals", so list only the versions you want in search.

The rel="canonical" link element

This is the familiar canonical tag. Put it in the <head> of each duplicate, pointing to the main page:

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

Google's rules for it:

  • Add it to the canonical page too. Google recommends this "self-referential" canonical.
  • Use absolute URLs. Relative paths are supported but "can cause problems in the long run", for example if you unintentionally allow a testing copy of the site to be crawled.
  • Keep it in a valid <head>. The element "is only accepted if it appears in the <head> section of the HTML", so broken markup above it can make Google miss it.
  • No alternate attributes. Canonical links with hreflang, lang, media or type attributes are not used for canonicalization. Language versions use rel="alternate" hreflang instead, and a separate mobile URL gets a rel="alternate" link from the desktop page.
  • Pick one place. Using the HTML element and the HTTP header together is supported but "more error prone", because the two can end up naming different URLs.
  • JavaScript sites: set the canonical in the HTML source and make sure JavaScript doesn't change it. If that isn't possible, leave it out of the HTML and set it only with JavaScript, so there is one clear value.

A PDF or Word file has no <head>, so the element can't be used. If you control the server, you can send a Link response header instead. Google supports this "for web search results only". Its example points a .docx file at the PDF version of the same document:

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

Use absolute URLs here as well. The header also works for HTML pages and doesn't add to page size, but Google notes that keeping the mapping right on a large site with changing URLs takes work, whichever form you use.

HTTPS and hreflang: signals from your setup

Besides the methods you choose, Google uses two signals based on how the site is set up.

HTTPS is preferred over HTTP, unless something conflicts: an invalid certificate, insecure dependencies other than images, an HTTPS page that redirects to or through HTTP, or an HTTPS page whose canonical points to HTTP. Google says bad certificates and HTTPS-to-HTTP redirects make it "prefer HTTP very strongly", and HSTS can't override that. Don't list HTTP URLs in your sitemap or hreflang, and make sure the certificate matches the exact host. Our SSL certificates guide covers the certificate side.

URLs in hreflang clusters are preferred. If your German and Swiss pages point to each other with hreflang but the Austrian page is left out, the first two are preferred as canonicals. Translated pages count as duplicates only when the main content is in the same language; translating only the header and footer isn't enough. For regional variants in one language, Google says to use both canonicals and hreflang. Our multilingual websites guide explains hreflang setup.

Mistakes Google tells you to avoid

  • robots.txt for duplicates. Google may still index a blocked URL "without their content".
  • The URL removal tool. It "hides all versions of a URL from Search", not just the duplicate.
  • Mixed messages. Don't name one URL in the sitemap and another in rel="canonical" for the same page.
  • Fragments. Don't use a #section URL as canonical; Google "generally doesn't support URL fragments."
  • noindex instead of a canonical. Google doesn't recommend it within one site, "because it will completely block the page from Search."
  • Wrong-language canonicals. With hreflang, the canonical should be a page in the same language, or the closest substitute.
  • Linking to duplicates. Internal links should point to the canonical URL; consistent linking helps Google understand your preference.

When Google picks a different URL

Google says it may override your choice "for various reasons, such as the quality of the content or technical signals." Start with the URL Inspection tool, which shows the user-declared and Google-selected canonical side by side. Google asks you to think about whether its pick makes more sense for searchers. The matching statuses in Search Console are explained in our Page indexing report guide.

Google's list of common causes:

  • Language variants without hreflang, such as US, UK and Australian sites with the same content.
  • Incorrect canonical elements added by a CMS or plugin. Check the page's HTML in your browser's developer tools; if the CMS sets the wrong URL, report it to the CMS provider.
  • Misconfigured servers, for example one domain answering with another domain's content, or two unrelated servers returning identical soft 404 pages.
  • Hacking that inserts a redirect or a cross-domain canonical pointing to a spammy URL. Our security issues guide covers what to do if your site is compromised.
  • Syndicated content. Google doesn't recommend the canonical element against duplication by syndication partners, "because the pages are often very different"; the partners blocking indexing works best.
  • A copycat site. Rarely, Google picks a site that copied your content. You can contact its host or file a DMCA request with Google.

If the real problem is that the pages are too alike, the fix is to make them clearly different. Google warns it "might hold pages in a duplicate cluster for up to two weeks" after you fix content, and pages split out faster when the difference is "clear and significant". Then use Request Indexing for your most important URLs, since that feature has quotas.

Our view: the checks we run

This part is our practice, not Google guidance. On the sites we build, every page has an absolute, self-referencing canonical that matches exactly the URL in the sitemap and in internal links: same protocol, same www or non-www, same trailing slash. The other host and protocol variants redirect to that version. After a launch or a CMS plugin change, we view the source of a few templates (home, a service page, a filtered or paginated listing) to check the canonical, and inspect one URL of each in Search Console a few weeks later to see whether Google agreed.

Frequently asked questions

Is a canonical tag a directive Google must follow?

No. Google calls a canonical preference "a hint, not a rule." It is a strong signal, but Google weighs it with redirects, sitemaps, HTTPS, hreflang and the content itself, and may choose another URL.

Should a page have a canonical tag pointing to itself?

Yes. Google recommends adding a self-referential rel="canonical" link on the canonical page itself, using the absolute URL.

Is duplicate content a penalty?

No. Google says some duplicate content on a site is normal and not a violation of its spam policies. The downside is that Google picks the version to show and your signals and data are split across URLs.

Can I use robots.txt or noindex to hide duplicate pages?

Google advises against both. A robots.txt block can still leave the URL indexed without its content, and noindex removes the page from Search completely. Use rel="canonical" or a redirect instead.

How long does it take for Google to accept a fix?

Google says it may keep pages in a duplicate cluster for up to two weeks after content issues are fixed, and pages split out faster when the difference is clear and significant.

For more on technical SEO, see our guides to the Page indexing report, 404s and redirects, robots.txt and sitemaps and redesigning without losing traffic.