rel=canonical: presence, absolute form and self-reference

What rel=canonical does

<link rel="canonical"> names the URL a page wants search engines to treat as its address. When the same content is reachable at several URLs, through parameters, a trailing slash, or both www and the apex domain, the canonical is what consolidates the signals onto one of them.

It is a hint rather than an instruction, and search engines can pick a different URL when the evidence disagrees with the declaration. The common case is a self-referential canonical: every page names itself, which costs nothing and makes the parameterised copies point somewhere real. A relative reference is valid HTML, and Google recommends an absolute URL because a relative one is easy to resolve against the wrong base.

What squirrel checks

The rule runs on every crawled page against the parsed canonical value. It emits one check named canonical:

• Warning with the message Missing canonical URL and a null value when there is no canonical.
• Failing with the message Canonical URL should be absolute and the expectation Absolute URL starting with https:// when the value does not begin with http.
• Failing with the message Invalid canonical URL format when the value begins with http but does not parse as a URL.
• At info status with the message Canonical points to different URL when it parses and does not match the page’s own URL exactly.
• Passing with the message Self-referential canonical present when it matches.

For a URL that answers with an HTTP redirect, the page’s own URL is the one the redirect ended on, since that is the page whose canonical is read: /en/old-slug redirecting to /en/new-slug is self-referential when /en/new-slug names itself. The crawled URL is used when no HTTP redirect was observed, when any hop was a client-side one (JavaScript or meta refresh), or when the final URL does not parse.

The comparison is between the two full URLs after parsing, so a difference in trailing slash, in scheme, or in query string is enough to make it a different URL. That result is informational rather than a warning, because pointing elsewhere is often correct.

How to fix it

<link rel="canonical" href="https://example.com/guides/build-cache" />

Emit it from the router’s own knowledge of the route, so it is absolute, uses one scheme and one host, and matches whatever form the rest of the site uses.

The common false positive is a filtered or sorted view that canonicalises to the unfiltered page, which is correct and reports as pointing to a different URL. That result is informational, not a defect. A paginated listing whose pages canonicalise to themselves passes normally.

Enable / disable

Disable this rule

[rules]
disable = ["core/canonical"]

Disable all Core SEO rules

[rules]
disable = ["core/*"]

Enable only this rule

[rules]
enable = ["core/canonical"]

enable replaces the default ["*"], so this is the only rule selected. Leave disable out: a rule that matches any disable pattern is skipped even when enable names it. Only an enabled setting under a rule’s own [rule_options] table overrides both lists.

Related rules

• core/canonical-header: the same declaration in an HTTP header, and whether the two agree.
• core/canonical-form-drift: canonicals that are each valid but disagree in form across the site.
• crawl/canonical-chain: a canonical pointing at a URL that redirects instead of answering.
• crawl/schema-noindex-conflict: rich-result markup on a page that is blocked from indexing.

Core SEO findings ship in every audit next to the performance, security and agent experience rules. See Fix SEO issues with AI for how an agent works through a report.

References

• How to specify a canonical URL, Google Search Central
• rel=canonical, MDN

Check your site

Run squirrel audit https://example.com and open the Core SEO section of the report. Each page reports the canonical it declared. Signed-out local audits need no account and cost nothing. Signed-in audits spend credits.