Canonical URLs
The one URL you nominate as the indexable version of a page, how the rel=canonical hint is actually weighted, and what a split canonical costs you when an agent needs a link to cite.
Karl-Gustav Kallasmaa, Founder & CEOLast updated A canonical URL is the single address a site nominates as the indexable version of a page that is reachable at several addresses. The rel="canonical" link relation is the standard way to state that preference, and search engines treat it as a strong signal rather than a command.
The relation itself is standardised. RFC 6596, The Canonical Link Relation, an Informational RFC published in April 2012, defines it as specifying "the preferred IRI from a set of resources that return the context IRI's content in duplicated form". That is the whole contract: it says this content also lives here, and here is the address I would rather you used.
How the signals are weighted
Google's canonicalization documentation lists several methods and does not treat them as equal:
- A redirect is a strong signal that the redirect target should become canonical. It is the strongest available because it removes the alternative entirely.
- A `rel="canonical"` annotation — in the HTML
<link>element or an HTTPLinkheader — is a strong signal that the specified URL should become canonical. - Inclusion in a [sitemap](/glossary/xml-sitemaps) is a weak signal that helps a listed URL become canonical.
Two constraints in the same document cause most real failures. Use absolute paths, not relative ones, with the rel="canonical" element. And do not specify different URLs as canonical for the same page through different techniques — a sitemap saying one thing and a <link> element saying another is not a stronger signal, it is a contradiction the engine resolves for you.
It is also worth reading the documentation's own hedge: none of these methods are required, and a site will likely do fine without specifying a preference, because the engine will pick a version regardless. Canonicalization is how you take part in that decision, not how you overrule it.
Why it matters when the reader is an agent
A retrieval system cites the URL it fetched. That single sentence contains most of the argument.
If the same article is served at /guide, /guide/, /guide?ref=newsletter and /amp/guide, an assistant answering three different questions can end up pointing at three different addresses. Nothing is broken from a reader's point of view — each link works — but the reference history that makes a URL look like the established home of a claim is split four ways. Source citation behaviour rewards the address that keeps appearing, and duplicate addresses guarantee that no address does.
The second effect is on crawling and indexing budget. Every duplicate address is a separate fetch. A site that generates a distinct URL per tracking parameter spends its crawl allowance re-reading the same page instead of finding the new one.
Failure modes
- The self-referential canonical on a paginated set. Page 2 declaring page 1 as canonical tells the engine page 2 has no distinct content. Its items then have no indexable home. Paginated pages should be canonical to themselves.
- The site-wide canonical. A template bug that points every page at the homepage is the single most destructive canonical error, because it is a strong signal saying none of this exists separately. It is silent: nothing breaks for a human visitor.
- Canonical to a blocked URL. Nominating a target that robots.txt disallows, or that returns a
noindex, asks the engine to consolidate onto something it cannot read. The signal is discarded and the choice reverts to the engine. - Relative canonicals under a rewriting proxy. A relative path resolved against an unexpected base yields a canonical pointing at a URL that does not exist. This is why the absolute-path guidance exists.
- Cross-domain canonicals used as a shortcut for syndication. Legitimate when the same content genuinely lives elsewhere. It also means you are asking every engine to attribute the content to the other domain — which is what you want when syndicating and a serious mistake when the other domain is a scraper.
- Canonical and redirect disagreeing. A page that redirects to A while declaring B canonical sends two strong signals in opposite directions.
A practical check
- Fetch each important page as a plain HTTP request, not through a browser, and read the
<link rel="canonical">in the raw HTML. A canonical injected by client-side JavaScript may or may not be seen. - Confirm the value is absolute, and that fetching it returns 200 rather than a redirect.
- Confirm the canonical target appears in your sitemap and the alternates do not.
- Confirm each paginated page is canonical to itself.
- Confirm parameterised variants — tracking, session, sort order — resolve to one canonical.
None of this makes content better. It decides which address gets credit for content that is already good, and that is the whole reason it is worth an hour.
Frequently asked questions
Is it a directive?
No. Google calls it a strong signal and reserves the right to choose a different canonical.
What is the strongest consolidation signal?
A redirect, followed by rel="canonical", followed by sitemap inclusion.
Must it be absolute?
Google's documentation says to use absolute paths with the rel="canonical" element.
Does it affect AI citations?
Indirectly but materially: assistants cite the URL they fetched, so duplicate addresses split the reference history across copies.
Terms related to Canonical URLs
The two separate stages that decide whether a page can be retrieved at all, and the reason a serving rule on a blocked page is never read.
A machine-readable list of the URLs you want discovered, bounded by the protocol at 50,000 URLs and 50MB per file, and a hint rather than an instruction.
The standardised file that tells crawlers what they may fetch, now the main place where AI training and AI retrieval access are decided separately.
How an AI answer attributes what it says to the pages it read, and why a citation is a distinct outcome from a click or a mention.