One of three values is off: status, redirects, canonical

This code bundles three distinct availability defects into a single finding. A page gets it when at least one of them holds, and at most once, even if all three hold at the same time:

1. An error status. The page answered with 400 or above (4xx or 5xx).
2. A long redirect chain. Reaching the content took more than 2 hops. The threshold lives in config/thresholds.json under rule_engine.ACC-04 as max_redirect_hops: 2 and comes from the product specification.
3. A missing canonical. The page has no <link rel="canonical">.

The third condition has a safeguard worth knowing about: canonical is only judged on genuinely live content (a 2xx response) and only on pages that are not themselves a step in a redirect chain. A URL that merely redirects elsewhere neither has nor needs a canonical; the destination of the chain carries its own. Without that distinction the report would flag every old URL you had correctly redirected.

What the check does not do:

• It does not judge whether the canonical points anywhere sensible. It only checks that one exists. A canonical pointing at another domain, or at your home page, passes.
• The title does not tell you which of the three reasons fired: it is one shared title for all three, because the report groups findings of the same code under a single title. Since 2026-09-19 the finding text does print all three measured values (status code, redirect hops, number of rel="canonical" links), so you can see which one is off, and the recommendation says explicitly to deal only with that one. This came out of a production audit where only the canonical arm applied and the customer was still told to fix 4xx/5xx links and shorten redirects, with nothing to act on.
• It does not separate 4xx from 5xx. For broken links leading out of your pages there are SIT-03 (4xx) and SIT-04 (5xx), which can also tell you which page the link was on. ACC-04 talks about the page itself.
• It never counts hops that leave the domain. The crawler never leaves the domain you gave it.

The finding is page-level; severity is warning.

An error page does not get indexed. That settles it, and it is the strongest class of claim we have, because Google states it in its own documentation:

To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet. There are no additional requirements.Google Search Central, AI features

Within the finding, though, the strength of evidence varies, and it would be dishonest to hide that:

In practice: take the 4xx and 5xx part of this finding seriously and treat canonical as housekeeping. The report shows you per page what exactly is wrong with it, so the distinction is easy to make yourself.

Work in order of impact, not of count:

1. 5xx pages first. A server error is your problem, not the visitor's, and it often comes and goes; if we saw it, somebody else did too. Check your logs for that timestamp.
2. Then 4xx. For each one, decide whether the content moved somewhere (then a permanent 301 straight to the destination) or is gone for good (then a clean 404, or 410 when you want to tell crawlers not to come back).
3. Then redirect chains. Shorten them to a single hop: redirect the original URL straight to the final destination, not via waypoints. Chains accumulate in layers: first http → https, then www, then a new URL structure. Each layer is one hop.
4. Canonical last. Add <link rel="canonical"> with an absolute URL of the preferred version to every indexable page.

<link rel="canonical" href="https://your-domain/path-to-page" />

Where this usually goes wrong:

• A canonical pointing at itself is correct. It is neither an error nor a duplicate; it is how you say “this is the right URL”.
• A relative canonical works but is risky. An absolute URL cannot break when the base path changes.
• A canonical pointing at the version with parameters. If a page exists both with ?utm_source=… and without, the canonical must point at the clean one; otherwise every campaign mints its own canonical page.
• A 302 where a 301 belongs. A temporary redirect says “come back here next time”. For a permanent move, use 301.
• A redirect loop after the fix. When rewriting rules, verify the result from outside (curl -IL), not just in the configuration.