What Is a Canonical Tag? When to Use It and the Common Mistakes

A canonical tag is an HTML signal that tells Google which URL is the main version when the same or very similar content can be reached at more than one URL. It is added to the page's head as a link tag with the rel="canonical" attribute and points at the main URL. It is a simple line; set up wrong, it can drop half an e-commerce site out of the index overnight.

Why canonicals are needed

When the same content exists at several URLs, Google treats them as duplicates and picks one on its own. That choice is not always the version you want. Links and signals pointing at the page are also split between the different URLs; ten links spread over three URLs do less than ten links pooled on one. The canonical merges those signals and keeps the index clean.

One thing to keep in mind: a canonical is a hint, and Google is not obliged to follow it. It usually does; but if the pages are genuinely different, or other signals (internal links, the sitemap, redirects) point at another URL, it makes its own choice. The line 'Google chose a different canonical than the user' in the Search Console page indexing report describes exactly that.

When to use a canonical

• A self-referencing canonical on every indexable page. This should be the default; copies with parameters added then point at the main page automatically.
• The same product opening from several category paths: if /men/shoes/product-x and /sale/product-x are the same page, one must be chosen as the main one.
• Tracking parameters: utm_source, gclid, fbclid and the like do not change the content; the canonical should point at the clean URL.
• Alternative presentations such as print versions, AMP or mobile subdomains.
• Content republished on another site: a copy of an article published with permission can point at the original with a cross-domain canonical.

There are cases a canonical does not solve. If the page has been removed entirely, the right tool is a 301 redirect. If the page should never be indexed, use noindex. Versions in different languages have hreflang; pointing one at the other with a canonical drops that language version out of the index.

Choosing between canonical, 301 and noindex

The three are often confused; to decide, ask this question: what should the user see when they open this URL?

• The page should open and show its content, but the main version should appear in search: canonical. Filtered category pages and URLs with tracking parameters belong here.
• The page no longer exists and another page has taken its place: 301 redirect. When the user opens the old address they go to the new one, and the links' value moves with it.
• The page should open but never appear in search: noindex. Thank-you pages, on-site search results and account pages go here.

Using canonical and noindex together on the same page sends a contradictory signal: one says 'the main version is this', the other says 'do not count this page'. In such cases Google decides for itself which to honor; you do not control the outcome. Pick one of the two.

E-commerce filter and parameter pages

This is the messiest area. When the color, size, price range and sort filters on a category page combine, thousands of URLs appear. Leaving them all as they are eats crawl budget; pointing them all at the category with a canonical makes some combinations with real search demand invisible.

A concrete example: say a shoe store's sneaker category has five color, ten size and four price range filters. Those three filters alone produce two hundred combinations; multiplied by the sort options the number quickly approaches a thousand. The vast majority of these URLs are searched by nobody. But a few combinations like 'white sneakers' have serious search volume, and if they are pointed at the category with a canonical, you have no page left to meet that demand.

A practical split can be made like this:

• Sort (by price, newest first) and view (list, grid) parameters do not change the content; they should point at the category page with a canonical.
• Filter combinations with no search demand (red, size 8, under $50) can also point at the category with a canonical, or get noindex.
• Filters with search demand (red sneakers, leather men's wallet) should behave like a separate landing page: their own canonical, their own title, if possible their own description and internal links pointing at them.

Decide which combinations have demand with keyword research. Entering the category name as a seed into the keyword generator quickly lists which filter combinations users search for directly.

Do not combine a canonical with a robots.txt block. If Google cannot crawl the blocked page, it cannot see the canonical tag inside it either; the signal is wasted.

Pagination

Pages 2, 3 and 4 of category and blog listings are among the places most often done wrong. The common mistake is pointing every page at the first page with a canonical. That tells Google page 2 is a copy of page 1; but the products on it are different. The result is that products on deep pages get discovered late, or never.

The right approach is for each paginated URL to point at itself: /category?page=3 references itself. If you have a "view all" page that loads at a reasonable speed, you can point the paginated URLs at it; but loading hundreds of products on one page ruins your Core Web Vitals. Google has not used rel="prev" and rel="next" as an indexing signal for a long time; adding them does no harm, but it solves nothing either.

http/https and www versions

The same site can open from four different addresses: the http and https versions, each with and without www. Only one of these should be the main one. The first tool here is a redirect: the other three versions should go to the main version in one step, with a 301. The canonical on every page of the main version should then point at the main version again, with a full, absolute URL.

Common mix-ups:

• The canonical says http while the site redirects to https. A canonical should not point at a URL that redirects.
• The canonical has www while the sitemap does not. Every signal should name the same version.
• Using a relative canonical (like href="/page"). It can technically work, but it creates ambiguity about domain and protocol; write an absolute URL.
• Trailing slash differences: if /services and /services/ serve the same content, one should redirect to the other and the canonical should use a single form.

Other common mistakes

• More than one canonical tag: when the theme adds one and a plugin adds another, Google may ignore both. Make sure there is only one in the page source.
• A canonical pointing at a 404 or noindex page. The target should be an indexable page returning 200.
• The whole site pointing its canonical at the homepage. Usually a template error, and it drops the site out of the index fast; check a few different page types before going live.
• Putting the canonical in the body. Google only honors the tag inside the head; even an element accidentally placed in the head that closes the head early can invalidate the canonical.
• A canonical added or changed later with JavaScript. It can work, but it causes trouble if it contradicts the value in the raw HTML; output the correct value server-side.
• The HTTP header and the HTML tag contradicting each other. The Link header is used for non-HTML files such as PDFs; do not give both with different values on the same page.

How to detect canonical problems

1. Open the page indexing report in Search Console. Examine the 'Google chose a different canonical than the user' and 'Duplicate without user-selected canonical' groups.
2. Enter the URL you suspect into the URL inspection tool; you see the canonical Google chose next to the one you declared.
3. Crawl the site end to end with a crawler. List in bulk the pages with no canonical, canonicals that do not point at themselves, and canonicals going to a redirect or a 404. weranklab's site audit reports these checks page by page; because it runs on credits, you start a crawl only when you need one, such as after a big change.
4. Wait a few weeks after the fix. Google updating its canonical choice depends on recrawling, and that takes time on large sites.

The canonical looks like a single item on the technical SEO checklist; on e-commerce sites it is one of the main factors deciding how clean the index is. A wrong canonical template can drop hundreds of pages out of search overnight; a correctly built one pools the signals scattered across those same pages in one place. To watch the effect, track the related category keywords; if you note the fix date on your rank tracking charts, you can read the result even months later.