Canonical Tag Checker
Fetches a URL you choose for real, reads its canonical link tag(s), and --
when there is exactly one -- fetches that URL too, then classifies the evidence into named
canonicalization misconfiguration patterns: multiple conflicting canonical tags,
a relative or cross-domain canonical, a
protocol mismatch, and a canonical target that is
unreachable, redirects, or is itself marked
noindex.
1. Run the CLI against your page
Node.js, no dependencies to install:
node cli/check.mjs https://example.com/some/page --jsonGet check.mjs, probe.mjs, and analyze.mjs from the repo — plain Node, nothing to install. It only ever talks to the page's URL, and (when relevant) the one canonical URL it names; nothing goes through this site.
2. Paste the JSON output here
Paste the JSON from step 1 and click Check.
Report
What was fetched
| Fetch | URL | Status | Redirects |
|---|
Common questions
What does a canonical tag actually do?
A link tag with rel=canonical and an href in a page's head tells search engines which URL is the authoritative version of this content, so duplicate or near-duplicate URLs (with tracking parameters, alternate sort orders, http vs https, www vs no-www) consolidate their ranking signal onto one page instead of splitting it.
Why does this need a CLI instead of just checking a URL I type into the page?
Reading another origin's response headers and body from inside a browser tab is CORS-gated, and most sites set no Access-Control-Allow-Origin at all -- so a page running in your browser cannot reliably fetch an arbitrary URL and read what came back, even a URL you own. Only a non-browser HTTP client, like the CLI here (or curl), can do that. Run the CLI, then paste its JSON output here for a rendered report.
Why does it sometimes make a second request?
When the page names exactly one canonical URL that differs from the page you fetched, the tool follows it -- the same way a search engine would -- to check the canonical target actually resolves, does not redirect further, and is not itself marked noindex. A canonical is only useful if the page it points at is a real, indexable page.
Is a cross-domain canonical always wrong?
No -- it is a real, supported pattern for syndicated content, where a republished article points its canonical back at the original source. It is flagged as a notice worth checking because it is also exactly what a hardcoded staging URL or a copy-pasted template leaves behind, and either mistake silently tells search engines to index a different site's page instead of yours.
Does a clean report mean the page has no SEO issues?
No. This checks canonical-tag evidence from one or two real fetches -- it is not a full SEO audit, does not crawl your whole site, and cannot see an issue outside what a canonical tag and its target page can show. Treat a clean report as evidence about this specific page's canonicalization, not a determination that the page or site has no other SEO problems.
Already running a full-site crawl? See how this checker compares to Screaming Frog SEO Spider — a one-URL CI gate next to a whole-site crawler, and when each one is the right tool. Only checking one page yourself? See how this compares to reading a canonical tag in view-source — the difference is whether anyone fetches the page the tag points at.
Seeing a "danger" finding on a page with a tag on it, not a missing one? See why two canonical tags is worse than none — a plugin and a template can both emit one, and only the first is ever honored. Got a report back with several findings at once? See which one to fix first.