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.
“Alternate page with proper canonical tag” is not an error
It is the single most misread status in Google Search Console, and the reason is placement: it is listed under “Why pages aren’t indexed”, next to genuine problems like server errors and soft 404s. So people try to fix it. In almost every case there is nothing to fix.
What it actually means
Google found this URL, saw a rel=canonical on it pointing at a different URL, agreed with your choice, and indexed that other URL instead. The status is Google confirming your canonical worked. The page is excluded deliberately, by you, and the version you wanted is in the index.
Pages that legitimately land in this report
On most sites, the majority of URLs in this report belong there. All of the following are normal and correct:
- Product variant URLs (?color=red, ?size=10) canonicalising to the main product page
- Filtered and faceted category URLs canonicalising to the unfiltered category
- URLs carrying tracking parameters such as ?utm_source or ?gclid
- The same product reachable through more than one collection or category path
- Print-friendly versions of articles
- AMP pages canonicalising back to their responsive originals
- RSS and feed URLs for content that also has a real page
- Paginated views canonicalising to a "view all" page
The three cases where it does point at a real problem
1. A page you want ranking is in the report
This is the one that costs money. A page you spent time on is quietly excluded because something set a canonical pointing away from it. Export the report, look for URLs you recognise as money pages, and give each one a self-referencing canonical. On a CMS this is usually a per-page setting in the SEO plugin rather than raw HTML.
2. The count is out of proportion to your site
Thousands of alternates on a site with a few hundred real pages is a URL generation problem, not a canonical problem. The canonicals are doing their job; the site is manufacturing duplicates faster than Google can dismiss them. Look for internal links carrying UTM parameters, filter combinations that are linked rather than generated on click, and session or sort parameters in navigation. On a large site this becomes a crawl budget issue before it becomes an indexing one.
3. The canonical points at something broken
Search Console says the canonical tag is “proper”, meaning present and parseable. It does not promise the target is healthy. If the target redirects, 404s or carries a noindex, the alternate page is excluded and the canonical target never picks up the signal, so the content disappears from both URLs. This is the case the checker at the top of this page is built to catch, and the one you cannot see from the Search Console report alone.
The status it is often confused with
| Search Console status | What Google is telling you | Act on it? |
|---|---|---|
| Alternate page with proper canonical tag | Google read your canonical and agreed with it. The target was indexed instead. | Usually not |
| Duplicate, Google chose different canonical than user | Google read your canonical and overruled it, picking a different URL. Your other signals (internal links, sitemap, redirects) contradict the tag. | Yes, investigate |
| Duplicate without user-selected canonical | Google found duplicates and you declared no canonical at all, so it chose one for you. | Yes, add canonicals |
| Excluded by ‘noindex’ tag | A robots directive, not a canonical, is keeping the page out. Different cause entirely. | Only if unintended (check it here) |
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”. If they differ, the tag is not the problem: the rest of your signals are.
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
- What does "Alternate page with proper canonical tag" mean in Search Console?
- It means Google found this URL, saw that it carries a rel=canonical pointing at a different URL, agreed with your choice, and indexed that other URL instead. Despite appearing under "Why pages aren't indexed", it is not an error. It is Google confirming your canonical setup worked exactly as intended. The page is excluded on purpose, and the version you wanted indexed is the one in the index.
- Do I need to fix "Alternate page with proper canonical tag"?
- Usually no. Product variants, filtered and faceted URLs, tracking parameter URLs, print versions, AMP pages, RSS feed URLs and paginated views all legitimately produce this status. You only need to act in three cases: a page you actually want ranking is listed there, the count is wildly out of proportion to your site size (thousands of alternates on a few hundred real pages), or the canonical points at a URL that redirects, 404s or is noindexed. The checker above tests that third case for you.
- What is the difference between "Alternate page with proper canonical tag" and "Duplicate, Google chose different canonical than user"?
- They are opposites. "Alternate page with proper canonical tag" means Google followed your declared canonical. "Duplicate, Google chose different canonical than user" means Google looked at your canonical, disagreed, and picked a different URL. The first is confirmation. The second is a signal problem worth investigating, usually caused by internal links, sitemaps or redirects pointing somewhere other than your declared canonical.
- 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.