Canonical isn't an absolute URL: how to fix it

What it means

A canonical tag points to a relative URL instead of an absolute one. The page declares itself as the preferred version, but the URL lacks the protocol and host prefix.

Why it matters

Google follows the canonical to resolve the preferred URL, and a relative link can resolve to the wrong host or protocol depending on context. This creates ambiguity around which page is canonical, wastes crawl budget on duplicate resolutions, and can confuse AI agents that rely on canonical links to consolidate signals.

How to fix it

1. Change the canonical to an absolute URL with the full protocol and host (e.g., https://www.example.com/page/).
2. If using a relative canonical, ensure the page's base href is set correctly in the HTML head.
3. Verify the resolved URL returns a 200 and matches the page's content exactly.

Example

<link rel="canonical" href="/products/shoe-a">

<link rel="canonical" href="https://example.com/products/shoe-a">

Canonicals should be absolute. A relative path can be misresolved against the wrong base (e.g. a staging host), pointing Google at the wrong URL.

When it's not a problem

A relative canonical is acceptable when the page and canonical refer to the same host and protocol — Google resolves it correctly in most cases. It becomes a problem mainly when the site serves multiple domains, uses protocol-relative URLs inconsistently, or when external tools parse the tag without resolving the base.

How Crawlinx detects it

We check whether the canonical href starts with http. If it doesn't, it's a relative or protocol-relative canonical and we report the value we found.

How common is it?

3 audited sites in our corpus currently show this issue. The breakdowns below show which platforms, gatekeepers, verticals and countries are most exposed.