Free tool
Canonical Tag Checker
Paste a list of URLs and see every rel=canonical each one declares. Then, unlike other checkers, this tool follows the canonical and tells you if the target redirects, 404s or is itself noindexed. No signup required.
0 URLs entered · free check covers the first 10
Reads every rel=canonical on the page and in the HTTP headers, then follows the canonical to check the target is not a redirect, a 404 or a noindexed page. No signup, no credit card.
Reading the canonical is the easy half
A canonical tag can be present, correctly formatted and completely ignored by Google. Every free canonical checker reports the value and stops there. A canonical only actually works if it survives four further tests, and each of the following silently invalidates it while leaving view-source looking perfect.
1. Is it inside the head?
Google accepts the canonical link element only when it appears in the <head> section. A canonical injected by a tag manager, added by a late script, or pushed into the body by markup that closes the head early is read by your browser and ignored by Google.
2. Is there exactly one?
Two canonicals pointing at different URLs is not a tie Google breaks in your favour. It treats the declaration as unreliable and picks for itself. The cause is almost always a theme and an SEO plugin both writing the tag, and it is invisible unless you count them.
3. Does the target exist?
A canonical pointing at a redirect is self-contradictory: the tag says index this URL, the redirect says this URL moved. A canonical pointing at a 404 asks Google to index a page that is not there. Both are routine after an HTTPS or URL migration, and neither is visible without a second request.
4. Is the target indexable?
If the canonical target carries a noindex, the two directives cancel out. You are asking Google to index that URL instead of this one, and telling it not to index that URL. The noindex often lives in an X-Robots-Tag header, which never appears in page source at all.
The checker above makes a second request to every canonical target to answer questions 3 and 4, and reports canonical loops and chains it finds on the way. If you also want to know whether a page is blocked outright, the noindex checker covers robots.txt, the robots meta tag and the X-Robots-Tag header.
Search Console tells you the tag is there, not that it works
When Search Console calls a canonical tag “proper”, it means present and parseable. It does not mean the target is healthy. That one word is the gap this checker exists to close, and it is invisible from the Search Console report alone.
The failure it hides
If the canonical target redirects, 404s or carries a noindex, the alternate page is still excluded, but the target never picks up the signal. The content then disappears from both URLs while the report reads as though the setup is working. The checker above fetches every target and reports its status code, redirect chain and robots directives, including the X-Robots-Tag header, which never appears in page source.
Most URLs in that report belong there: product variants, faceted and tracking-parameter URLs, print versions, feeds and paginated views all produce it correctly, and a large count on a site with parameters is evidence the consolidation is working. For the full explanation of the status, the two cases where it really does cost you traffic, and how to triage a report with more URLs than you can inspect, see “alternate page with proper canonical tag”: when to worry.
One neighbouring status is worth separating out, because it is the opposite situation and it does need action: “Duplicate, Google chose different canonical than user” means Google read your tag and overruled it, which points at your internal links, sitemap or redirects rather than the tag itself. If the page is being kept out by a robots directive instead, that is a different cause entirely and the noindex checker is the right tool. To see which canonical Google actually picked for a given URL, open URL Inspection in Search Console and compare “User-declared canonical” with “Google-selected canonical”.
A canonical is a hint, not a command
Google describes rel=canonical as a strong signal for canonical selection, and ranks it below redirects and above sitemap inclusion. It is one input among many, not an instruction. Google can read your canonical, weigh it against everything else it knows, and choose a different URL. When that happens you get the “Duplicate, Google chose different canonical than user” status instead.
Which means a canonical tag rarely fails on its own. It fails because something else outweighs it:
- A redirect pointing the other way, which is a stronger signal than the tag
- Internal links across the site consistently pointing at the non-canonical URL
- A sitemap listing the duplicate rather than the canonical
- Pages that are not actually near-duplicates, so consolidating them makes no sense to Google
- hreflang clusters referencing a different URL than the canonical does
The practical consequence: fixing the tag is step one, not the whole job. Once the tag is right, confirm Google actually acted on it by checking whether the URL you wanted is the one in the index, which is what the Google index checker answers.
What each result means, and how to fix it
| Result | What it means | What to do |
|---|---|---|
| Self-referencing | The canonical points at the page it is on. The default you want on any page you intend to rank. | Nothing. |
| Points elsewhere | A same-site canonical to a healthy target. This is the page that will show up as “Alternate page with proper canonical tag”. | Confirm it is deliberate. If this is a page you want ranking, change it to self-referencing. |
| Cross-domain | The canonical points at another domain. Correct for syndicated content, damaging as a migration leftover. | Check the domain is one you meant. Staging and old client domains show up here. |
| No canonical | Nothing declared. Google will pick a canonical for you from content similarity and linking signals. | Add a self-referencing canonical using an absolute URL. Not urgent unless the content is reachable at more than one URL. |
| Broken canonical | A canonical exists but Google cannot act on it: it sits outside the head, conflicts with another tag, or points at a redirect, a 404 or a noindexed URL. | Fix first. This is worse than having no canonical, because it looks correct in view-source. |
The mismatch that causes most accidental canonicals
When a canonical is wrong, it is usually wrong by a hair rather than by a mile. The tag points at the same page, in a slightly different form: http instead of https, with www instead of without, or with a trailing slash the site no longer serves. Every one of those variants now redirects, so the canonical resolves to a redirect and Google discards it. The cause is almost always a migration where the redirect rules were updated and the templates that build canonical URLs were not. The checker calls these out specifically rather than lumping them in with any other “points elsewhere” result.
Canonicals break long after you set them
A canonical you wrote correctly can be invalidated by a change made somewhere else entirely, months later. Someone adds a redirect and every canonical pointing at the old URL becomes a dead pointer. A plugin update starts writing a second canonical tag. A staging config reaches production and noindexes the target. None of these touch the page you are worried about, and none of them announce themselves.
That is the gap a one-off checker cannot close. It tells you the truth about this moment and then forgets. The traffic drop shows up weeks later, and by then the change that caused it is buried in a deploy log.
Keep watching after you close this tab
SearchOptimo re-checks your URLs on a schedule, keeps an index history timeline per URL, and alerts you the day a page drops out of Google. You find out when it happens, not when you next remember to look.
Frequently asked questions
- Does Google always follow the canonical tag?
- No. Google describes rel=canonical as a strong signal, not a directive, and it is one of roughly a dozen inputs into canonical selection. Redirects outrank it. Internal linking, sitemap inclusion, HTTPS preference and content similarity all feed in too. If the pages are not genuinely near-duplicates, or your other signals contradict the tag, Google can and does choose a different canonical. That is why a canonical checker that reports the tag in isolation only tells you half the story.
- What happens if the canonical points to a redirect or a 404?
- The signal is discarded and Google falls back to picking a canonical itself. A canonical pointing at a redirect is a contradiction: the tag says "index this URL", the redirect says "this URL moved". A canonical pointing at a 404 asks Google to index a page that does not exist. Both are common after an HTTPS migration or a URL restructure, because templates keep emitting the old URL form. Neither shows up in view-source, which is why this checker fetches the canonical target as a second step.
- Can a canonical point to a noindexed page?
- It can be written that way, but it cancels itself out. You are telling Google to index the target instead of this page, and telling it not to index the target. Google's guidance is to use a canonical or a noindex, not both on the same content set. The likely outcome is that neither URL ends up where you wanted it. The checker above reports the target's robots directives, including the X-Robots-Tag header, which never appears in the page source.
- Does a canonical tag outside the head work?
- No. Google's documentation is explicit that the rel=canonical link element is only accepted if it appears in the head section of the HTML. A canonical injected into the body by a tag manager, a late-loading script or invalid markup that closes the head early is ignored. This is a genuinely invisible failure: view-source shows a canonical, Search Console shows none. The checker above reports where each tag was found.
- What happens if a page has two canonical tags?
- Conflicting canonicals are not a tie Google breaks in your favour. When a page declares more than one canonical target, Google treats the declaration as unreliable and selects a canonical itself, ignoring both. The usual cause is two things writing the tag: a theme plus an SEO plugin, two SEO plugins, or a CMS default plus a template override. Removing one is the fix.
- Is a cross-domain canonical bad?
- Only when it is unintentional. A cross-domain canonical is correct for syndicated content: if you republish your article on a partner site, that copy should canonicalise back to your original. It is a disaster when it is left over from a migration, so that your production pages canonicalise to a staging domain or an old client domain. In that case you are asking Google to index a URL you may not even control. The checker flags every cross-domain canonical so you can confirm each one is deliberate.
- Should every page have a self-referencing canonical?
- It is a good default, but Google is clear that canonicals are not required and most sites do fine without them. The real value of a self-referencing canonical is defensive: it stops tracking parameters, trailing slash variants, uppercase URLs and http versus https duplicates from being treated as separate pages. Use absolute URLs rather than relative paths, because a relative canonical resolves against whatever host serves it, including a staging domain that was never meant to be crawled.
Fix it once. Then know when it breaks again.
Checking by hand catches today’s broken canonical. Monitoring catches the one a future redirect is going to create. Free forever plan, no credit card, cancel anytime.