Canonical Pointing to a Redirect, 404, or Noindexed Page

Why a canonical must point to a clean, indexable 200 URL

A rel=canonical tag is an instruction to consolidate ranking and indexing signals onto a specific target URL. For that instruction to be usable, the target has to actually be something Google can index: a URL that returns a normal 200 OK status, is not blocked from crawling, does not carry a noindex directive, and is not itself canonicalized somewhere else. This is sometimes called the target needing to be a clean, indexable URL, and tools like Screaming Frog label the opposite condition a "Non-Indexable Canonical."

The logic is straightforward once stated: you are telling Google, in effect, "don't index this page, index that one instead." If "that one" cannot itself be indexed, cleanly and directly, you have given Google an instruction it cannot follow. The signal doesn't get honored in any useful way, the link equity and consolidation you were hoping for doesn't materialize, and depending on the target, Google may end up doing something you did not intend, such as indexing the original page after all or discarding your canonical hint entirely.

The bad targets: redirects, 404s, noindex, and robots-blocked pages

There are four common categories of bad canonical target, each with a slightly different failure mode. A canonical pointing to a URL that itself redirects, whether a single 301 or a longer chain, creates a muddled signal: Google may follow the chain, may not, and in general the research indicates Google may ignore your canonical and pick its own selection when the target isn't the final, direct destination. The fix is to always point the canonical straight at the final 200 URL, with no intermediate redirect hops.

A canonical pointing to a URL that returns a 404 or a 5xx server error is simply pointing at an invalid target. Google disregards a canonical like this and falls back to choosing its own canonical for the page, since there is nothing at the destination to consolidate onto.

A canonical pointing to a page that itself carries a noindex tag is contradictory in the same way a noindex and canonical on the same page are contradictory: you're asking Google to index a page as the authoritative version while that page separately tells Google not to index it. This combination is unreliable and should be avoided.

A canonical pointing to a URL blocked by robots.txt fails for a more basic reason: Google cannot crawl the target to confirm it is actually equivalent content, so it can't verify or act on the canonical relationship. Google explicitly advises: don't use the robots.txt file for canonicalization purposes.

What Google does with an invalid canonical target

Across each of these bad-target scenarios, the general pattern in Google's behavior is the same: when the canonical target isn't a clean, directly-indexable 200 URL, Google disregards the canonical hint and picks its own canonical for the page using whatever other signals it has, such as internal linking, sitemaps, and content similarity, rather than trying to work around the broken pointer.

This matters because it means a broken canonical target doesn't just fail quietly, it actively hands the decision back to Google in a situation where you had presumably set the canonical for a reason. If the goal was to consolidate duplicate content, that consolidation doesn't happen as intended. If the goal was to steer which URL variant shows up in search results, that steering is lost, and Google's own algorithmic choice takes over instead.

Common ways this happens

Non-indexable canonical targets are usually leftovers from some other change to the site rather than a mistake made all at once. A very common source is a site migration: canonical tags that were correct before the migration still point to the old, pre-migration URL structure, and since those old URLs now redirect to their new equivalents, every one of those canonicals is now pointing at a redirect instead of a final 200 URL.

A second common source is a protocol change: after moving a site from HTTP to HTTPS, canonical tags that were never updated still point to the old http:// version of the URL, which typically now redirects to https://, again turning the canonical into a canonical-to-redirect situation. Google prefers HTTPS as the canonical version in general, so an unupdated HTTP canonical works against that preference as well as pointing at a redirect.

A third source is parameter handling: some canonical setups are configured to strip query parameters and canonicalize to the bare URL, but if that bare, parameter-stripped URL does not actually exist as a valid page on its own, for example because the parameter was required to load real content, the canonical ends up pointing at a URL that 404s.

How to find and fix non-indexable canonicals

Finding these issues at scale is best done with a site crawler that specifically checks the indexability of canonical targets rather than just their presence. Tools built for this purpose, such as Screaming Frog, produce a dedicated "non-indexable canonical" report that flags every page whose canonical points to a redirect, a 4xx or 5xx error, a noindex page, or a robots-blocked URL, which is far faster than manually checking canonical targets one by one.

Here is the kind of pattern that report would catch: a page whose canonical looks fine at a glance but actually points to a URL that no longer resolves directly.

<link rel="canonical" href="https://example.com/old-path/product-name" />
<!-- https://example.com/old-path/product-name redirects (301) to
     https://example.com/products/product-name -->

Once flagged, the fix is the same in every case: repoint the canonical directly at the current, final, 200-status URL, the one that would be reached at the end of any redirect chain, rather than at the intermediate or outdated URL. For canonicals pointing to noindex or robots-blocked pages, the fix usually requires deciding what you actually want, either removing the noindex or robots block from the target if it should genuinely be indexable, or removing the cross-page canonical if the source page should not be consolidated at all. After correcting the targets, re-crawl to confirm every canonical now resolves directly to a clean 200 URL.

Frequently Asked Questions