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

What "Canonical Is a Relative URL" Means

This check fires when your <link rel="canonical"> points at a relative path like /product/ instead of a full absolute URL like https://example.com/product/. Google can usually resolve a relative canonical against the current page, but "usually" is the problem, because it leaves the single most important consolidation signal on your page open to misinterpretation.

The stakes: a relative canonical gets resolved against whatever base the crawler thinks it is on, and if that page is reachable on both HTTP and HTTPS, or with and without www, or through a proxy, the relative path can resolve to the wrong host. Now your duplicate signals split instead of consolidating, which is the exact opposite of what a canonical is for.

The Failing Example and the Fix

Here is the risky markup. The canonical is a bare path:

<link rel="canonical" href="/blog/spring-sale/">

And here is a subtler-but-still-wrong version, a protocol-relative URL that inherits whichever scheme the page loaded on:

<link rel="canonical" href="//example.com/blog/spring-sale/">

The fix is to write the fully qualified, absolute URL, scheme and host included:

<link rel="canonical" href="https://example.com/blog/spring-sale/">

Absolute means no ambiguity: there is exactly one URL the canonical can point to, no matter what host or protocol served the page. Match your live, indexable URL exactly, including trailing slash and casing.

Relative vs Absolute Canonicals

How to Detect It

1. View Source. Open the page, search the source for rel="canonical", and read the href. If it starts with a slash or with // instead of https://, it is relative.
2. curl. Pull the canonical straight from the response: curl -s https://example.com/page/ | grep -i canonical. You will see the exact href string the server sent, before any JavaScript touches it.
3. Screaming Frog. Crawl the site and open the Canonicals tab. Frog reports the canonical link element for every URL; sort or filter to spot any that are not absolute. One export covers the whole site.
4. GSC URL Inspection. Inspect the URL and read the "User-declared canonical" and "Google-selected canonical" fields. If they disagree, or if the declared value looks off, your relative canonical may be resolving somewhere you did not intend.

How to Fix It

1. Find where the canonical tag is generated. On WordPress with Yoast or Rank Math, it is output automatically and absolute by default, so a relative canonical usually means a theme or custom snippet is overriding it. Hunt that down.
2. Rewrite the template so it prints the full absolute URL, including https:// and the exact host, not a path fragment.
3. If you build canonicals from a variable, make sure that variable holds the complete URL and is not just the request path.
4. Standardize on one host and one scheme. Decide whether you are https://example.com or https://www.example.com and make every canonical use it, which also prevents the split-signal problem at the root.
5. Re-crawl and confirm every canonical now starts with your protocol and host. While you are in there, verify you are not accidentally shipping multiple canonical tags on the same page.

The Exact Scenario Where a Relative Canonical Backfires

Picture a page that resolves on all four of these: http://example.com/page/, https://example.com/page/, http://www.example.com/page/, and https://www.example.com/page/. That is a common state before redirects are locked down. Now the page ships a relative canonical of /page/. When Googlebot crawls the non-www HTTP variant, the relative canonical resolves to http://example.com/page/. Crawl the HTTPS www variant and the same tag resolves to https://www.example.com/page/. One relative tag, four different resolved canonicals depending on how the page was reached, which means your four duplicates each declare themselves the canonical. The consolidation you wanted never happens.

An absolute canonical of https://www.example.com/page/ resolves to that one URL no matter which variant a crawler hits, so all four duplicates point at the same target and the signal pools correctly. This is also why fixing relative canonicals goes hand in hand with enforcing a single host and scheme via redirects. If your variants are not yet redirecting to one canonical host, the absolute canonical is doing double duty as your safety net. For the broader duplicate picture, see managing duplicate content from URL variations.

Frequently Asked Questions

Google says it can resolve relative canonicals. Why does this even matter?

Because "can resolve" is not "always resolves correctly." The moment your page is reachable on more than one host or scheme, a relative canonical is a coin flip about which base it resolves against. Absolute URLs remove the coin flip entirely, and this signal is too important to gamble.

What is the difference between this and a missing canonical?

Here the canonical exists but is written ambiguously. With a missing canonical URL there is no canonical at all and Google picks one for you. Both are consolidation problems, but this one you have already half-solved, you just need to make the URL absolute.

Is a protocol-relative canonical (//example.com/...) acceptable?

No. It is better than a bare path but still inherits the page's scheme, so a page accidentally served over HTTP would canonicalize to an HTTP URL. Always write the explicit https://.

Does the trailing slash in the canonical matter?

Yes. The canonical should exactly match the version of the URL you want indexed, trailing slash and all. A mismatch between the canonical and the live URL is a small inconsistency that adds noise to the signal.

My plugin outputs absolute canonicals but Frog still shows relative ones. Why?

Something is overriding the plugin, usually a hardcoded tag in the theme header or a second SEO plugin. Two canonical sources on one page is its own failure, covered under the canonical tags reference. Remove the duplicate source and let one system own the tag.