Canonical Points to a Redirecting URL: How to Fix It

This check fires when a page's rel="canonical" points at a URL that 301s or 302s somewhere else instead of returning a direct 200. The content still resolves at the end of the hop, but a canonical is supposed to name the final destination — pointing at a way-station forces Google to do extra work and weakens the signal.

What this check flags and why it matters

Google will usually follow one redirect and treat the endpoint as the intended canonical, so this is milder than a 404 or 5xx target. But it is still an error: the canonical should point where you actually want equity to land. Chain it through a redirect and you invite ambiguity, slower consolidation, and — if that redirect itself points back into the cluster — an outright loop.

The reason this is worth fixing even when it "works" comes down to how canonicalization scales. Google canonicalizes billions of URLs and every extra hop it has to resolve is compute it would rather not spend. When your signal is cheap and unambiguous — a canonical that lands on a 200 in one request — it gets trusted and applied quickly. When the signal is expensive to resolve, Google leans harder on its own heuristics and your declared preference carries less weight. A redirecting canonical is a self-inflicted tax on the exact instruction you most want honored.

A real failing example

Page /services/seo-audit/ declares this canonical:

<link rel="canonical" href="https://example.com/services/audit/" />

But /services/audit/ was consolidated into /services/seo-audit/ ages ago and now 301s. Follow the chain with curl:

$ curl -sIL -A 'Mozilla/5.0' https://example.com/services/audit/

HTTP/2 301
location: https://example.com/services/seo-audit/

HTTP/2 200
content-type: text/html; charset=utf-8

See the trap: the page canonicalizes to a URL that redirects straight back to the page itself. Google has to resolve the hop to figure out what you meant, and in a messier setup that same pattern becomes a canonical-plus-redirect loop.

The fix is to skip the hop and name the final 200 URL directly — here, a clean self-reference:

<link rel="canonical" href="https://example.com/services/seo-audit/" />

Redirect type changes the risk

How to detect it

1. Screaming Frog: open the Canonicals tab and filter Canonical Links to Non-Indexable URL (redirects count as non-indexable), or use the Redirects report and match any 3xx URL that also appears as a canonical target. Turn on "Always Follow Canonicals" plus "Follow Internal Redirects" so the chain is fully mapped.
2. GSC URL Inspection: when your declared canonical redirects, Google often reports "Google-selected canonical" as the endpoint while your "User-declared canonical" is the redirecting URL — that split is the tell.
3. curl -IL: the definitive check — curl -sIL -A 'Mozilla/5.0' <canonical-target>. Count the hops. Anything more than a bare 200 on the first response means your canonical is pointing at a redirect.

How to fix it

1. Run curl -IL on the canonical target and note the final 200 URL at the end of the chain.
2. Rewrite the <link rel="canonical"> to that final URL — never an intermediate hop.
3. Confirm the new target returns 200 on the first response with no Location header.
4. Check for the loop case: make sure the final URL does not itself redirect back to the page carrying the canonical.
5. Where a whole set of pages canonicalize through the same redirect, fix them in bulk — a single stale legacy URL is often the shared culprit.
6. Validate in GSC and re-inspect; the declared and Google-selected canonical should now match.

FAQ

Google says it followed the redirect and indexed the right page — do I still need to fix this?

Yes. You are relying on Google to guess correctly every crawl. Name the endpoint directly and you remove the guesswork, speed up consolidation, and preclude future chain/loop problems.

Does a 302 in the canonical target behave differently than a 301?

A 302 signals "temporary," which conflicts with the permanent "this is the master" intent of a canonical. Google may hesitate on which URL to treat as canonical. Use a 301 for permanent moves — better yet, no redirect in the canonical at all.

What if the redirect target redirects again?

Multi-hop chains decay the signal and Google may stop following partway. Collapse the chain so the canonical points at the true final 200 in one step. See Internal Chain Loop.

My canonical points to a page that redirects to itself — is that the same as a canonical loop?

It is a close cousin. When the canonical and the redirect point at each other, Google can never settle a stable canonical. Read Canonical Loop and Internal URL Redirects Back to Itself.

Related canonical checks

Redirecting targets sit next to the harder failures: a target that never resolves in Canonical Points to a 404, one that errors in Canonical Points to a 5xx Error URL, and one Google cannot even fetch in Canonical Points to a Disallowed URL. Ground yourself in the Canonical Tags Complete Reference if any of these keep recurring.