Which canonical-tag finding to fix first
A report with several findings at once is not a to-do list in the order it prints them. This tool already grades each finding danger or notice — here is what that grading means in practice, and how to wire the CLI's exit code into CI without blocking a deploy over the wrong finding.
danger findings: the tag contradicts itself or points nowhere useful
| Finding | Why it's danger, not notice |
|---|---|
| Multiple conflicting canonical tags | The page's own markup names two different canonical URLs. Only the first is honoured, so whichever system emitted the second one is being silently ignored — usually two independent sources (a CMS plugin and a hand-written template tag) that don't know about each other. |
| Canonical target unreachable | The tag points at a URL that 404s or errors. The page is telling search engines "index this instead" and naming a dead end. |
| Canonical target marked noindex | A direct self-contradiction: the canonical says "index this page," and that exact page says "don't index me." One of the two is wrong. |
All three are worth fixing before the next deploy, in roughly this order: a broken or noindex'd target first, since the URL you're pointing at needs to actually work; conflicting tags second, since it's a build or template bug that will keep recurring until the duplicate emitter is found.
notice findings: usually real, rarely urgent
| Finding | What to do |
|---|---|
| Relative canonical URL | Works in every major browser and crawler today. Google's own guidance prefers an absolute URL since a relative one leaves the protocol and host to be inferred — fix it as ordinary hygiene, not as a repair. |
| Protocol mismatch (http/https) | Usually a leftover from an http-to-https migration. Low urgency unless the site no longer serves the old protocol at all, in which case the canonical target itself may also be unreachable — check for that finding too. |
| Cross-domain canonical | Needs a judgment call, not a default fix — see the FAQ below. |
| Canonical target redirects | The canonical points at a URL that works, but isn't the final one — it 30x's somewhere else first. Pointing the tag straight at the final URL saves search engines a hop; not urgent, but a quick fix once you're already touching the template. |
No canonical tag at all is a separate, lower-severity notice
Plenty of pages don't need one — a single canonical URL with no
duplicate-content risk gets nothing extra from adding a tag that just
points at itself. Treat a no-canonical-tag finding as a
prompt to ask "does this page have a duplicate (a print view, a
tracking-parameter variant, an amp version)?" rather than as a defect on
its own.
Wiring the CLI into CI on the right signal
node cli/check.mjs <url> exits 1 only when a
danger-severity finding is produced (or the fetch itself fails), and
0 otherwise — including when notice findings are
present. That split is deliberate: gating a deploy on the exit code
blocks the self-contradicting cases above without also failing a build
over a relative URL or a deliberate cross-domain reference. Grep the
--json output for notice-severity findings separately if you
want them tracked, but keep the build gate on the exit code as shipped
rather than tightening it to fail on any finding at all.
Common questions
Does a danger-severity finding mean the page is already deindexed?
Not necessarily. Severity here describes how directly the finding contradicts itself or points nowhere useful, not a confirmed ranking or indexing outcome — this tool checks two fetches, not what a search engine has already done with them. A canonical-target-noindex finding, for instance, is danger because the page's own markup says two contradictory things, which is worth fixing regardless of whether it has visibly affected indexing yet.
Should I fix every notice-severity finding before shipping?
Not on the same timeline as a danger finding. A relative canonical URL, for example, resolves correctly in every major browser and most crawlers today — fixing it is good hygiene per Google's own published guidance, not an urgent repair. Batch notice findings into ordinary cleanup work rather than treating a report with several of them as several fires.
Is a cross-domain canonical always something to fix?
No, and this is the one finding that needs a judgment call rather than a default. Syndicated content pointing back at the original publisher is a legitimate, deliberate use of a cross-domain canonical. A staging or preview hostname left in a canonical tag on the production page is the same finding shape from a copy-paste mistake, and it means production is telling search engines to index the staging copy instead. The finding itself can't tell these apart — check which one you're looking at before deciding what to do.
Should CI fail the build on any finding, or only danger ones?
The CLI's own exit code already makes this distinction for you: it exits 1 on a danger-severity finding and 0 otherwise, specifically so a CI gate can block a real self-contradiction (a broken or noindex'd canonical target, conflicting tags) without also failing routine deploys over a relative URL or an intentional cross-domain reference. Wiring a stricter gate that fails on any finding at all will make the check fire on legitimate cases and get bypassed.
Want the accuracy question instead — what this tool checks and doesn't? See the tool's own FAQ, or how it compares to a whole-site crawler and to checking canonicals by view-source.