Canonical Points to a Redirecting URL: How to Fix It

What this means

Every indexable page can carry a rel="canonical" tag that names the URL you want treated as the master version. The expectation is that this target is a real, final destination that responds with a 200 OK status.

This issue fires when the canonical target does not resolve directly. Instead, requesting it triggers a 301 (permanent) or 302 (temporary) redirect to a different address. In other words, you are pointing search engines at a signpost rather than at the actual page. If Page A canonicalizes to Page B, and Page B redirects to Page C, the canonical is pointing one step short of where the content really lives.

Why it matters

A canonical tag and a redirect are two different signals, and when they disagree, search engines have to break the tie themselves.

• It sends a confusing signal. The canonical says "index this URL," while the redirect on that same URL says "this URL has moved." Faced with contradictory instructions, Google often discards the declared canonical and picks its own, which may not be the page you wanted.
• It weakens canonicalization. The whole point of the tag is to consolidate duplicate or near-duplicate pages onto one authoritative URL. When the target redirects, that consolidation becomes unreliable, and ranking signals can scatter across versions instead of pooling on one.
• It wastes crawl budget. Every time a crawler follows the canonical, it has to make an extra request to resolve the redirect before reaching real content. Across many pages this adds avoidable hops, slows discovery of genuinely new URLs, and can grow into a redirect chain.

How it gets flagged

A crawler reads the rel="canonical" value on a page, then requests that exact URL. If the response is a 3xx redirect rather than a 200, the page is reported. In Screaming Frog this surfaces under the Canonicals tab and in the redirect reporting; in Sitebulb it appears as the "Canonical points to a redirecting URL" hint under Indexability. The fix is the same in every tool: make the canonical target resolve directly.

How to fix it

Point the canonical at the final 200 URL, the page the redirect actually lands on, so there is no hop between the tag and the content.

1. Request the current canonical target and note where it redirects to. Follow the chain all the way to the URL that returns 200.
2. Confirm that final URL is genuinely the page you want indexed (correct protocol, host, trailing-slash form, and parameters).
3. Update the rel="canonical" to that final address, then re-crawl to confirm the canonical now resolves with a 200.

<!-- Before: canonical target 301-redirects elsewhere -->
<link rel="canonical" href="https://example.com/old-page/" />

<!-- After: canonical points straight at the final 200 URL -->
<link rel="canonical" href="https://example.com/new-page/" />

Keep the redirect in place for users and links that still hit the old URL. You are not removing the redirect, you are making sure your own canonical no longer relies on it. For deeper background, see our complete reference for canonical tags, our guide to redirect chains and loops, and the difference between 301 and 302 redirects.

False positives

A few cases look like this issue but may be acceptable:

• Mid-migration snapshots. During a site move or HTTPS rollout, a crawl can catch canonicals that point to URLs you are still redirecting. Re-crawl after the migration settles before treating it as a defect.
• Protocol or www normalization. If a redirect only upgrades http to https or adds www, canonicalizing to the final form is still safest, but the impact is minor next to a redirect that changes the path.
• Cached or stale crawl data. If you already corrected the canonical, an older report may still list it. Confirm against a fresh crawl before acting.

FAQ