Where the canonical tag goes
Add a canonical tag by placing one <link rel="canonical" href="..."> element inside the page's <head>, with the absolute URL of the version you want indexed. Google accepts the element only in the <head>; a canonical placed in the <body> is ignored.
Each page should carry exactly one canonical. Google's guidance is not to declare different canonicals through different techniques on the same page, for example one URL in the HTML head and another in an HTTP header. When a page has multiple conflicting declarations, the widely observed behavior is that Google is likely to ignore all of them and fall back to its own selection.
Position inside the head matters too. According to Google's valid page metadata guidance, Google stops reading the head at the first element that does not belong there, such as an iframe or img, and treats everything after it as outside the head. The valid head elements are title, meta, link, script, style, base, noscript, and template. In this head, the canonical sits after an image and is never read:
<head>
<meta charset="utf-8">
<title>Blue Widgets</title>
<img src="/pixel.gif" alt=""> <!-- Google treats the head as ending here -->
<link rel="canonical" href="https://www.example.com/blue-widgets/">
</head>View Source still shows the canonical inside <head>, so this passes a visual check. Placing the canonical near the top, straight after the charset and title, means a later element cannot cut it off.
How to add a self-referencing canonical tag
A self-referencing canonical is a rel=canonical tag on a page that points to that page's own preferred URL. Google recommends it as a best practice. John Mueller has described self-referencing canonicals as "not critical," in the sense that a site will not break without them, but they remove ambiguity whenever a page is reachable through variant URLs, such as with a tracking parameter or a different trailing slash.
To add one, open the page's HTML (or its template, if a CMS generates the page) and insert the link element inside the head, using the exact absolute URL of the preferred version:
<head>
<title>Example Page Title</title>
<link rel="canonical" href="https://www.example.com/page/" />
</head>The href must match the preferred, indexable version exactly: same protocol, same host, same case, same trailing-slash convention.
Absolute vs relative canonical URLs
An href can be written as an absolute URL (https://www.example.com/page/) or a relative one (/page/), and both are technically supported. Google's advice is to use absolute URLs: "Use absolute paths rather than relative paths with the rel=canonical link element."
A relative canonical resolves against whatever host and protocol the page happens to be crawled on. Google warns that relative paths "can cause problems in the long run," for example if a staging copy is crawled: its relative canonical resolves to the staging host rather than production. A related trap is the protocol-less value example.com/page, which looks absolute but is read as a relative path and resolves to something like https://www.example.com/current-folder/example.com/page. Writing the full URL with its scheme removes both problems.
Attributes and values that break the tag
A tag in the right place can still be discarded because of what it contains. Check each canonical against this list:
- No
hreflang,lang,media, ortypeattribute. Google's canonicalization documentation says canonical annotations carrying these attributes "are not used for canonicalization." Language alternates belong in separaterel="alternate"links. - Only on
<link>. The HTML standard defines the canonical keyword for thelinkelement;rel="canonical"on an<a>tag is invalid. - No fragment. Google generally does not support URL fragments, so
https://www.example.com/page/#reviewsis the wrong target. - A non-empty
hrefthat parses as a URL. An empty or malformed value gives Google nothing to use. - A target that returns a 200 and is indexable. The canonical should not name a URL that redirects, returns an error, carries noindex, or is blocked by robots.txt.
This fails two rules at once:
<link rel="canonical" hreflang="en" href="/page/#top">How to add a canonical to a non-HTML file with an HTTP header
Files with no HTML head, PDFs being the usual example, can still carry a canonical. Since 2011, Google has supported rel=canonical in an HTTP Link response header, for web search results. The header looks like this, with the target in angle brackets:
Link: <https://www.example.com/downloads/file.pdf>; rel="canonical"It is configured at the server or in application code. In Apache (mod_headers), append keeps any other Link values the server sends, while set would replace them:
<Files "white-paper.docx">
Header append Link "<https://www.example.com/downloads/white-paper.pdf>; rel=\"canonical\""
</Files>In nginx, note that add_header inside a location block stops that block from inheriting headers defined at the server level:
location = /downloads/white-paper.docx {
add_header Link '<https://www.example.com/downloads/white-paper.pdf>; rel="canonical"';
}For ordinary HTML pages, prefer the <link> element, which is visible in source and to every tool. Running a header and an element that disagree is a conflict with no published tiebreaker; John Mueller said in 2026 that "There's no publicly defined order of precedence for metadata reconciliation here."
If JavaScript writes the canonical
On sites where the head is assembled in the browser, the canonical may be added by script. Google can pick up a canonical injected during rendering, with two conditions from its JavaScript guidance: the injected tag must be the only canonical on the page, and "You shouldn't use JavaScript to change the canonical URL to something else than the URL you specified as the canonical URL in the original HTML."
The safer arrangement is to have the server send the canonical in the initial HTML and let scripts leave it alone. To see whether a script is involved, compare two views of the same page: View Source shows what the server sent, while the browser DevTools Elements panel shows the DOM after scripts ran. A canonical that appears only in Elements is JavaScript-injected; one whose value differs between the two views is being rewritten. Screaming Frog reports the first case as "Canonical Only In Rendered HTML" when rendering is enabled.
How to test that your canonical tag works
- View Source: confirm the raw HTML contains exactly one
rel="canonical"in the head, pointing at the intended URL, with no invalid element before it. Search for "canonical" and count the matches. - curl: header canonicals never appear in View Source. This prints any
Linkheader from a real GET request:curl -s -D - -o /dev/null https://www.example.com/page/ | grep -i '^link:' - URL Inspection: in Search Console, URL Inspection reports the "User-declared canonical" and the "Google-selected canonical." If they differ, Google did not accept the declared preference. Only the indexed result shows Google's choice; Search Console Help is explicit that "the live test cannot predict whether or not the tested version will be considered canonical." After a fix, allow up to about two weeks for Google to re-evaluate.
- A crawler: tools such as Screaming Frog crawl a whole site and report canonicals in bulk, flagging missing, self-referencing, multiple, and conflicting declarations across thousands of URLs.
Adding canonicals at scale
Hand-editing the head works for a few pages; most sites need canonicals applied across hundreds or thousands of URLs. There are two general approaches:
- CMS or plugin fields: most content management systems and SEO plugins expose a canonical field per page or generate one from a template, so no page needs hand-editing.
- Templates or code: custom sites generate the tag in the page template on every render. Build it from the page's stored URL with a fixed scheme and host, not from the requested URL, which can carry tracking parameters or a forged host.
Whichever route is used, keep every signal consistent. The canonical, the sitemap, and internal links should agree on the same URL form, because a mismatch between rel=canonical and those other signals is exactly what leads Google to override the declared canonical.
Frequently asked questions
Can I put the canonical tag in the body of the page instead of the head?
No. Google only accepts rel=canonical in the HTML head, and a canonical placed in the body is ignored. It also has to appear before any invalid element in the head, because Google stops reading the head at the first one.
Can a page have more than one canonical tag?
A page should have exactly one. Google's guidance is not to declare different canonicals through different techniques on the same page, and the widely observed behavior with multiple conflicting declarations is that Google ignores all of them and selects its own canonical.
How do I add a canonical tag to a PDF?
PDFs have no HTML head, so the canonical goes in an HTTP Link header sent by the server, in the form Link: <https://www.example.com/downloads/file.pdf>; rel="canonical". Google has supported this since 2011, for web search. It is set in the server configuration or application code, not in the file.
Should canonical URLs be absolute or relative?
Google recommends absolute URLs. Relative canonicals resolve against whatever host and protocol the page is crawled on, which Google warns can cause problems if a staging or alternate host is ever crawled.
Does Google read a canonical tag added with JavaScript?
It can, when it renders the page, but the injected tag must be the only canonical on the page and should not change a value already set in the original HTML. Sending the canonical in the server's HTML is the more dependable approach.
What is the fastest way to check if my canonical tag is working?
View the page's raw HTML source to confirm the tag is present and correct, then check the URL in Search Console's URL Inspection tool to see whether the Google-selected canonical matches the one declared. Use the indexed result, not the live test, for Google's choice.