en
/login
Koval SEO

The page named as the main one cannot be reached

In the reportCanonical target error

canonical_target_error · Issue

Short answer

This appears when pages name an address on your site as their canonical, and that address fails: it answers a 4xx error other than 429, a server error on both of our requests, or redirects in a loop or more than ten times. A 401 or 403 is kept for review, because access rules may answer our crawler differently, and a 429 is noted as not covered. Point the canonicals at a page that works, or restore the named one.

Severity: High. Fix confirmed errors soon: the address you chose as the main one cannot be read. For a 401 or 403, first check who can reach the address, since our crawler's access may differ.

Why it matters

Google does not index addresses that answer with a 4xx error other than 429, and it slows down and eventually drops pages that keep returning server errors. The canonical link standard asks not to name an address that returns an error.

What to do

  1. Look at the finding: it shows the named address, its final status or redirect steps, and the pages that name it.
  2. If the named page should exist, restore it so that it answers 200.
  3. Otherwise change the canonicals on the listed pages to a page that works, often the page's own address.

When to leave it as it is: if the named page answers 401 or 403 only to our crawler and your visitors reach it, confirm who can access it before changing the canonicals.

What we read

We read the canonical of each crawled page and group pages by the one other address on your site they name. That address is found in the crawl, or fetched separately when the crawl did not reach it, up to 20 per audit by default, following up to ten redirects, respecting robots.txt and retrying once after a server error or 429.

The named address is reported when its final answer is a 4xx other than 429, a 5xx on both requests, or when its redirects loop or run past ten. A 401 or 403 is reported as a review item with low confidence. A 429, a timeout or a single server error is noted as not covered.

Example & evidence

Illustrative example — one page and the address it names, not a live audit.

https://bakery.example/cakes/?page=2 declares:

<link rel="canonical" href="https://bakery.example/cakes-archive/">

The crawl did not reach that address, so it is fetched separately:

GET https://bakery.example/cakes-archive/
HTTP/1.1 404 Not Found

The named address answers 404, so it is reported: Canonical target returns HTTP 404.

A possible correction: if https://bakery.example/cakes/?page=2 is the intended canonical page and answers 200, make it name itself.

Confirm & check again

Check for yourself: open the address named in the canonical in a browser and in a private window, and see what it answers.

Check again: Full audit — Run a new audit of the site. A sufficiently complete recheck of the same target can close this finding when its settled response no longer meets this rule’s error conditions. While the target is still named, a timeout, a 429 or a single server error cannot establish that it has recovered. It can also close when complete, readable canonical inventories from every previously associated source page prove that none still names this address as its one canonical target. A complete inventory with multiple distinct canonicals may establish that; an unread or incomplete inventory cannot. A replacement target is judged separately: its health or robots policy is not part of proving that the old single-target group has disappeared. A missing, partial or non-HTML source response, or a redirect by itself, does not prove removal.

Limits & sources

Only the status is read, so a page that shows a not-found message while answering 200 is not caught, and named pages beyond the 20 fetched separately are not checked.

Confidence: High for 4xx and redirect failures, read directly; a server error counts only when both requests fail, and a 401 or 403 is marked with low confidence.

Sources

Editorial review: 2 November 2026