rel=canonical Syntax: The Complete Reference

The rel=canonical syntax

The canonical tag is a single HTML link element placed in the head of a page. Its job is to tell search engines which URL is the preferred, indexable version when the same or substantially similar content is reachable at more than one address. The exact syntax is:

<link rel="canonical" href="https://www.example.com/page.html">

Three things make this element work correctly. First, rel="canonical" is the fixed keyword that identifies the relationship type — it does not vary. Second, href carries the preferred URL, written as a complete, absolute address rather than a partial path. Third, the element is self-closing in HTML and takes no closing tag. There is no additional required syntax beyond this: no wrapping element, no extra attributes needed for it to function. Simplicity is the point — a canonical tag is a hint, not a script, and search engines read it as a single, unambiguous declaration of preference.

Where the canonical tag must be placed

The canonical link element is only recognized when it appears inside the <head> section of the HTML document. A rel=canonical tag placed in the <body> is ignored by Google entirely — it carries no weight and produces no signal, regardless of how correctly it is otherwise written.

This matters in practice more than it might seem. Content management systems, page builders, and JavaScript frameworks sometimes inject markup into the body through widgets, embedded components, or client-side rendering that appends elements after the head has already closed. A canonical tag written by a plugin or a script that lands in the body — even briefly, even correctly formatted — does nothing. The fix is straightforward: verify placement by viewing the rendered HTML source (not just the template code) and confirming the <link rel="canonical"> element sits between <head> and </head>, ideally as early in the head as practical so crawlers encounter it without having to parse a large amount of markup first.

The HTTP header form of rel=canonical

The canonical signal is not limited to HTML markup. It can also be declared in the HTTP response header using the Link header, and Google has supported this form since 2011. The syntax is:

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

This header form exists specifically for content that has no HTML head to put a link element into — PDFs, images, and other non-HTML file types served directly by the server. If a site publishes downloadable PDFs that are reachable at multiple URLs (for example, through different referral or tracking paths), the HTTP header is the only mechanism available to declare a canonical preference for those files, since there is no document markup to modify.

The header and the HTML link element serve the same purpose and use the same underlying relationship, just expressed at different layers — one in the markup, one in the response headers. A site can use either depending on the content type, but as covered further down, using both on the same resource with different targets creates a conflict Google is likely to disregard.

The rules Google enforces

Beyond correct syntax, Google applies a small set of structural rules to how a canonical tag is written and where it points:

Exactly one canonical per page. A page should declare a single rel=canonical value; declaring more than one creates ambiguity.
Absolute URLs are recommended over relative paths. A relative href resolves against whatever host and protocol the page happens to be crawled on, which can cause problems if a staging environment, an alternate hostname, or an unintended protocol is crawled — the canonical would then point somewhere unintended.
Don't use a URL fragment (the portion after a #) as the canonical target. Fragments are not sent to the server and are not a valid basis for a canonical declaration.
The specification behind rel=canonical is documented in RFC 6596, and support for it is not proprietary to Google — Bing and other engines recognize the same underlying standard.

These rules exist because the canonical tag is meant to remove ambiguity about which URL is preferred. A relative path, a fragment-based target, or multiple competing declarations all reintroduce the exact ambiguity the tag is supposed to resolve — which is why Google treats malformed canonicals as unreliable signals rather than errors it corrects on the site's behalf.

Attributes and values Google ignores

Several attributes and configurations that look plausible on a canonical link element are simply not read by Google. Knowing what's ignored prevents wasted effort and false assumptions about control:

hreflang, lang, media, and type attributes attached to the canonical link element itself are ignored. These attributes belong to other contexts — hreflang, for instance, is declared through its own separate link elements, not layered onto the canonical tag.
Multiple rel=canonical tags on one page are not merged, averaged, or prioritized by order. Google's guidance is not to specify different canonicals through different techniques at all; when it encounters conflicting declarations, the well-documented behavior is that it is likely to ignore all of them and fall back to its own selection, meaning the site loses control over the outcome entirely.

The practical implication is that adding extra attributes to a canonical link element in hopes of layering additional meaning onto it — language targeting, media targeting, or anything else — accomplishes nothing. If those relationships need to be declared, they require their own separate markup, following their own separate syntax.

Valid vs invalid canonical examples

A correctly formed, self-referencing canonical on the preferred URL itself:

<link rel="canonical" href="https://www.example.com/shoes/running.html">

This is valid: absolute URL, single declaration, placed in the head, pointing to a real, indexable, 200-status page — in this case, itself.

Several common invalid patterns:

<link rel="canonical" href="/shoes/running.html">

Technically supported but not recommended — a relative path that resolves against whatever host is crawling the page, which risks pointing at a staging or wrong-protocol version.

<link rel="canonical" href="https://www.example.com/shoes/running.html#reviews">

Invalid use of a URL fragment as the canonical target; the fragment is not a valid basis for the declaration.

<link rel="canonical" href="https://www.example.com/shoes/running.html">
<link rel="canonical" href="https://www.example.com/shoes/running-shoes.html">

Two conflicting canonicals on one page — Google's documented behavior is to likely disregard both and choose its own canonical instead.

<body>
<link rel="canonical" href="https://www.example.com/shoes/running.html">
</body>

Correctly formed markup placed in the body instead of the head — ignored entirely regardless of syntax.

Frequently Asked Questions

Does the canonical tag need to be the first element in the head?

It does not strictly need to be first, but placing it early in the head, before large blocks of other markup, makes it easier for crawlers to encounter reliably and easier for anyone auditing the page's source to verify. There is no rule against placing it later in the head — the only firm placement rule is that it must be inside the head at all.

Can I use a canonical tag and a Link header canonical on the same page with different targets?

You can technically emit both, but doing so creates the same kind of conflict as multiple canonical tags in the HTML. Google's guidance is not to specify different canonicals through different techniques, and the documented behavior when signals conflict is that Google is likely to disregard the declarations and select its own canonical.

Is the HTTP header form only for PDFs?

PDFs are the most common use case since they lack an HTML head, but the header form applies to any non-HTML resource served over HTTP — images and other downloadable file types included. Any HTML page can also technically carry the header, though the HTML link element is the standard method for HTML content.

Why does Google ignore hreflang or lang attributes placed on the canonical link?

Because those relationships are defined by their own separate markup with their own syntax. The canonical link element has one job — declaring a preferred URL — and Google's parsing of it does not extend to attributes that belong to unrelated declarations, even when they're physically attached to the same tag.

What happens if my canonical URL has a typo in the domain?

Google evaluates the canonical target as a real URL it can attempt to crawl. If the href points to a domain or path that doesn't resolve to a valid 200-status page, Google treats the canonical as unreliable and is likely to disregard it in favor of its own selection, the same way it handles a canonical pointing to a 404 or a redirect.

rel=canonical Syntax Reference