Missing canonical tag

It is a hint, not an instruction. It says "of the addresses that serve this content, treat this one as the main one". Search engines usually follow it, and may ignore it when other signals — internal links, sitemaps, redirects — point elsewhere consistently.

It does not prevent a page from being crawled, does not remove a URL from the index by itself, and does not replace a redirect. A page that should not exist at an address should redirect, not canonicalise.

Tracking parameters. `?utm_source=…` creates a distinct URL for every campaign, all serving one page. Without a canonical, each is a candidate for indexing.

Faceted navigation and sorting. `?sort=price` and `?colour=blue` multiply addresses quickly, and the content behind them is often near-identical.

Several paths to one item — a product under two categories, an article under a date path and a slug path.

Protocol and host variants when redirects are incomplete: http and https, apex and www, with and without a trailing slash.

On one page: search the source for `rel="canonical"`, or run `document.querySelector('link[rel=canonical]')?.href`.

Then test the variants: append a dummy parameter, toggle the trailing slash, try the other host. If they all return 200 with the same content and no canonical, you have found the real problem.

A canonical that points at a URL which redirects, or at a page that answers 404, is worse than none: it is an explicit instruction to consolidate onto something that does not work.

Make every page declare a self-referencing absolute canonical by default. It costs nothing and it removes the parameter problem entirely.

Absolute, not relative — `https://example.com/page`, not `/page`. A relative canonical resolves against the current host, so each host declares itself canonical, which defeats the purpose on a site answering at several.

One per page. Two canonical tags are ambiguous and search engines may ignore both.

Where duplication should not exist at all, redirect instead. A 301 is a stronger and clearer statement than a canonical.

`seo.canonical` reads the canonical of every crawled page and reports the ones with none, as well as canonicals that are relative, duplicated, or point outside the site.

Alongside it, `domain.url_variants` and `transport.canonical_host` look at the other half of the question: whether the host and protocol variants actually redirect, which is what determines whether a missing canonical is theoretical or expensive.

This is the part worth internalising before adding canonical tags everywhere: an absent canonical leaves search engines to work it out, and they are reasonably good at it. A wrong one is an explicit instruction, and they tend to follow instructions.

Pointing at a 404. The page says "index that one instead", and that one does not exist. The current page can be dropped and nothing replaces it.

Pointing at a redirect. One extra hop, and an ambiguity about which of the three URLs involved is meant to win.

Pointing every page in a section at the section's index. This is the template error, and it asks search engines to discard every page in the section. It is rare because it is catastrophic, and it usually ships because each page looked correct when checked in isolation.

A relative canonical on a multi-host site, where each host declares itself canonical and the tag accomplishes precisely nothing.

A hardcoded staging domain shipped to production, which points the entire production site at an environment nobody outside the company can reach.

The practical consequence: a self-referencing canonical generated from the URL the server is actually answering on is both the safest default and the one that cannot be wrong. Anything else deserves a check that the target returns 200 before it goes out.