Canonical Points to a 404: Why It Breaks and How to Fix It
- April 25, 2021
- Indexation, Canonical Issues
This check fires when a page's rel="canonical" points at a URL that returns 404 Not Found. You are telling Google "the master version of this content lives over there," while "over there" is a dead end — so Google throws the hint away, decides for itself which URL to index, and often lands on the wrong one.
What this check flags and why it stings
A canonical is a suggestion, not a command. When that suggestion resolves to a 404, Google has nothing to consolidate signals onto, so it silently ignores the annotation and picks a canonical from the cluster on its own. The page you actually care about can end up demoted, deduplicated against a random parameter variant, or dropped from the index while a URL you never wanted to rank takes its place.
What makes the 404 case the cleanest to reason about is that Google's response is decisive: a 404 is a permanent, unambiguous "there is nothing here," so there is no waiting and no retry loop — the hint is thrown out on the spot. That decisiveness cuts both ways. You are not stuck in the limbo a 5xx creates, but you also get no grace period; the moment Googlebot fetches that dead target, your intended canonicalization is gone and the cluster is up for grabs. On a big template where one broken variable feeds the canonical of thousands of pages, that is thousands of URLs surrendering their canonical choice in a single crawl.
A real failing example
Here is the canonical you shipped in the <head> of /blog/color-theory/:
<link rel="canonical" href="https://example.com/blog/colour-theory/" />Note the British spelling. That URL was renamed months ago. Curl the target and the chain ends in a wall:
$ curl -sIL -A 'Mozilla/5.0' https://example.com/blog/colour-theory/
HTTP/2 404
content-type: text/html; charset=utf-8
x-robots-tag: noindexNo redirect, no rescue — just a hard 404. Google fetches the canonical target, sees it does not exist, and discards the hint. The self-referencing canonical the page should have carried never gets a chance to do its job.
The fix is to repoint the tag at a live 200 URL — almost always the page itself:
<link rel="canonical" href="https://example.com/blog/color-theory/" />$ curl -sI -A 'Mozilla/5.0' https://example.com/blog/color-theory/
HTTP/2 200
content-type: text/html; charset=utf-8What Google actually does with a 404 canonical
| Stage | What happens | Impact on your page |
|---|---|---|
| Canonical parsed | Google reads href and queues the target for verification | None yet |
| Target fetched | Server returns 404 — the URL has no content | Hint marked invalid |
| Signal ignored | Google drops your canonical and runs its own canonicalization | You lose control of the choice |
| Google picks | A different URL in the cluster becomes the Google-selected canonical | Wrong URL may rank; equity splits |
| Reported | Search Console flags "Alternate page with proper canonical tag" or "Duplicate, Google chose different canonical" | Confusing coverage numbers |
How to detect it
- Screaming Frog: crawl the site, open the Canonicals tab and filter to Canonical Links to Non-Indexable URL, then cross-reference against the Response Codes > Client Error (4xx) tab. Any canonical target appearing in both is a 404 canonical. Enable "Always Follow Canonicals" so the crawler chases the target's status.
- GSC URL Inspection: inspect the affected page. Under Page indexing, check "User-declared canonical" versus "Google-selected canonical." A mismatch where your declared URL is a 404 is the smoking gun.
- curl -IL: pull the canonical
hrefstraight from the source and hit it:curl -sIL -A 'Mozilla/5.0' <canonical-target>. A terminal404with no redirect confirms it.
How to fix it
- Extract the current canonical target from the page source.
- Confirm it 404s with
curl -I— rule out a transient blip by retrying once. - Decide the correct live destination: the page itself (self-referencing) in the vast majority of cases, or the true master if this really is a duplicate.
- Update the
<link rel="canonical">to that 200 URL and confirm withcurl -Ithat it returns200. - If the old target was renamed rather than deleted, add a 301 from the dead URL to the new one so any stray inbound links and old canonicals resolve gracefully.
- Request validation in the GSC Page Indexing report and re-inspect the URL to confirm Google now honors your canonical.
FAQ
Will Google index my page at all if its canonical 404s?
Usually yes — it just ignores your broken hint and canonicalizes on its own. The risk is not deindexation so much as losing the vote: Google may consolidate onto a URL you did not choose.
Is a self-referencing canonical always the safe fix?
For a standalone, indexable page, yes. Point the canonical at its own live URL. Only point elsewhere when the page is a genuine duplicate of another live 200 page.
The target used to exist — can I just 301 it instead of editing every canonical?
A 301 turns a 404 canonical into a redirecting canonical, which is a separate (milder) problem — see Canonical Points to a Redirecting URL. Cleanest is to fix the canonical to the final 200 URL and keep the 301 for stray links.
How fast will Search Console clear the error?
After you fix the tag and hit Validate, expect recrawl over days to a couple of weeks depending on the page's crawl frequency. Higher-authority pages clear faster.
Related canonical checks
A dead canonical target rarely travels alone. Work through the rest of the cluster: Canonical Points to a 5xx Error URL, Canonical Points to a Disallowed URL, and the closely related Canonical Loop. For the fundamentals, keep the Canonical Tags Complete Reference open, and if you are handling removed pages, read 404 vs 410 before deciding how to retire the dead target for good.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
