A canonical tag is an instruction, not a suggestion: it tells a search engine to consolidate this page's ranking signals onto another URL. That instruction assumes the target is actually eligible to hold them. When it is not, because the target itself carries a noindex directive or no longer resolves, the instruction has nowhere to go, and the page that sent it can disappear along with it.
What this finding means
Crawl Cove's canonical-to-noindex check looks at every indexable page (HTTP 200, not itself noindex) whose rel="canonical" is a same-origin, absolute URL pointing at another page in the crawl. It flags the source page when that canonical target turns out to be non-indexable: either marked noindex or answering with a non-200 status.
A real finding looks like this:
canonical points to "https://example.com/old-category", which is marked noindex (a non-indexable page)
or, when the target no longer exists:
canonical points to "https://example.com/discontinued-product", which returned HTTP 404 (a non-indexable page)
This is separate from the plain canonical check, which only confirms a canonical tag is present and well-formed; it never inspects whether the target itself is fit to be canonicalized to, which is exactly the gap this check closes.
Why it matters
Telling a search engine to consolidate a page's signals onto a target it will not index is not a neutral instruction, it is one that can drag the source down with it. Google generally treats the two pages as one group led by the canonical target; if that target is excluded from search, the group has no page left eligible to rank, and the source can silently drop out of the index even though nothing about the source page itself is wrong.
How to fix it
- Open the source page's canonical tag and find the target URL named in the finding.
- Check why the target is non-indexable. If it is
noindex, confirm whether that was intentional (see Noindex for how to read that finding); if it is a 404, the page it should have pointed at may have moved or been deleted. - Point the canonical at an indexable URL. In most cases that means the page itself, a self-referential canonical, unless there really is a different, live, indexable page these signals should consolidate onto.
- Re-crawl afterwards to confirm the finding clears and the source page is eligible to rank again.
False positives and edge cases
- A self-referential canonical never fires this check. A page pointing at itself is the normal, correct pattern, and is explicitly excluded rather than merely happening not to match.
- Only same-origin, absolute, already-crawled canonical targets are checked here. A canonical that is missing, relative, points off-site, or points at a URL the crawl never reached is out of scope for this specific check, by design, so it never gets a false answer about a target it could not actually inspect.
- A canonical pointing at a redirect is not flagged here. That is a different, more specific case with its own fix, and mixing the two would tell you less than reporting them apart.
Related reading
For the check that covers a page excluded by noindex in the first place, whether or not anything canonicalizes to it, see Noindex.
Frequently asked questions
- Isn't a canonical tag just for duplicate content?
- That is its most common use, but the instruction it sends is broader: "fold this page's ranking signals into the target." If the target is not eligible for search at all, that instruction has nowhere useful to go, whatever the reason the two pages are related.
- What if the canonical points at a page that was deleted?
- That is covered by the same finding. The check reports a canonical target as non-indexable whether the reason is a noindex directive or a non-200 status, and the evidence names which one applies.
- Does this check flag a page that canonicalizes to itself?
- No. A page pointing its canonical at itself is the normal, correct case and is never flagged.
- What is the difference between this and a canonical pointing at a redirect?
- They are reported separately on purpose. A canonical pointing at a redirect is a different, more specific problem covered by its own check, because the fix (point at the final destination) is different from the fix here (point at an indexable page at all).