Canonical target redirects: point it at the final URL
A canonical that targets a redirecting URL forces Google through an extra hop and weakens the signal. Find canonicals aimed at redirects and fix them free.
What it means
The page's rel="canonical" tag points to a URL that does not return 200 directly — it redirects (301, 302, 308) to somewhere else. You are telling Google "index this other URL", but that other URL then says "actually, go here instead". The canonical target should be the final destination, not a stop along the way.
Why it matters
A canonical is a hint, not a directive: Google weighs every competing signal — internal links, sitemaps, the redirect graph — before choosing a canonical. When your declared canonical redirects, you hand Google a contradiction (the tag names URL A, but A immediately forwards to URL B), which dilutes the signal and makes Google more likely to disregard your hint and pick its own canonical. Every hop also adds latency and a chance for the signal to decay, and spends crawl budget on resolution work a clean canonical would have avoided. A canonical should resolve in a single step to a live, indexable page.
How to fix it
- Fetch the canonical target URL directly (curl, or the browser network tab) and read its status code.
- If it returns 301, 302, or 308, note the Location header — that final destination is your real canonical.
- Update the rel=canonical on the source page to point at the final 200 URL, skipping the redirect entirely.
- Confirm the new target returns 200 and is indexable (no noindex, not blocked in robots.txt).
- Audit templated canonicals: a template that builds the canonical from the request URL rather than the resolved URL will propagate any redirecting path into the tag.
When it's not a problem
Crawlinx only flags this when the canonical target was actually crawled and observed to redirect. If the redirect is a deliberate, permanent 301 that Google already treats as a canonical signal, the practical harm is small — Google follows 301s and consolidates them. It is a warning, not an error: the page still works and will usually be indexed. Fix it to tighten the signal, not to prevent an outage.
How common is it?
2 audited sites in our corpus currently show this issue. The breakdowns below show which platforms, gatekeepers, verticals and countries are most exposed.
Related guides
Audit your own site — free
77 checks, internal PageRank, render-diff. No signup, results in ~30s.