What Is a Canonical Tag (and the Mistakes That Deindex Pages)

A canonical tag tells search engines which URL is the master copy of a page. Used correctly it consolidates your ranking signals; used wrong it silently removes pages from search. Here's how it works and the mistakes that deindex pages.

What a canonical tag does

When the same content is reachable at more than one URL, the canonical tag names the one true version, so search engines consolidate signals onto it instead of splitting them.

A canonical tag is a single line of HTML you place in the of a page. It names the URL that should be treated as the master, preferred version of that content. It looks like this:

In the of the page

Why is it needed at all? Because the same page is almost always reachable at several different URLs without you realising. Each of these can return the identical content, and to a search engine they look like separate, duplicate pages competing with each other:

All of these can serve the same pagehttps://example.com/blue-widgetshttps://example.com/blue-widgets/← trailing slashhttp://example.com/blue-widgets ← HTTP not HTTPShttps://www.example.com/blue-widgets ← www varianthttps://example.com/blue-widgets?ref=twitter← tracking parameter

Left unmanaged, Google has to guess which of these is the "real" one, and your ranking signals (links, content quality, click data) get split across the duplicates instead of pooling on one strong page. The canonical tag removes the guesswork: every variant declares the same master URL, and the signals consolidate onto it. For the vast majority of indexable pages, the correct master is the page itself, a self-referencing canonical.

The self-referencing canonical (your default)

Almost every indexable page should point its canonical at its own URL. This is the single most important canonical habit.

A self-referencing canonical explicitly confirms "this URL is the preferred version," which protects the page from a parameter or duplicate URL being chosen instead. So on the page at https://example.com/blue-widgets, the canonical in its head should be its own clean URL:

On https://example.com/blue-widgets

Always use the absolute URL (full https:// and domain), not a relative path, and match your site's exact trailing-slash and www convention. A relative or inconsistent canonical is one of the easiest ways to send a mixed signal.

The canonical mistakes that deindex pages

Each of these is a real check in the audit, because each one quietly removes pages from search.

Canonical points to a redirect

If a page's canonical points to a URL that 301-redirects somewhere else, you're sending search engines on a detour. Google often ignores a canonical that resolves through a redirect and picks its own, which may not be the URL you wanted. Point the canonical at the final destination directly.

Canonical points to a 4XX or 5XX

A canonical that points to a 404 or a server error is naming a dead page as the master. Google can't honour it, so it disregards the signal and guesses. The page's ranking signals scatter. The audit flags canonicals pointing to 4XX and 5XX targets specifically.

Every page canonicalising to page 1

A frequent and costly bug: paginated archive pages (page 2, 3, 4...) all set their canonical to page 1. This tells Google that pages 2+ are duplicates of page 1, so it deindexes them: along with the links and products only reachable from those pages. Paginated pages should self-reference their canonical.

Canonical to the wrong protocol or domain

A canonical pointing from HTTPS to HTTP (or vice versa), or off to a different domain, sends authority and indexing intent to the wrong place. The audit flags canonical HTTP-to-HTTPS, HTTPS-to-HTTP, and off-domain canonicals. After any HTTPS or domain migration, re-check that every canonical references the new, correct URL.

Wrong: deindexes pages 2+

Every paginated page canonicalising to page 1:

Right: each page self-references

Paginated pages point to themselves:

What this looks like in Google Search Console

When a canonical points away from a page, Search Console's URL Inspection tool shows a mismatch: User-declared canonical is the URL you set, but Google-selected canonical differs, or the page lands in the "Alternate page with proper canonical tag" or "Duplicate, Google chose different canonical than user" report under Pages. If a page you want indexed shows either of those, its ranking signals are being sent elsewhere. That is the symptom this whole section is about.

Canonical best practice

A short set of rules that prevents almost every canonical problem.

Self-reference by default. Every indexable page should canonicalise to itself unless it's genuinely a duplicate of another URL. Point at a live, canonical 200 URL. Never canonicalise to a redirect, an error page, or a non-canonical URL. Keep it absolute and consistent. Use the full URL with the correct protocol, domain and trailing-slash convention. Align canonical, hreflang and internal links. They should all reference the same URL for a page, if your hreflang points one way and your canonical another, you've sent a contradiction. Re-check after migrations, when canonicals most often break.

Canonicals in practice

A strong hint, not a hard directive

A canonical tag is a strong hint rather than a binding instruction. Google usually honours a clear, consistent canonical, but where your signals conflict, the canonical says one thing while internal links and the sitemap say another, it is free to choose a different URL entirely.

What makes a canonical reliable, then, is consistency rather than the tag on its own. Canonical, internal links, sitemap and hreflang should all name the same URL for a page. When they agree, Google has no reason to override you; when they disagree, the canonical is just one vote among several.

Does every page need a canonical?

A self-referencing canonical on every indexable page is best practice, and the simplest policy to apply consistently. It is not strictly mandatory, but it removes ambiguity and protects the page against a parameter variant or duplicate URL being selected in its place.

The audit flags non-canonical URLs that receive organic traffic, which is usually the visible symptom of a missing or wrong canonical: a variant URL is ranking where the master should be, which means the signals are pooling on the wrong page.

Choosing between a canonical and noindex

Use a canonical when two URLs are duplicates and you want to consolidate their signals onto one. Use noindex when you want a page kept out of search entirely.

They solve genuinely different problems: canonical merges, noindex excludes. Do not combine a noindex with a canonical pointing to another URL, because the two directives contradict each other, one saying "this page is a copy of that one" and the other saying "remove this page", and Google is left to resolve a conflict you created.

Choosing between a canonical and a 301 redirect

If users never need to see the duplicate URL, an old path or a non-www version being the obvious cases, use a 301 redirect. It is the stronger signal and it sends both users and crawlers to the right place in one step.

Reach for a canonical when the duplicate URL must stay accessible to users but should not compete in search: a print version, or a page reachable through filters or tracking parameters. The rule of thumb is short: redirect if the duplicate should not exist, canonical if it must exist but should not rank separately.

Handling tracking parameters like ?ref= and ?utm_

Give the page a self-referencing canonical pointing at the clean, parameter-free URL. Every ?utm_source=... or ?ref=... variant then declares that same canonical, so the analytics parameters never spawn duplicate pages in the index.

This is the standard fix for parameter-driven duplication, and it is worth putting in place before you start any campaign that appends tracking parameters at scale, since the duplicates otherwise accumulate quietly in the background.