By Mehdi HassanMarketing sites create duplicate URLs constantly without anyone intending to. A campaign link adds UTM parameters. A CMS serves the same post with and without a trailing slash. A designer duplicates a landing page for an A/B test. Each version is a separate URL to a search engine, and canonical tags are how you tell it which one counts.
This guide explains canonical tags in plain English and walks through the cases that come up on startup and SaaS sites. It's part of our technical SEO guide for marketing websites, which covers how canonicals fit with noindex, redirects and sitemaps.
What is a canonical tag?
A canonical tag is a link element in a page's head, written as link rel=canonical with an href, that names the preferred URL for that content. When search engines find several URLs with the same or very similar content, the canonical tells them which one to index and where to consolidate signals such as links.
Google treats the canonical as a strong hint rather than a directive. It weighs the tag alongside other signals: which URL your internal links use, which one is in the sitemap, redirects, https versus http and whether the content really matches. When those signals agree, Google almost always follows your canonical. When they conflict, it may choose its own, and Search Console reports this as duplicate, Google chose different canonical than user.
When should you use canonical tags?
Use canonical tags on every indexable page, pointing to itself, and on any URL that duplicates another page while still needing to stay reachable. The second case covers most marketing-site duplicates: tracking parameters, campaign variants, syndicated content and URL format variations.
Situation on a marketing site | Canonical should point to |
|---|---|
Any normal indexable page | Itself, using its exact final URL |
URL with UTM or click-ID parameters | The clean URL without parameters |
Paginated blog archive, page 2 and beyond | Itself, not page 1 |
Landing page variant for paid traffic | The main page, or noindex the variant |
A/B test variant on a separate URL | The original page |
Article republished on Medium or a partner site | Your original article, if the partner allows it |
Print or AMP-style alternate version | The main page |
Should every page have a self-referencing canonical?
Yes. Every indexable page should have a canonical tag that points to its own clean URL. A self-referencing canonical protects the page against duplicates you didn't anticipate, such as someone linking to it with parameters, and removes any ambiguity about which format you prefer.
The canonical URL should be absolute and exactly match the version you want indexed: https, your chosen host with or without www, and your trailing-slash convention. Webflow and Framer can output self-referencing canonicals from their site-level SEO settings; check your platform's current documentation for where the option lives. In Next.js, set metadataBase and an alternates canonical value in each route's metadata. Whatever the platform, the canonical has to be in the server-rendered HTML, not set later by JavaScript; our guide to JavaScript SEO explains why.
How do canonical tags handle UTM and tracking parameters?
Canonical tags handle tracking parameters by pointing every parameterized URL back to the clean version. When someone shares yourdomain.com/pricing with a UTM string attached, the page's self-referencing canonical still names yourdomain.com/pricing, so Google consolidates signals there.
This works automatically if every page outputs a canonical built from its path, not from the full requested URL including the query string. That's the detail to check: some custom setups build the canonical from the current URL and accidentally include the parameters. Never use UTM parameters on internal links either; they create duplicate URLs and overwrite the original traffic source in analytics. Our guide to Google Tag Manager setup covers cleaner ways to track internal clicks.
Should paginated blog pages canonicalize to page one?
No. Page 2, page 3 and later pages of a blog archive should each have a self-referencing canonical. They list different posts, so they aren't duplicates of page one, and pointing them all to page one can stop search engines from crawling the posts linked only from deeper pages.
Google no longer uses rel=next and rel=prev as indexing signals, so pagination relies on plain crawlable links between pages. Make sure each archive page links to the next with a real anchor tag, and that every post is also reachable from a category or hub page. For blogs and resource libraries, linking from topic hubs matters more than archive depth; our internal linking strategy covers that structure.
How do you canonicalize landing page variants and A/B tests?
Canonicalize near-duplicate landing page variants and A/B test URLs to the main page, or set paid-only variants to noindex. Either way, the version you want ranked is the only one search engines treat as primary.
If a variant exists only for ad traffic and is never linked from the site, noindex is the cleaner choice: it can't compete with the main page, and its content can differ freely. If a variant might be shared or linked, a canonical to the main page consolidates any links it earns. For split tests that serve different content at the same URL, no canonical change is needed. For tests that redirect visitors to a variant URL, use a temporary 302 and a canonical on the variant pointing to the original.
Hypothetical example: three versions of one landing page
For example, suppose a startup has its main demo page at /demo, a paid-search variant at /lp/demo-google with a shorter form, and an A/B test variant at /demo-b with a new headline.
/demo has a self-referencing canonical and is in the sitemap. /lp/demo-google has a noindex tag, because it exists only for ads and doesn't need to rank. /demo-b has a canonical pointing to /demo for the length of the test and is left out of the sitemap.
When the test ends and the new headline wins, the team updates /demo with the winning copy and 301 redirects /demo-b to /demo, instead of keeping two pages alive.
Canonical vs noindex vs 301 redirect: which should you use?
Use a canonical when duplicate URLs need to stay accessible, a 301 redirect when the old URL should stop existing for users too, and noindex when a page should be reachable but never appear in search. The choice depends on whether people still need the duplicate.
Tool | Users see the page? | Search engines index it? | Use when |
|---|---|---|---|
Canonical tag | Yes | Usually the canonical target instead | Duplicates must stay reachable |
301 redirect | No, they're sent to the new URL | The destination | Page moved, merged or replaced |
noindex | Yes | No | Utility or campaign pages that shouldn't rank |
robots.txt Disallow | Yes | May still be indexed from links | Saving crawling on low-value paths, not deindexing |
What canonical tag mistakes should you avoid?
The most common canonical mistakes are canonicals that point to redirects or 404s, canonicals built from the full URL including parameters, and sites where internal links disagree with the canonical. Each one sends mixed signals and often leads Google to pick its own canonical.
- Canonical points to a redirect, 404 or noindex page. After a redesign, update canonicals to final URLs from your redirect map.
- Every page canonicalizes to the home page, usually a template bug that tells Google most of the site is a duplicate.
- Relative or mismatched URLs, such as http in the canonical on an https site or a missing trailing slash.
- Multiple canonical tags on one page, often from a plugin and a theme both adding one.
- Canonical set by JavaScript, so the initial HTML disagrees with the rendered page.
- Cross-language canonicals on multilingual sites; each language should canonicalize to itself and use hreflang.
If Search Console shows duplicate or alternate statuses you don't expect, our guide to pages not indexed by Google explains each one, and an on-page SEO audit will catch canonical errors alongside titles and headings.
