Canonical tag – how rel=canonical signals the preferred URL and why implementation often goes wrong

Definition

A canonical tag is a line of HTML in the <head> that tells search engines which URL is the preferred version of a page when several URLs have similar or identical content.

Google, Microsoft and Yahoo introduced the canonical tag in 2009 as a way of handling duplicate content without blocking or redirecting – Google announced it in the blog post Specify your canonical. It is an underrated part of technical SEO, and one that is often implemented incorrectly.

Getting canonical tags right is less about understanding the syntax, which is trivial, and more about understanding why they go wrong.

What the canonical tag looks like

The canonical tag is placed in the <head> of the page and points to the preferred URL:

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

The URL should be absolute (include the protocol and domain), point to an actual indexable page, and return a 200 status code. It can point to itself (a self-referencing canonical) or to another URL.

There is also an HTTP header alternative for non-HTML resources (PDFs, images):

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

Both are equivalent from a search engine's point of view.

What the canonical tag actually says

Crucially, a canonical is a hint, not a directive – something Google itself stresses in its documentation on canonicalisation. Search engines use it as a strong signal of which URL should be treated as the original, but they reserve the right to ignore it if other signals say otherwise. Those other signals include:

• Internal linking (which URL gets the most internal links?)
• Inbound external links (which URL gets backlinks?)
• Sitemap.xml (which URL is listed there?)
• Hreflang (do language or regional variants point to another URL?)
• The actual content (are the pages really alike?)

If your canonical tag says A but everything else points to B, Google will probably index B. That is not Google's fault – your canonical tag was not credible.

When a canonical is needed

The canonical tag solves a specific problem: the same or very similar content being reachable through several URLs. Common scenarios:

• Parameters in the URL. /shoes and /shoes?utm_source=newsletter are the same page to a user, but two different URLs to a search engine. The canonical points back to /shoes.
• Filters and sorting. /shoes?colour=black and /shoes?sort=price are often variants of a category page. Either you let them be indexed (if they have search traffic potential of their own) or you canonicalise them back to the unfiltered page.
• Tracking parameters. Anything that starts with utm_, fbclid, gclid. These should be canonicalised away.
• HTTP/HTTPS and www/non-www. This is best solved with a 301 redirect, but a canonical can complement it if a redirect is not possible for some reason.
• Cross-domain duplicates. If the same article is published on both your website and a partner's, the partner can set a canonical pointing to your original page.
• Print versions and AMP. The simpler or specialised version points to the main version.

Common mistakes – and their consequences

This is where most projects fall down, even at agencies that should know better.

• The canonical points to a redirect. Canonical → 301 → final destination. Search engines follow the chain, but the signal weakens and it can take longer for the right URL to be indexed.
• The canonical points to a 404 or a noindex page. The canonical tag then contradicts itself – the page says "the original is over there", Google goes there and finds that the original cannot be indexed.
• Every page points to the homepage. A classic implementation mistake in CMS templates. The result: the whole website consolidates towards a single URL and almost all the content drops out of the index. This happens more often than you would think.
• A canonical combined with noindex. This confuses search engines. Either you want the page indexed (in which case, send a clear canonical) or you do not (in which case, send noindex without a canonical, or with a self-referencing one).
• A cross-domain canonical in the wrong direction. You publish your article on your own website first. Then a partner publishes the same article – and you set a canonical to the partner. The effect: the partner gets the ranking signals.
• Different canonicals in the <head> and in the HTTP header. If they point to different URLs, Google will pick one – and there is no telling which.
• Several canonical tags on the same page. If a page has more than one rel="canonical" in the <head>, Google ignores all of them. This happens easily when a theme sets one tag and a plugin, embed or CMS template sets another.
• The canonical is set via JavaScript. Google renders JavaScript, but that can take longer. A static canonical in the HTML is more reliable.

Incorrect canonical tags are one of the most common technical reasons a website fails to show up in search – we cover more of these reasons in Website not ranking? The 10 most common reasons.

Canonical vs 301 redirect – which should you choose?

If a URL should never be visited by users again (old, renamed, moved), use a 301. It is a stronger signal and removes the risk of the wrong URL continuing to rank.

If both URLs should remain available to users (filters, parameters, alternative views) but only one should be indexed, use a canonical.

In practice they are often combined: a 301 for a real move, a canonical for parameter variants and alternative views.

Canonicals and paginated series

Google used to recommend rel="next" and rel="prev" for paginated lists, but in 2019 it confirmed that it no longer uses them. Today the recommendation is either to:

• Give each paginated page a self-referencing canonical and keep it indexable, so the deeper pages can rank too.
• Or, if only the first page should rank, set noindex (but not nofollow) on pages 2 onwards.

Canonicalising all paginated pages to page 1 is an old recommendation that is now considered wrong – the content of each page is unique (different products), so a canonical to page 1 contradicts what is actually on the page.

Canonical tags in Webflow

In Webflow, you enter the domain that Webflow then uses to give every page a self-referencing canonical automatically – each page points to itself as the original unless you specify otherwise. That is enough for most websites and prevents the most common duplicate content problems without any configuration. It also works for pages in several languages, just like the automatic hreflang feature.

When you need to point a page to another URL, you can set a custom canonical per page under Page Settings, and per CMS item in the collection's settings. That is where you solve parameter variants, cross-domain canonicals and alternative views. Because Webflow places the tag statically in the HTML, you avoid the delay that JavaScript-set canonicals can cause.

How to find canonical problems on your website

In practice, use a crawler (Screaming Frog, Sitebulb, Ahrefs Site Audit) and look for:

• Pages with no canonical at all
• Pages where the canonical points to a URL other than the page itself (check that it is deliberate)
• Canonicals pointing to non-200 status codes
• Canonicals pointing to URLs that are not in sitemap.xml
• Canonical chains (canonical → 301 → ...)
• Canonical conflicts (the HTML says A, the HTTP header says B)

Search Console also reports "Alternate page with proper canonical tag" and "Duplicate, Google chose different canonical than user". The latter is a warning sign – Google does not trust your canonical.

Summary

A canonical tag is a hint to search engines about which URL is the preferred version of a page. It is central to handling duplicate content and URL parameters without blocking or redirecting. It is also the technical SEO detail where we most often see mistakes slip into production. Make sure every canonical points to an indexable 200 URL, is consistent between the HTML and the HTTP header, and does not contradict other signals such as internal linking and the sitemap.