Canonical Tags Explained: How to Fix Duplicate Content for Google and AI

🔗 Technical SEO · Updated October 2026 · 11 min read · by Jacob Campbell

A canonical tag is a <link rel="canonical" href="..."> element in a page’s <head> (or a Link HTTP header for files such as PDFs) that tells search engines which URL is the main version when the same content is reachable at several addresses. Google treats it as a strong hint, not a rule: it weighs your canonical together with redirects, sitemaps, HTTPS and other signals, and can pick a different URL if those signals disagree.

Duplicate URLs are rarely deliberate. They come from http and https, www and non-www, trailing slashes, tracking parameters, filters, print views and, increasingly, Markdown versions of pages served to AI agents. This guide explains exactly how to declare a canonical, how Google decides which URL wins, how to check the result in Search Console, and the mistakes that quietly undo the work, with code you can copy.

Key facts

• Hint — Google treats a declared canonical as a hint, not a rule
• <head> only — rel=canonical is only accepted in the HTML head
• Link header — Declares a canonical for PDFs and other non-HTML files
• Up to 2 weeks — Google may keep a page in a duplicate cluster after a fix

What a canonical URL is, and why it matters

The canonical URL is the single address a search engine chooses to represent a group of pages with the same or very similar content; the other addresses become duplicates that are crawled less and usually not shown in results.

Google’s canonicalization overview describes the process: during indexing, Google clusters pages it finds to be duplicates and picks the one that is “objectively the most complete and useful” as canonical. You do not have to declare anything for this to happen. Declaring a canonical lets you influence the choice, and Google lists four reasons to do it in its guide to consolidating duplicate URLs:

• Choose the URL people see in search results (for example the short one, not the one with ?utm_source=newsletter).
• Consolidate signals such as links pointing to the different versions, so they count towards one URL.
• Simplify tracking, because metrics for one piece of content are not split across several URLs.
• Save crawl time, so Googlebot spends its visits on new and updated pages instead of copies.

Duplicate content is not a penalty in itself. The cost is dilution and loss of control: the wrong URL ranks, link equity is split, Search Console reports are fragmented, and on larger sites crawling is wasted. The same clarity helps AI systems that build on a search index, because Google’s AI Overviews and AI Mode draw on pages that are indexed and eligible to be shown in Search (see how to show up in AI Overviews).

How to declare a canonical: HTML, HTTP header, sitemap, redirect

Google supports four ways to indicate a canonical, and they differ in strength: a permanent redirect and a rel="canonical" annotation are strong signals, and listing a URL in a sitemap is a weak one.

1. The link element in the HTML head

This is the method most sites use. Put it in the <head> of every duplicate and of the canonical page itself (a self-referencing canonical), using an absolute URL:

<head>
  <link rel="canonical" href="https://www.example.com/services/web-design/">
</head>

Google’s rules for the element: it is only accepted in the <head>, the head must be valid HTML (a stray element that closes the head early can push the tag into the body), use absolute rather than relative URLs, and if JavaScript adds or changes the tag, make sure it ends up correct in the rendered page. The safest approach is to output it in the server-rendered HTML and never touch it with scripts.

2. The HTTP Link header, for PDFs and other files

Non-HTML files have no head, so you send the canonical as a response header. Google documents this for documents it supports in web search, such as PDFs:

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

A common use is a PDF that duplicates an HTML page. If you want the HTML page to rank, point the PDF’s header at it. On Apache with mod_headers:

<Files "price-guide.pdf">
  Header set Link "<https://www.example.com/pricing/>; rel=\"canonical\""
</Files>

The same header is the cleanest option for Markdown twins: if you serve /pricing.md or a Markdown response for AI agents (see Markdown for AI agents), send Link: <https://www.example.com/pricing/>; rel="canonical" with it, so a search engine that finds the Markdown URL knows the HTML page is the main version. Google does not document how it treats Markdown files specifically, so treat the header as good hygiene rather than a guarantee, and keep Markdown URLs out of your sitemap.

3. Sitemaps

Only list canonical URLs in your XML sitemap. Google calls sitemap inclusion a weak signal, so it helps but will not override a redirect or a conflicting canonical tag. (Our guide on where to submit your sitemap covers the submission side.)

4. Redirects

When a duplicate does not need to exist at all, a permanent (301 or 308) redirect to the canonical is the strongest signal and the cleanest result, because users and crawlers both end up in one place.

How Google chooses the canonical, and why it is only a hint

Google combines several signals to choose a canonical, and when they conflict it may ignore your declared preference; in Google’s words, “indicating a canonical preference is a hint, not a rule.”

The signals Google names in its documentation are:

• Redirects: the target of a permanent redirect is strongly favoured.
• rel="canonical" annotations, in HTML or the HTTP header.
• Sitemap inclusion, a weaker signal.
• HTTPS over HTTP: Google prefers the HTTPS version unless there are problems such as an invalid certificate, insecure dependencies, or the HTTPS page redirecting to HTTP.
• hreflang clusters: Google says it prefers URLs that are part of hreflang clusters.

Internal links are not listed as a separate signal in that documentation, but they matter in practice: if your navigation, breadcrumbs and article links all point to /services/web-design while the canonical tag says /services/web-design/, you are sending mixed messages. Make every signal agree. The most reliable canonical is one where the redirect, the tag, the sitemap and every internal link name the same URL.

Content also matters. Google’s canonical troubleshooting guide notes that it may pick a different canonical because of “the quality of the content or technical signals”. If two of your pages are near-identical, Google may fold one into the other even if each declares itself canonical. The fix is to make the pages genuinely different or to merge them.

Check the result: URL Inspection and the Google-selected canonical

The URL Inspection tool in Google Search Console shows two values for any indexed URL: the User-declared canonical (what your page says) and the Google-selected canonical (what Google actually chose).

1. Open Search Console, paste the URL into the inspection bar at the top, and wait for the result.
2. Expand Page indexing. Compare User-declared canonical with Google-selected canonical.
3. If they match, you are done. If the declared value is “None” on a page that has no duplicates, that is fine too; Google’s URL Inspection help says that when a page has no alternate versions, the Google-selected canonical is the inspected URL.
4. If they differ, open the Google-selected URL and ask why Google might consider it the better version: is it the one your internal links use, the one in the sitemap, the one external sites link to?
5. Use Test live URL to confirm that the canonical tag is present in the rendered HTML, not just in your source template.

Site-wide, the Page indexing report groups URLs under reasons such as “Alternate page with proper canonical tag” (normal and expected), “Duplicate without user-selected canonical” (declare one) and “Duplicate, Google chose different canonical than user” (your signals disagree). After a fix, be patient: Google says it may keep pages in a duplicate cluster for up to two weeks even after the content issue is resolved.

One caveat from the same help page: the URL shown in search results can differ from the canonical, for example when Google shows a device-appropriate version. That is display, not a canonical failure.

Where duplicate URLs come from, and the fix for each

Most duplicate URLs come from a handful of predictable sources, and most of them are better fixed with a redirect than with a canonical tag.

• http and https: redirect all HTTP requests to HTTPS with a 301. A canonical alone leaves both versions crawlable.
• www and non-www: choose one host and redirect the other. Do the same for any extra hostnames your hosting creates.
• Trailing slashes: /about and /about/ are different URLs to a search engine (the bare domain is the exception, where both forms are the same). Pick one form, redirect the other, and link consistently.
• Index files and case: /index.php, /index.html and mixed-case paths can all serve the same page. Redirect them to the clean URL.
• Tracking and session parameters: ?utm_source=, ?gclid=, ?ref=. Keep the page available, and give it a canonical pointing to the clean URL.
• Sort and filter parameters (faceted navigation): ?sort=price, ?colour=red&size=m. A canonical to the unfiltered category works for small sites. Google’s faceted navigation guide says rel="canonical" is “generally less effective in the long term” than blocking filter URLs in robots.txt or using URL fragments for filters, so large shops should consider those instead.
• Pagination: do not canonicalize page 2, 3 and so on to page 1. Google’s pagination guidance says to give each page its own canonical URL; Google no longer uses rel="next" and rel="prev".
• Print, AMP and Markdown versions: a print view should carry a canonical to the main page. AMP pages follow the AMP pairing (the AMP page links to the canonical with rel="canonical", the canonical links to the AMP page with rel="amphtml"). Markdown twins get the HTTP Link header shown earlier.
• Separate mobile URLs: on an m. site, Google recommends a rel="alternate" link from the canonical page to the mobile URL and a canonical from the mobile URL back.
• Syndicated copies: when partners republish your articles, a cross-domain canonical often fails because their page differs a lot from yours (different navigation, comments, related content). Google’s troubleshooting guide lists syndication as a case where canonicals can be ineffective; asking partners to noindex their copy is the more reliable route.

Here is a typical Apache block that settles the protocol, host and index-file variants in one place:

RewriteEngine On
# Force HTTPS and www in one redirect
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]
# Remove index.php from URLs
RewriteCond %{THE_REQUEST} \s/(.*/)?index\.php[\s?] [NC]
RewriteRule ^ /%1 [L,R=301]

Canonical mistakes that undo the work

Most canonical problems come from tags that contradict other signals or point somewhere Google cannot use, and the following are the ones we find most often in audits.

• Canonical to a page that is noindex, redirected or returns 404. The canonical target must be an indexable 200 page. A canonical that points at a redirect or an error page is a conflicting signal and is likely to be ignored.
• Using noindex instead of a canonical. Google advises against noindex to steer canonical selection within one site, because it removes the page from Search completely; a rel="canonical" is the preferred solution. Combining noindex with a canonical to another page sends two opposite instructions.
• Every page canonicalized to the homepage. Usually a theme or plugin bug. It tells Google that every page is a duplicate of the homepage, and Google will typically ignore the tag or, worse, drop the inner pages.
• Canonical in the body. Google only accepts the element in the <head>. Invalid markup above it, such as an <iframe> or <div> injected by a script into the head, can end the head early and leave the tag in the body.
• More than one canonical, or different canonicals in different places. Two plugins each adding a tag, or the HTML tag saying one URL and the Link header another. Google’s guidance is not to specify different URLs as canonical for the same page; when signals conflict, Google chooses for itself.
• Relative or fragment URLs. Use absolute URLs, and never a #fragment; Google generally does not support fragments in canonicals.
• Cross-domain canonicals by accident. Staging hosts, CDN hostnames or an old domain in a hard-coded template. Google supports cross-domain canonicals, so a mistake here can hand your rankings to the wrong host.
• Using robots.txt to hide duplicates. Google cannot read a canonical on a page it is not allowed to crawl, and a disallowed URL can still be indexed without its content. Our guide to noindex vs robots.txt explains why.
• Using the Removals tool. Google warns that it hides all versions of a URL from Search, not just the duplicate.

Canonical tags and hreflang on multilingual sites

Each language version of a page should be its own canonical: translated pages are not duplicates, and canonicalizing them all to the English version tells Google to drop the translations.

Google’s canonicalization documentation says pages count as duplicates only when the primary content is in the same language. Its consolidation guide adds that when you use hreflang, the canonical should be a page in the same language (or the best substitute language if no same-language canonical exists). In practice:

<!-- On https://www.example.com/es/servicios/ -->
<link rel="canonical" href="https://www.example.com/es/servicios/">
<link rel="alternate" hreflang="en" href="https://www.example.com/services/">
<link rel="alternate" hreflang="es" href="https://www.example.com/es/servicios/">
<link rel="alternate" hreflang="x-default" href="https://www.example.com/services/">

Each page lists every version, including itself, and every version links back; Google ignores hreflang annotations that are not reciprocated. Point hreflang only at canonical URLs; an alternate that is itself canonicalized elsewhere is a contradiction. Regional variants in the same language (en-US and en-GB with near-identical text) are where things get delicate: they can be clustered as duplicates, so use hreflang and make the regional differences real (prices, spelling, contact details). Our multilingual websites guide covers the full setup.

A canonical checklist, and when not to rely on canonicals

A canonical tag is the right tool when a duplicate must stay reachable for users; when it does not need to exist, a redirect is better, and when it should not be in search at all, noindex or authentication is better.

1. Pick one protocol and one host, and redirect everything else to it.
2. Choose a trailing-slash convention and enforce it with redirects.
3. Add a self-referencing absolute canonical to every indexable page, in server-rendered HTML.
4. Add canonicals pointing to the clean URL on parameter, print and sort variants.
5. Send Link: <...>; rel="canonical" on PDFs and Markdown twins that duplicate an HTML page.
6. List only canonical URLs in the sitemap, and link internally to canonical URLs only.
7. Check a sample of templates in URL Inspection, then watch the Page indexing report for “Google chose different canonical”.

Limits. A canonical does not stop crawling: Google still fetches duplicates occasionally to read the tag. It does not keep a page private. It cannot rescue two thin pages that should be one, and it is not honoured by every crawler: AI crawlers that fetch pages directly may read the duplicate as it is, which is why redirects and clean internal linking matter more than the tag. For other search engines, check their own documentation; Bing also supports rel="canonical", and our Bing Webmaster Tools guide covers its reports.

If you would rather see the whole picture at once, the technical SEO checklist puts canonicals alongside the other factors that move rankings.

Product facts: the AI Indexing Pack

The AI Indexing Pack serves Markdown versions of pages to agents, which is exactly the kind of twin URL this guide covers. Stated plainly, so it can be checked against the product page:

• What it is: the AI Indexing Pack is a set of files you upload to your own website. It is sold by Built2WinWeb as a one-time purchase, with no subscription.
• What it ships: (1) a working MCP server using the Streamable HTTP transport, with typed output schemas and tool annotations; (2) Markdown content negotiation, so agents can request a clean text version of each page; (3) llms.txt, agents.txt and agent cards; (4) the full /.well-known/ discovery tree; (5) OAuth protected-resource metadata; (6) bot access control that verifies crawler identity; (7) a README with a verification checklist.
• Requirements: PHP 7.4 or newer, Apache or LiteSpeed with .htaccess support, FTP access, and a domain you control. Installation takes about 30 minutes.
• What it is not: it is not a WordPress plugin (that is the separate WordPress edition, which needs WordPress 6.0+ and PHP 8.0+), it does not write content for you, it does not guarantee rankings or citations, and it is not a managed service.
• Free routes in: sites built on AIWebBuilding get the core built in, and a 50-day streak on FreeAIBoost unlocks the pack for one domain. Current prices are on the product pages.

Related reading

• noindex vs robots.txt Disallow — Which one keeps a page out of Google, and the mistake that keeps it in.
• Technical SEO checklist — 12 technical factors that move rankings, canonicals included.
• Multilingual websites for search and AI — hreflang, lang attributes and translation done right.
• Markdown for AI agents — Serve a clean text version of every page, without creating duplicate-content problems.
• SEO migration guide — Redirects and canonicals when you move platforms.
• Where to submit your sitemap — Every search engine, plus IndexNow.
• AI Indexing Pack — The file-drop kit: MCP server, Markdown pages, llms.txt, discovery files and bot access control for any PHP site.

Frequently asked questions

Does Google always follow my canonical tag?

No. Google treats rel=canonical as a strong hint, not a rule, and weighs it with redirects, sitemaps, HTTPS and content similarity. If those signals conflict, Google may choose a different canonical, which you can see in Search Console’s URL Inspection tool.

Should every page have a self-referencing canonical?

Yes. Google recommends including a rel=canonical link on the canonical page itself, using an absolute URL. It protects against parameter and tracking variants of the page being chosen instead.

How do I set a canonical for a PDF?

Send an HTTP Link header with the PDF response, for example Link: <https://www.example.com/pricing/>; rel="canonical". Google supports this header for non-HTML documents it indexes, such as PDFs.

Is it better to use a 301 redirect or a canonical tag?

Use a 301 redirect when the duplicate URL does not need to exist for users, such as http, non-www or index.php variants. Use a canonical tag when the duplicate must stay reachable, such as tracking-parameter, sort or print URLs.

Should translated pages canonicalize to the English page?

No. Each language version should be its own canonical, connected to the others with hreflang. Google only treats pages as duplicates when their main content is in the same language.