Canonical tags: pointing duplicates to one address
A canonical link tells search engines which address is the main version of a page. When to use one, how to set it, how it goes wrong, and how to check it.
In this guide
Why duplicates happen
Lighthouse's documentation explains the problem. When several pages have similar content, search engines treat them as duplicate versions of one page, and choose one as the canonical, or primary, version to crawl more. Its example: desktop and mobile versions of a product page are often considered duplicates.
Common causes:
- the same page with and without
www, or overhttpandhttps; - links with query parameters added on the end, for example by other sites or by campaigns. Lighthouse notes that with a canonical link, search engines consolidate those URLs into your preferred version;
- versions made for a different device;
- sorted or filtered copies of a list;
- syndicated content, where your article is copied onto another site.
A canonical link helps search engines pick the right address. The 2025 Web Almanac lists what goes wrong without one: crawlers may split ranking signals, waste crawl budget, and show the wrong address in results.
Lighthouse also names two side benefits. It simplifies tracking, since one address is easier to track than many, and it improves the ranking of syndicated content by consolidating the syndicated links to your original.
What a canonical tag is, and is not
The Almanac is clear on one point: canonical tags are not directives like a robots noindex. They are strong hints, supporting signals that reduce ranking problems when used correctly. A search engine can still choose a different address if your signals conflict. Make them agree: use the same address in your links, your sitemap, your redirects and your canonical.
MDN defines the canonical value of rel as the preferred URL for the current document, which helps search engines reduce duplicate content.
How to set it
Lighthouse shows two ways.
In the page's head:
<link rel="canonical" href="https://example.com/product/blue-chair/">In an HTTP header:
Link: <https://example.com/product/blue-chair/>; rel="canonical"The Lighthouse example writes the header value without angle brackets. The Link header as described by MDN uses them around the address, so use them.
The head method is by far the more common one. The Almanac found a canonical link on 68% of desktop pages and 67% of mobile pages in 2025, and found the header form on about 0.5%. The header has one advantage: it works for files that have no head, such as PDFs.
Most pages that have a canonical point to themselves. The Almanac found that 7% of desktop pages and 9% of mobile pages had a canonical that pointed somewhere else, which it calls canonicalized pages.
The rules, from Lighthouse
A page fails Lighthouse's canonical audit if:
- there is more than one canonical link;
- the link is not a valid URL;
- it points to a page for a different region or language;
- it points to a different domain;
- it points to the site's root. Lighthouse notes that this may be valid for AMP or mobile variations, but it treats it as a failure.
Its general guidelines:
- Make sure the canonical address is valid.
- Use secure
httpsaddresses whenever possible. - If you use
hreflanglinks for language or country versions, make each page's canonical point to its own language or country version. See hreflang for English and Spanish. - Do not point the canonical to a different domain, because Yahoo and Bing do not allow it.
- Do not point lower-level pages to the root page unless their content is the same.
Put it in the raw HTML
A page's code arrives as raw HTML, and scripts may change it after loading. The Almanac found that only about 2% of sites have a canonical that is missing in the raw HTML but present after rendering. Most put it in the raw HTML. It states that the most reliable approach is to include the tag in the raw HTML so it stays the same after rendering, and that a canonical added by JavaScript brings more room for error. Where the raw and rendered versions disagree, which the Almanac found on 0.7% of pages, the signal is undermined.
For the same reason, keep the tag high in the head, before any invalid element. The Almanac warns that an invalid element, such as an img or a div, in the head can cause the browser to treat the head as ended, and the tags after it, canonical links included, stop working. See robots.txt and noindex.
Canonical, redirect or noindex?
They solve different problems:
| You want to | Use |
|---|---|
| Keep both addresses working but name one as the main one | A canonical link |
| Retire the old address, so visitors and crawlers always land on the new one | A redirect. See redirects and status codes |
| Keep a page out of results | noindex. See robots.txt and noindex |
Do not use them against each other. A page that carries a canonical to another address and also a noindex sends two different messages.
In WordPress
WordPress core prints a canonical link for single posts and pages, with a filter that lets a plugin change the address. SEO plugins also print one, and the plugin normally replaces core's. If your page source contains two canonical links, Lighthouse will fail the page. Open the page source, search for rel="canonical", and count. See themes and plugins.
Canonicals and speed
Duplicate addresses are also a load issue: a crawler that follows hundreds of parameter variations makes hundreds of requests to your server. A clean canonical setup, with consistent links, reduces that waste. It also keeps analytics and cache keys tidier, since one address is easier to track and to cache than many. See caching explained for why addresses that differ by a parameter can be separate cache entries.
How to check
- View the page source and search for
rel="canonical". There should be one, with the address you expect. - Check the header. In the Network panel, select the page and look for a
Linkheader. - Compare the address with the one in your address bar, your sitemap and your internal links. They should match in scheme, host, path and trailing slash.
- Run Lighthouse. The audit is named for a valid
rel=canonicallink. - Test a parameter. Open the page with
?utm_source=teston the end and check that the canonical is still the clean address.
Mistakes to avoid
- Two canonical links. A theme and a plugin both printing one.
- A canonical to the home page from every page.
- Relative or `http` addresses where
httpsis expected. - A canonical to a redirected or missing address.
- A canonical added only by script.
- Pointing English pages to Spanish ones, or the reverse.
- Treating it as a command. It is a hint, so keep your other signals consistent.
Check your own page
Run the free audit and read the SEO findings for a canonical failure. Then open your home page and one deep page in the page source and check the canonical on each.
Sources
- Document does not have a valid rel=canonical in the Lighthouse documentation: the benefits, the failure conditions, the two ways to set it and the guidelines.
- SEO chapter, Web Almanac 2025: what canonicals do, how common each method is, and raw versus rendered canonicals.
- The rel attribute and the Link header on MDN.
- WordPress core: link-template.php and default-filters.php: the canonical link for singular pages.
Start here
Free website audit
Live Google data for any public page: mobile and desktop.
Mobile + desktop · Lighthouse lab test · Real-user Chrome data when Google has it
Rather have this done for you? Technical SEO · Book a call