This canonical tag checker finds the wrong canonicals that quietly deindex pages or split your ranking signals. Paste any page for an instant free check, no signup, then crawl every page to catch the paginated, filtered and parameter URLs where canonical bugs actually hide.
Instant free check of one page. Sign up to check every URL.
The instant check reads your homepage's canonical. A full crawl checks every page's canonical against the rules below.
Every indexable page should declare a rel="canonical".
The canonical should point to the page's own clean URL unless you intend otherwise.
The canonical target must be a live page - not a redirect or a 404.
Flags canonicals that point at a URL which then redirects - a wasted signal.
Canonicals should use https, not leftover http after a migration.
A full audit tracks pages whose canonical changed between crawls.
Canonicalisation is subtle but high-impact - these are the rules that keep your ranking signals where they belong.
On every indexable page, add <link rel="canonical" href="THIS-PAGE-CLEAN-URL"> pointing to its own URL. This is the safe default and stops search engines guessing which of several similar URLs to index.
The URL in your canonical must be live and canonical itself - not a redirect, not a 404. A canonical pointing at a redirected URL is ignored, and Google picks its own. Re-check after any HTTP→HTTPS or trailing-slash change.
A common template bug: every page in a paginated series canonicalises back to page 1, which deindexes pages 2+. Each paginated page should self-reference (or use proper pagination handling), not point to page 1.
Your canonical, your hreflang annotations, and the URLs you link internally should all point at the same canonical version. Mixed signals (linking to one URL but canonicalising to another) confuse crawlers.
Canonical is a hint for consolidating duplicates - it is not a way to deindex a page (use noindex for that) or to block crawling (use robots.txt). Use the right tool for each job.
A rel="canonical" tag tells search engines which URL is the preferred version when similar or identical content is reachable at more than one address. It consolidates ranking signals onto a single URL instead of letting them split across variants, which is what prevents duplicate-content dilution.
It is a hint rather than a directive. Search engines usually respect a clear, consistent canonical, but they will override one that contradicts your other signals.
Every indexable page should carry a self-referencing canonical pointing at its own clean URL. That is the safe default and it removes the guesswork about which of several similar URLs to index. The exception is a page you deliberately want consolidated into another, in which case the canonical points at that target instead.
A canonical-to-redirect error is a canonical that points at a URL which then redirects, or that 404s outright. Google ignores the tag and picks a canonical of its own, so the signal you intended is simply lost. Every canonical must resolve to a live 200 URL, and this is worth re-checking after any HTTP to HTTPS migration or trailing-slash change, which are the usual sources of the problem.
The instant check above reads your homepage's canonical with no signup. To cover the rest, run a full audit, which checks every page's canonical for presence, self-reference, HTTPS, a live 200 target, canonical-to-redirect problems, and changes between crawls so you can spot a template edit that quietly rewrote canonicals site-wide.
The most common bug is not a missing canonical, it is a canonical that points somewhere it should not.
A canonical is a hint, so it must resolve cleanly to a live, self-consistent URL. The failures the checker catches are all versions of "the target is not a stable 200": a canonical to a redirect, to a 404, to an off-domain URL, or every paginated page canonicalising to page 1. There is also a quieter case the tag alone will not reveal: a correct canonical in the HTML that is overridden by an HTTP Link: header or injected by JavaScript, so Google sees a different value than you wrote. If your canonical looks right but Google keeps picking another URL, check the response headers and the rendered DOM, not just the source.
Once the checker shows a wrong canonical, here is where you change it.
Both SEO plugins output a self-referencing canonical automatically, which is correct for most pages. To override one, use the plugin's Advanced tab on the post (Yoast: Advanced → Canonical URL; Rank Math: Advanced → Canonical URL). If a canonical is pointing at the wrong place, it is almost always a manual override left in that field, clear it to restore the self-reference.
Shopify sets canonicals automatically and, by design, points product URLs seen through a collection (/collections/x/products/y) at the clean product URL (/products/y). That is correct. Custom canonicals require editing theme.liquid under Online Store → Themes → Edit code, look for the canonical_url output in the <head>.
Canonicals are set in your head/metadata component. The frequent bug here is a hard-coded or templated canonical that does not update per route, or one built from the wrong base URL (staging domain, trailing-slash mismatch). Make it derive from the page's own resolved URL, and confirm the same value survives into the rendered HTML.
A canonical tag is a claim about which URL is the real version of a page. Checking one tells you whether that claim is well-formed. Checking all of them tells you whether the claims agree with each other, which is where canonical problems actually live.
For one URL, a canonical is correct when it is present exactly once, uses an absolute URL, points at a page that returns 200, and either references the page itself or a genuine master version of the same content. A page with two canonical tags is a common bug and search engines may ignore both, so counting them matters as much as reading them.
This level of check catches the obvious faults: a relative URL that resolves wrongly, a canonical left pointing at a staging domain, a canonical pointing at a URL that now 404s. All are real, all are fixable in one edit, and all are invisible to a visitor.
The expensive canonical problems are relational. A canonical chain, where A points to B and B points to C, forces search engines to resolve indirection they may simply abandon. A canonical loop, where two pages name each other, is unresolvable by definition. A whole section canonicalising to the homepage, usually the result of a template default that was never overridden, quietly removes every page in that section from search.
Each of these is perfectly well-formed on any individual page. You cannot see a chain by looking at one link in it. Finding them means collecting the canonical target of every URL and looking at the resulting graph, which is a bulk operation by nature.
Canonical tags do not act alone, and the confusing bugs come from disagreement between signals rather than from a bad tag. A page that canonicalises elsewhere while appearing in your sitemap sends two opposite instructions. A canonical target that is itself noindexed asks a search engine to consolidate onto a page it has been told to exclude. An hreflang cluster whose members canonicalise outside the cluster breaks the cluster.
Reconciling these requires seeing canonical, sitemap, robots and hreflang data for the same URL side by side. That comparison is the practical reason to check canonicals across a whole site rather than page by page, and it is why canonical findings so often turn out to be sitemap or indexability findings in disguise.
Read the mechanics behind a check, or run the next tool on the same site.
Read the guide
How rel=canonical works and the mistakes that quietly deindex pages.
How canonicals resolve duplicate and near-duplicate URLs.
When to use noindex versus canonical, and how they differ.
Run another check
Free to start. Crawl your site and catch every canonical mistake.
Check my canonicals