Canonical Is a Relative URL: Why It Is Risky and How to Fix It

What this means

A canonical tag tells search engines which version of a page is the preferred one to index. This issue fires when the href value is a relative URL rather than an absolute one. A relative URL leaves out the scheme and host and includes only the path, for example href="/category/page". The crawler is expected to resolve that path against the current page, inheriting the same protocol, domain, and subdomain.

Google confirms the tag accepts both relative and absolute URLs, but advises using absolute paths, because resolution is not always as predictable as it looks and a small mistake can quietly point the canonical at the wrong page.

Why it matters

A relative canonical can resolve to an unintended URL in several common situations:

• A <base> tag is present. If the page declares a <base href>, the browser resolves the relative canonical against that base rather than the page URL. This can silently send the canonical to a different directory or even a different domain.
• The page is reachable on a non-canonical host. If the same HTML is served on http and https, on www and non-www, or on a staging subdomain, a relative canonical inherits whichever host served the request. Google warns that allowing a test site to be crawled can lead to the wrong canonical being recorded.
• Subtle path mistakes. A leading slash, a missing slash, or a stray trailing segment changes where a relative path resolves. These errors are easy to miss and can ignore your intended canonical entirely.

When the canonical resolves to the wrong address, Google may ignore your signal and pick its own canonical. That leads to mis-canonicalization, wasted crawl on duplicate hosts, and the wrong URL surfacing in search. Absolute URLs remove the ambiguity by stating the exact preferred page once, regardless of where the page is served.

How it gets flagged

Crawlers parse the href value of each rel="canonical" tag and check whether it begins with a protocol and host. If it does not, the URL is classified as relative and flagged. In Screaming Frog you review these under the Canonicals tab using the Canonical Is Relative filter; Sitebulb and Ahrefs report the same condition. SEO ProCheck flags it during the on-page crawl whenever a canonical lacks an absolute address.

How to fix it

Replace each relative canonical with the full absolute URL, including https:// and your canonical domain. Make the change in the template or component that outputs the canonical so every page is covered at once.

Before:

<link rel="canonical" href="/category/blue-widget" />

After:

<link rel="canonical" href="https://www.example.com/category/blue-widget" />

Checklist while you fix:

• Use the exact protocol, host, and casing of your preferred canonical domain.
• Match your host normalization. If you redirect to https://www., every canonical should use that form so the canonical and the live URL agree.
• Have each page self-reference its own absolute canonical unless it is a true duplicate that should point elsewhere.
• Remove or review any <base> tag that was masking the problem.
• Re-crawl after deploying to confirm the filter is clear.

For deeper guidance on tag syntax, placement, and edge cases, see our complete canonical tags reference. If duplicate URLs are part of the wider picture, our duplicate content guide explains how canonicals and redirects work together, and our 301 vs 302 redirects guide covers host normalization.

False positives

This is a best-practice warning, not a hard error. If your relative canonicals always resolve correctly, no <base> tag is present, and the page is only served on your single canonical host, the canonical may already be working. Protocol-relative values such as href="//www.example.com/page" are also reported as relative; they resolve in practice but still inherit the request scheme, so an absolute https:// URL remains safer. Treat the flag as a low-risk cleanup item unless Search Console shows mis-canonicalization.

FAQ