Canonical Tag

How to implement rel=canonical correctly — the HTML link element, the HTTP Link header for PDFs, absolute URLs, one per page — and where people go wrong.

First published: Jun 23, 2026 · Last updated: Jul 26, 2026 · Advanced
demand #1 in Indexing#3 in How Search Works#31 in Technical SEO#43 on the site
AIAuthored byAI v2
1 evidence signal on this page

A canonical tag (rel=canonical) tells search engines which URL is the preferred version of duplicate content. It's a hint, not a directive — a strong signal Google can override. Valid methods: the HTML <link rel="canonical"> in the <head> (never the <body>), the HTTP Link header (the way to canonicalize PDFs and other non-HTML), and sitemap inclusion as a weaker signal. Declare one unambiguous canonical relationship per page; multiple or conflicting declarations can produce unexpected results, so don't claim that an engine deterministically chooses the first or last. Use absolute URLs and self-reference your preferred pages. Don't canonicalize paginated pages to page 1, and don't combine canonical with noindex or a robots.txt block — those send conflicting signals. Test the raw response, rendered DOM, response headers, and GSC's user-declared vs. Google-selected canonical.

TL;DR — rel=canonical is a hint, not a rule — a strong signal Google can and does override. Valid declaration methods: the HTML <link rel="canonical"> in the <head> (in the <body> it’s disregarded), the HTTP Link: rel="canonical" header (the only way to canonicalize PDFs and other non-HTML), and sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. inclusion as a weaker signal. Use exactly one unambiguous canonical per page — multiple or conflicting declarations can produce unexpected results. Use absolute URLs, self-reference preferred pages, and don’t canonicalize a paginated series to page 1. Don’t pair canonical with noindex, a robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. block, or a 4XX — each one stops Google reading or honoring the tag. Test with view-source vs the rendered DOM, curl -I for the header, and GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. URL Inspection (User-declared vs Google-selected).

A canonical is a declaration, not a decision

Keep two ideas separate. CanonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. is the process Google runs to pick one representative URL out of a duplicate set — it weighs a whole pile of signals to do it. The canonical tagA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. is just one of those signals: your declared preference. This page is about declaring it correctly; the selection process itself lives on the canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. hub.

That distinction is the whole accuracy spine here, because Google is explicit that “indicating a canonical preference is a hint, not a rule.” It’s a strong hint — as I’ve framed it in my deep dive on canonicalization, the canonical is “considered a strong signal,” and “Google ignores it if other signals are stronger.” But it is never a directive. If you declare URL A as canonical while your internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., and redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. all point at URL B, Google may side with B. (That’s the “Duplicate, Google chose a different canonical than user” state you’ll see in Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance..) Evidence for this claim Canonicalization methods communicate a preferred URL, but Google can choose a different canonical when signals conflict. Scope: Google Search canonical selection; applies to duplicate or very similar pages. Confidence: high · Verified: Google: URL canonicalization

Three non-redirect ways to declare a canonical

Alongside redirects, Google documents three non-redirect ways to indicate a canonical, and they have different strengths: Evidence for this claim Alongside redirects, Google documents three non-redirect ways to indicate a canonical: an HTML link element, an HTTP Link header, and sitemap inclusion. Scope: The three non-redirect canonical declaration approaches covered in this article; Google also documents redirects as a canonicalization method. Confidence: high · Verified: Google: Specify a canonical URL

  • HTML <link rel="canonical"> in the <head> — “A strong signal that the specified URL should become canonical.” This is the everyday method for HTML pages.
  • HTTP Link: rel="canonical" response header — for documents where you can’t put a <link> element. Google: you can “use a link HTTP response header with a rel=“canonical” target attribute as defined by RFC5988 rather than an HTML element to indicate the canonical URL for a document supported by Search, including non-HTML documents such as PDF files.” The HTML method “Only works for HTML pages, not for files such as PDF. In such cases, you can use the rel=“canonical” HTTP header.” This is the answer to “how do I canonicalize a PDF.”
  • Sitemap inclusion — “A weak signal that helps the URLs that are included in a sitemap become canonical.” Real, but the weakest of the three.

Two things worth knowing about how these interact:

  • They stack. Google: “these methods can stack and thus become more effective when combined.” A self-referencing <link> plus a clean sitemap plus consistent internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. all pointing the same way is far stronger than any one alone.
  • None of them are mandatory. “While we encourage you to use these methods, none of them are required; your site will likely do just fine without specifying a canonical preference.” Declaring one removes ambiguity; not declaring one isn’t an error.

Separately, a 301 redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. is an even stronger consolidation signal than rel=canonical — but it’s a different tool (more on canonical vs 301 vs noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. below).

A PDF has no <head>, so there’s nowhere to put a <link> element. The fix is to send the canonical in the HTTP response header at the server level. The shape:

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

You configure that in your server (Apache .htaccess, Nginx) or your CDN/edge — see the Scripts tab for working Apache and Nginx snippets and the curl -I command to confirm the header is actually being sent. The header method also works for HTML, but for HTML the <link> element is simpler; reach for the header when there’s no markup to edit (PDFs, images, other non-HTML).

It must be in the <head> — the body-placement trap

This is the failure mode that burns the most people, and it’s almost always accidental. Google: “The rel=“canonical” link element is only accepted if it appears in the <head> section of the HTML, so make sure at least the <head> section is valid HTML.” And from the 2013 “5 common mistakes” post, still the clearest statement of it: “When we encounter a rel=canonical designation in the <body>, it’s disregarded.” Their closing line is the rule in one sentence: “rel=canonical designations in the <head> are processed, not the <body>.” Evidence for this claim Google accepts an HTML rel=canonical link element only in a valid head section and disregards a canonical placed in the body. Scope: HTML link-element canonicals in Google Search; HTTP-header canonicals are a separate method. Confidence: high · Verified: Google: Common rel=canonical mistakes

Here’s the trap. You wrote the canonical into the <head> in your source. But when the page is constructed in a browser or rendered by the search engine, the <head> can end early — unclosed tags, JavaScript injected into the head, or an <iframe> in the head can all prematurely close it. The canonical then lands in the rendered <body>, where it’s ignored. I’ve described exactly this in my JavaScript SEO guide: things like “unclosed tags, JavaScript injected” can cause the <head> to end prematurely and throw a canonical into the <body> of a rendered page “where it will not be respected.”

The catch: this is invisible in view-source — the raw HTML looks fine. You have to compare the raw HTML to the rendered DOM (DevTools Elements panel, or GSC URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.’s rendered HTML) to see where the canonical actually ended up.

On the JavaScript note: Google’s guidance is to pick one method and not fight yourself. “If you can’t set the canonical URL in the HTML source code, leave it out and only set it with JavaScript.” If JS injects the canonical, make sure it injects it into the <head> properly — don’t also server-render a different one.

Declare one canonical relationship per page

There should be one unambiguous canonical relationship per page. Google’s current canonical-method guidance warns that combining canonical methods can produce errors and unexpected results; it does not define a first-tag or last-tag winner. A 2013 Google Search Central post said multiple declarations would likely be ignored. Keep that as historical troubleshooting context, not a timeless deterministic parser contract: the safe current conclusion is to flag the conflict, expose every HTML and HTTP declaration, and fix the template.

The usual cause is not a typo; it’s stacking systems. The CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms. injects one, the theme injects one, and an SEO plugin injects one — three conflicting declarations. I’ve flagged this pattern directly in my canonicalization deep dive: multiple rel=canonical tags will likely be ignored, and “in many cases this happens because tags are inserted into a system at different points such as by the CMS, the theme, and plugin(s).” If you’re debugging a canonical that “isn’t working,” count the tags in the rendered DOM first.

TIP

To compare the canonical signals a public page actually returns, run the Canonicalization Checker Free

  1. Check the rendered page and HTTP response together so stacked systems cannot hide a second declaration.
  2. Remove conflicting values and return one absolute canonical URL by the intended delivery method.
  3. Use Search Console URL Inspection separately to see Google’s selected canonical; this checker reports observable signals, not Google’s private decision.
Conflicting canonical declarations are not a vote Google can tally. Return exactly one intended canonical signal.

The completed result shows two HTML canonical values, one ending in widget and one ending in widgets. It labels the state as a signal conflict and a high override risk, while stating that this is not a claim about Google's indexed canonical.

Use absolute URLs, not relative

Google: “Use absolute paths rather than relative paths with the rel=“canonical” link element. Even though relative paths are supported by Google, they can cause problems in the long run.” The reason is mechanical — a <link> “accepts both relative and absolute URLs,” and a relative href like /page/ resolves against the current URL. On a malformed base or an unexpected path, that resolves to somewhere you didn’t intend. Always write the fully-qualified URL:

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

<!-- Bad: relative path -->
<link rel="canonical" href="/dresses/green/green-dress.html">

Same logic extends to host and protocol: point at the real, final version (https:// over http://, your canonical host). And don’t use a URL fragment as the canonical — “Google generally doesn’t support URL fragments.”

Self-referencing canonicals and pagination

A page naming itself as canonical is fine and recommended for your preferred version — it makes your intent unambiguous when other signals don’t all line up. When a check says a page has “no different canonical,” a self-referencing canonical satisfies that condition: it is an allowed same-URL declaration, not a competing target.

PaginationPagination splits a large set of content — product listings, blog archives, search results — across multiple sequentially numbered URLs. For SEO, each paginated page should be crawlable, indexable, and self-canonical; Google no longer uses rel=prev/next, but Bing still does. is where self-referencing matters most, and where people get it wrong. Do not canonicalize page 2, 3, 4… of a series back to page 1. “Specifying a rel=canonical from page 2 (or any later page) to page 1 is not correct use of rel=canonical.” Page 2 isn’t a duplicate of page 1 — it has different content. Instead, “self-referencing canonicals should be used on all paginated pages”: each page is its own canonical.

A related over-canonicalization mistake: a category or landing page that canonicalizes to a single featured article. The category page and the article aren’t the same content, so that’s a misuse too.

Don’t break the canonical’s visibility — and don’t point it at a broken target

A canonical only works if Google can crawl the page, read the tag, and isn’t getting a contradicting instruction. That’s a source-side health problem — it’s about whether Google can even see the tag on the duplicate URL. Three ways people defeat their own canonical this way:

  • Blocking the canonicalized URL in robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere.. If you Disallow the duplicate, Google can’t crawl it, so it never sees the canonical on it — and can’t pass consolidation. (Google adds the kicker that a robots-blocked URL “may still index URLs that are disallowed in robots.txt without their content.” Don’t use robots.txt for canonicalization.)
  • Setting the canonicalized URL to noindex. Contradictory instructions: noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. says “remove this page,” canonical says “consolidate this page.” Don’t mix them — pick one based on intent.
  • Returning a 4XX on the canonicalized URL. Same effect as noindex: Google can’t read the tag, so it can’t transfer consolidation.

And don’t declare conflicting canonicals across methods: “Don’t specify different URLs as canonical for the same page using different canonicalization techniques” — e.g. one URL in the sitemap and a different one in rel=canonical.

There’s a separate, target-side health problem people miss because it’s the opposite direction: the URL you’re pointing to has to be a clean landing spot. RFC 6596 says to avoid designating a target that is itself the source of a redirect, that chains to a different canonical, or that returns an error code — and Google’s own verification checklist adds confirming the target doesn’t carry a noindex tag. A canonical pointed at a redirecting, chained, noindexed, or erroring target is asking Google to consolidate onto a URL that can’t actually serve as the representative page — treat “does the target return a clean 200 with no redirect, no noindex, and no different canonical target of its own” as its own check, separate from whether the source page is crawlable.

If you’re using hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others., the canonical must point to a same-language page: “specify a canonical page in the same language, or the best possible substitute language if a canonical page doesn’t exist for the same language.”

Canonical vs 301 redirect vs noindex

These get treated as interchangeable. They aren’t — see the decision table in the Cheat Sheets tab. The short version:

  • rel=canonical — both URLs stay live and crawlable; you express a preference; Google consolidates signals onto the chosen one. A hint. Use it when both URLs must remain accessible and are genuinely duplicate or near-duplicate contentThe same or very similar primary content reachable at more than one URL. There's no general duplicate content penalty — the real costs are possible signal dilution, the wrong URL getting chosen, and less-efficient crawling. (parameters, print versions) — not as a general fix for syndicated contentSyndicated content is the deliberate, usually licensed republishing of the same article on other sites — wire pickups, partner reprints, or cross-posting. Because both parties know it's a copy, the SEO job is deciding which URL search engines should show, not eliminating a duplicate.; see below.
  • 301 redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. — users and bots are moved to the target; it’s the strongest consolidation signal. Use it when the duplicate shouldn’t be reachable at all.
  • noindex — a directive that removes a page from search entirely (the page must stay crawlable for Google to see it). Use it to remove, not consolidate.

Google’s own preference for in-site duplicates is the canonical: “We don’t recommend using noindex to prevent selection of a canonical page within a single site, because it will completely block the page from Search. rel=“canonical” link annotations are the preferred solution.” Evidence for this claim Google recommends rel=canonical rather than noindex when the goal is selecting a canonical within one site, because noindex removes the page from Search. Scope: Google Search guidance for duplicate pages within a single site. Confidence: high · Verified: Google: Specify a canonical URL

Why a canonical gets ignored

When Google picks a different canonical than you declared, it’s almost always one of these: the two URLs aren’t actually the same content; you have multiple or conflicting canonicals; it’s in the body; it’s relative/broken; the URL is robots-blocked or returns 4XX; or stronger signals (internal links, sitemap, redirects) point elsewhere.

The “not actually the same content” case bites JS-rendered sites hardest. John Mueller: “With JavaScript based sites, the content side is a common reason for this: for example, if you’re using a SPA-type setup where the static HTML is mostly the same, and JavaScript has to be run in order to see any of the unique content, then if that JS can’t be executed properly, then the content ends up looking the same.” If Google can’t see the unique content, it can’t tell your “duplicates” apart — and may consolidate or split them in ways you didn’t intend.

Bing treats rel=canonical the same way — a clarity signal, not a cure-all — and explicitly recommends it for syndicated content (ask the partner to point a canonical at your original). That’s a real divergence from Google: Google’s current troubleshooting guidance says “the canonical link element is not recommended for those who want to avoid duplication by syndication partners, because the pages are often very different.” Evidence for this claim Google's current troubleshooting guidance does not recommend rel=canonical as the general fix for duplication by syndication partners, because syndicated pages are often materially different from the original. Scope: Google Search guidance for syndicated-content duplication; canonical remains valid where the syndicated copy is a genuine duplicate or superset of the original. Confidence: high · Verified: Google: Fix canonicalization issues Google’s fix for that specific problem is asking the syndication partner to block their copy from being indexed on their end — not a canonical — because canonical only works when the target is genuinely the same content, and syndicated copies often aren’t close enough. On the toolkit, Bing’s framing is that “Canonical tags, redirects, hreflang, noindex, and IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. all support this clarity, but the foundation is a streamlined site that avoids unnecessary duplication.” One divergence worth knowing: for parameter duplication, Bing also offers URL Normalization in Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. as its preferred fix.

How to test it

The numbered workflow lives in the Checklists tab; the commands are in Scripts. The core moves:

  1. View-source the page — is there exactly one <link rel="canonical">, in the <head>, with an absolute URL?
  2. Compare to the rendered DOM (DevTools / GSC rendered HTML) — did it stay in the <head>, and is it still the only one after renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM.?
  3. curl -I the URL for the HTTP Link: rel="canonical" header (this is how you check PDFs and non-HTML).
  4. GSC URL Inspection — compare User-declared canonical to Google-selected canonical. A mismatch is your signal to investigate why. Two caveats: the indexed result can lag what’s actually happening by hours, and the live test only confirms the URL is fetchable right now — it can’t predict which URL Google will select as canonical.
  5. Crawl the site (Ahrefs Site Audit, free via Ahrefs Webmaster Tools for sites you verify; or Screaming Frog) to catch canonical issues at scale.

For the broader topic — how Google actually chooses a canonical from ~40 signals — see the canonicalization hub. Sibling issues like duplicate content and URL parametersThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO. are the usual reasons you’re reaching for a canonical in the first place.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.