Canonical Points to a Noindex URL: Fixing the Contradiction

This check fires when a page's rel="canonical" points at a URL that carries a noindex directive. It is a flat contradiction: the canonical says "consolidate signals onto this master," while the master says "keep me out of the index." Google has to break the tie — and the way it breaks it can quietly deindex the very content you wanted to rank.

What this check flags and why it is dangerous

Canonical and noindex are conflicting instructions aimed at the same URL. Google's guidance is not to combine them, because the crawler cannot tell whether you mean "index the master" or "drop this page." Depending on how signals shake out, the noindex can bleed across to the pages that canonicalize to it — so instead of consolidating rank, you risk pulling the whole cluster out of the index.

This is the only failure in the cluster where both URLs are technically healthy — the target returns a clean 200, the crawl succeeds, nothing is broken in the HTTP sense. The problem is purely semantic: you have handed Google two instructions that cannot both be true. That is what makes it so easy to ship and so hard to spot. There is no error status to alert on, no broken link in a crawl report's obvious columns; the contradiction only surfaces when a tool specifically cross-references canonical targets against indexability directives. Meanwhile the practical outcome tends to favor removal — a noindex is a strong, explicit exclusion signal, and Google is reluctant to index a page you have explicitly told it to exclude, even if another page is pointing traffic its way.

A real failing example

Paginated view /blog/page/2/ canonicalizes to the blog root, trying to funnel equity to page one:

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

But someone slapped a noindex on the blog root during a redesign and never removed it. Curl the headers and the contradiction is right there:

$ curl -sI -A 'Mozilla/5.0' https://example.com/blog/

HTTP/2 200
content-type: text/html; charset=utf-8
x-robots-tag: noindex

Or, just as often, it hides in the HTML instead of the header:

<meta name="robots" content="noindex,follow" />

The target loads fine (200), so Google fetches it, reads "noindex," and now faces two opposite orders. Treat the canonical as authoritative and the master's noindex may propagate to the pagination; honor the noindex and the master itself vanishes. Either way you lose.

The fix is to remove the contradiction — if the master should be indexed, strip the noindex:

$ curl -sI -A 'Mozilla/5.0' https://example.com/blog/

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

How Google resolves the conflict

The rule of thumb: a canonical target must be indexable. If you would noindex it, it has no business being anyone's canonical.

How to detect it

1. Screaming Frog: crawl, then open the Canonicals tab and filter Canonical Links to Non-Indexable URL — noindexed targets appear here. Cross-check the Directives tab (filter Noindex) and match any noindexed URL that is also a canonical target elsewhere. Configure it to read both meta-robots and X-Robots-Tag headers.
2. GSC URL Inspection: inspect the page — if the declared canonical is noindexed, Google may report "Excluded by noindex tag" for the target and "Duplicate, Google chose different canonical" for the current page. That pairing is diagnostic.
3. curl -I plus source check: noindex lives in two places. Run curl -sI <target> | grep -i x-robots-tag for the header form, and grep the fetched HTML for meta name="robots" for the tag form. Check both — missing one is how these hide.

How to fix it

1. Confirm the canonical target is noindexed — check both the X-Robots-Tag header and the HTML <meta name="robots">.
2. Decide which directive is the mistake. If the target should rank, remove the noindex and let the canonical do its job.
3. If the target genuinely should not be indexed, repoint the canonicals that aim at it — they should self-canonicalize or point to a different indexable master.
4. Never leave a URL that is simultaneously a canonical target and noindexed; pick one intent.
5. Re-crawl to confirm no other pages canonicalize to the same noindexed URL — these tend to cluster.
6. Validate in GSC and re-inspect until the declared and Google-selected canonicals agree.

FAQ

Google says "noindex wins" in a conflict — so will my master always get dropped?

When canonical and noindex clash on one URL, Google leans toward respecting the noindex, and that intent can carry to pages pointing at it. Do not rely on a predictable outcome — remove the contradiction.

Can I use noindex,follow on a canonical target to get the best of both?

No. follow only affects link crawling; the noindex still contradicts the canonical. A canonical target must be indexable, full stop.

What about canonicalizing a noindexed page to itself?

That is fine and common for utility pages — a self-referencing canonical on a noindexed page is not this error. The problem is only when other pages point their canonical at a noindexed URL.

The noindex is in an X-Robots-Tag header, not the HTML. Does that change anything?

Google honors both identically. Header-based noindex is easier to miss because it never shows in the page source — always check with curl -I. See the noindex glossary entry for how the two forms behave.

Related canonical checks

This is the directive-conflict case; the rest of the cluster are fetch/status failures: Canonical Points to a 404, Canonical Points to a 5xx Error URL, Canonical Points to a Redirecting URL, and Canonical Points to a Disallowed URL. If you are wrestling with pages that carry both directives, see Noindex and Nofollow Together.