What a canonical tag actually does
A canonical tag is a hint, not a directive. <link rel="canonical" href="..."> tells Google (and Bing, and most other crawlers) which URL you would prefer to represent a set of duplicate or near-duplicate pages in search results. Google's own documentation is explicit that it treats this as one signal among several, alongside redirects, internal linking patterns, and the sitemap. A page can carry a perfectly correct canonical tag and still get indexed under a different URL, if enough other signals point the other way. That gap between "what you declared" and "what Google actually chose" is exactly why this tool exists: it can tell you what a page's canonical signals say, not what Google decided to do with them, and those are two different questions.
Canonical versus redirect versus noindex, and when each is right
These three get reached for interchangeably and they are not interchangeable. A redirect (301 or 308 for a permanent move) sends both the visitor and the crawler to a different URL; nothing serves at the old address any more. A canonical tag leaves both URLs live and reachable, and only asks a crawler to consolidate ranking signals onto the one you named. A noindex tag or header tells a crawler this exact page should never appear in results at all, full stop, regardless of any other page.
The rule of thumb: if the old URL should stop existing, redirect it. If two URLs need to keep working (a desktop and a mobile-specific version, a page reachable with and without a tracking parameter, a print view), canonicalize the duplicate onto the primary one. If a page should genuinely never be searchable, whether or not anything else links to it, noindex it. Mixing these up is common and specific: canonicalizing a page you actually want gone (it stays crawlable and can still surface), or noindexing a page you only meant to deduplicate (you lose it from search entirely instead of consolidating it).
Cross-domain canonicals and syndication
A canonical does not have to point at the same domain, and sometimes it deliberately shouldn't. Syndication is the standard legitimate case: a publication picks up your article and republishes it verbatim, and their copy carries a canonical pointing back at your original. That tells Google the two pages are the same content and the ranking credit should consolidate on your original, not split between two near-identical pages competing with each other.
The failure mode is the same mechanism used by mistake. If a page you actually want to rank on its own carries a cross-domain canonical, pointing at a partner site, a syndication network, or a staging environment that never got cleaned up, you are telling Google not to index this copy at all. This tool flags every cross-domain canonical it finds, because the same signal is correct in one context and a self-inflicted deindexing in the other, and the only way to tell them apart is knowing which page you meant to rank.
The WordPress and Shopify mistakes that show up here every time
Two platforms produce the same handful of canonical bugs often enough that they are worth naming directly. On WordPress, the most common one is an SEO plugin and a theme both writing a canonical tag, usually disagreeing, which is exactly the multiple-conflicting-canonicals case this tool flags as critical. A close second is pagination: /blog/page/2/ self-canonicalizing correctly is fine, but a misconfigured plugin sometimes canonicalizes every paginated page back to page 1, which can quietly remove the deeper pages from the index. On Shopify, the recurring one is product variants and collection-filtered URLs (colour, size, sort order as query parameters) all serving the same product but with the canonical missing or pointing at the wrong variant, alongside apps that inject a second canonical tag on top of the theme's own. Both platforms share the same underlying cause: more than one system independently believes it owns the canonical tag, and nobody checks whether they agree.
Why a canonical to a redirecting URL is self-defeating
If the URL named in a canonical tag itself redirects somewhere else, a crawler now has to follow another hop just to find out where the canonical actually points. The whole purpose of a canonical tag is to name the one true URL directly; naming a URL that immediately forwards elsewhere undoes that in one step. This usually happens after a migration: a site moves to a new URL structure, sets up redirects from the old URLs to the new ones, and forgets that a batch of canonical tags across the site still point at the old structure. Every one of those pages is now telling Google "the real version of this page is over here", at an address that itself says "actually, it's over there". Fetching a page by URL in the tool above checks exactly this, by requesting the canonical target and seeing whether it resolves directly or bounces again.
Reading both signals at once
Google reads a canonical from two places: the HTML <link rel="canonical"> tag, and (for anything served with a Link response header, HTML or not) an HTTP header of the same form. Most site owners only ever check the HTML tag, because that's the one visible in view-source. The header is invisible in a browser tab and gets set independently, often by CDN or reverse-proxy configuration rather than the page template that writes the HTML tag, which is exactly how the two drift apart without anyone noticing. If you also want to see how a crawler handles the rules that live outside a page's own markup, the robots.txt tester covers the file that governs whether a crawler reaches the page at all, and the link decoder covers what a URL's own query string is carrying once a crawler (or a visitor) does reach it. Every check above runs against whatever HTML and headers you feed it, either pasted directly or fetched through a small server-side hop, because a browser can't read another site's response headers directly. See all free tools for the rest of the set.