A canonical tag is one line in the head of a page declaring which URL should be treated as the authoritative address for that content. It is filed under duplicate content, usually with a warning about search penalties attached. The penalty framing is the part to drop, since Google has said for years that duplicate content is a consolidation problem rather than a punishment. What remains once you drop it is a more practical question: when the same content answers to four different addresses, which one accumulates the reputation, and which one does a retrieval system cite?
Adoption sits at 65% of pages on both desktop and mobile per the 2024 Web Almanac, the first year the tag was applied equally across both (Web Almanac). So roughly a third of the web still leaves the question open, and a further group answers it incorrectly, which is the more expensive case and the reason the audit checks the tag's content rather than its presence.
The mechanism is signal consolidation. Most sites are reachable at more variants than their owners think, due to the number of ways the same content can be addressed: with and without www, over HTTP and HTTPS, with and without a trailing slash, and with tracking parameters appended by every campaign that ever linked to them. Each variant can be fetched independently and can accumulate its own links and its own copy of your structured data. A canonical tag tells every fetching system to attribute all of it to one address. Without one, the consolidation still happens, but it happens by inference, and as a result different systems infer differently. Google picks a canonical on your behalf using its own signals. A retrieval agent may simply cite whichever variant it fetched first.
The failure that matters most for agents is subtler than a split link graph. When two variants of a page are retrieved as separate sources, an assistant can end up treating one document as corroboration for the other, which is not corroboration at all, and if the variants have drifted, with one carrying a stale price or an old date, the model has two conflicting facts from what it believes are two independent sources. Meaning a correct canonical collapses that back into one document with one set of facts.
The incorrect canonical deserves its own warning, because it fails in a direction that is harder to detect. A tag pointing at the wrong variant, or a relative URL, or a site-wide tag pointing every page at the homepage, does not produce an error anywhere. It quietly instructs every crawler to attribute your page to something else, and a page that self-canonicalizes to the homepage is asking not to be indexed as itself. MachineRead gives the canonical group 5 points in the checked total and verifies that the tag resolves absolutely, that it uses HTTPS, and that it points where a canonical should point, since a canonical served over an unencrypted connection is a contradiction on its face.
So the fix is mechanical, and worth doing properly. Pick one variant, make it HTTPS, and enforce it with 301 redirects rather than relying on the tag alone, because a redirect settles the question before anyone can fetch the alternative. Then set an absolute self-referencing canonical on every page, verify that paginated and parameterized URLs point somewhere sensible instead of defaulting to the homepage, and check what the tag actually renders to in production rather than what the template intends. It is one line, and it is one of the few lines that tells every other system how to interpret everything else on the page.
See also
- Methodology reference - documents the canonical check group and its 5 checked points
- Launch post - covers how canonical URLs fit the SEO pillar
- Related: schema.org JSON-LD and sitemap