What the checker requests and what it reports
The canonical tag checker reports the canonical a page declares, as the server delivers it. When you submit a URL, this site's server requests it, follows any redirects to the final response, and parses what comes back: the HTML, the response headers, and the indexing directives. Nothing you enter is stored.
That makes the result a statement about the site, not about Google. A rel="canonical" annotation is, in Google's words, "a hint, not a rule." Google weighs it alongside HTTPS, redirects, sitemap inclusion and other signals, and then selects the URL it considers most useful. The declared canonical and the Google-selected canonical usually agree on a well-built site, but only Search Console can show the second one. Read every result below as "this is what the page asks for," then confirm what Google granted separately.
Reading the redirect hops
The first block lists each hop between the URL you typed and the response that finally carried content, with the status code at every step. Everything after it, including the canonical, comes from that final response. If you entered http://example.com/page and the chain ended at https://www.example.com/page/, the canonical shown belongs to the second URL.
Three patterns deserve attention:
- More than one hop. A chain such as http to https to www to trailing slash usually means several redirect rules fire one after another. Internal links, sitemap entries and canonicals should point at the last URL directly.
- A temporary status in the chain. A 302 or 307 labels the move as temporary. If the change is permanent, the status code should say so.
- A final status other than 200. A canonical read from a 404 or 5xx page describes an error response, not the content you meant to check.
Redirects matter here because Google counts them as a strong canonicalization signal in their own right. A page whose redirects point one way and whose canonical points another is sending two strong signals that disagree.
What each canonical field means
| Field | Healthy value | What a problem looks like |
|---|---|---|
| Canonical in head | One URL | Missing, or more than one |
| Canonical in body | None | Any; Google ignores it |
| HTTP Link header | Absent, or identical to the head value | A different URL from the head |
| Absolute | Yes | A relative path |
| HTTPS | Yes | An http:// target on an HTTPS site |
| Self-referencing | Depends on intent | "No" on a page meant to be indexed |
Head versus body. Google's documentation states that the link element "is only accepted if it appears in the <head> section." A canonical found in the body usually comes from a theme or widget printing markup in the wrong place. It does not count, and if the head carries a different one, the page is also sending a mixed message to other parsers.
The Link header. A canonical sent as Link: <https://…>; rel="canonical" never appears in View Source, which is why it is so often overlooked. On HTML pages it tends to be added by a CDN, a server rule or a plugin. If it names a different URL from the head tag, Google publishes no rule for which one prevails; its guidance is not to specify different canonicals through different methods. Remove one.
Absolute and HTTPS. A relative canonical resolves against whichever host is crawled, so a staging copy ends up nominating itself. An http target on an HTTPS site usually names a redirect.
Self-referencing. "No" is not an error by itself; it means the page nominates some other URL. That is correct on a tracking-parameter variant or a duplicate product path, and wrong on the page you want ranked.
Multiple canonicals. When a page carries more than one, Google has said it will likely ignore all of them. Count across the head, the body and the header together.
Robots meta and X-Robots-Tag alongside the canonical
The checker also reports any robots meta tag and any X-Robots-Tag response header, because a noindex changes how the canonical should be read. A canonical asks Google to consolidate signals onto a target; noindex asks it to drop the page. Google's own staff have characterized the pairing differently over the years, which is itself the lesson: the combination is contradictory, and the reliable course is to choose one. Use the canonical alone to consolidate a duplicate, and noindex alone to keep a page out of the index. Google also says it does not recommend noindex as a way to steer canonical selection within one site.
A noindex sent in the header is as easy to miss as a header canonical, and for the same reason.
What a server-side fetch cannot see
- JavaScript changes. The checker does not execute scripts. A canonical that a framework injects or rewrites after load will not appear, and a "missing" result on a client-rendered site may be wrong about the final page. Google can process a JavaScript-injected canonical during rendering, but its JavaScript SEO guidance warns against using script to change the canonical away from the one in the original HTML.
- What Googlebot receives. Servers can vary responses by user agent or IP address. A request from this site is not a request from Google, and a site that verifies Googlebot may answer differently. Cloaked hacks that insert cross-domain canonicals only for Google fall in this blind spot.
- robots.txt. The report does not evaluate robots.txt. If the page or its canonical target is disallowed, Google cannot read the tag at all.
- The rest of Google's inputs. Internal linking, sitemap entries, how duplicates were clustered and which URL was selected are all outside a single fetch.
- The head boundary. Google stops reading the head at the first element that does not belong there, such as an
imgoriframe. A canonical placed after one can look fine in source and still go unread.
What to do with the result
- Run the canonical target itself through the checker. It should return 200 directly, carry a self-referencing canonical and have no noindex. RFC 6596 advises against a target that is a permanent redirect source or returns an error.
- On a JavaScript-heavy site, compare View Source with the rendered DOM in browser DevTools to see whether script alters the tag.
- For a site you have verified, open URL Inspection and compare the user-declared canonical with the Google-selected canonical in the indexed result. The live test cannot predict the selected canonical.
- If Google chose a different URL that is still acceptable, such as the https or www version you link to anyway, there may be nothing to fix. After a real fix, Google's troubleshooting page allows up to about two weeks for re-evaluation.
Frequently asked questions
Does the canonical checker show which canonical Google chose?
No. It shows the canonical the server declares, in the HTML and the HTTP headers. Google treats that declaration as a hint and may select a different URL. The Google-selected canonical appears only in Search Console's URL Inspection, in the indexed result rather than the live test.
Why does the checker find no canonical when I can see one in the browser?
The tag is probably added by JavaScript after the page loads. The checker reads server-delivered HTML and does not run scripts, while browser DevTools shows the DOM after scripts have finished. Google can pick up a script-injected canonical during rendering, but a canonical in the original HTML is the more dependable arrangement.
My page has an HTML canonical and a Link header canonical. Which one counts?
If they name the same URL, both reinforce the same hint. If they differ, Google publishes no order of precedence, and its documentation says not to specify different canonicals through different methods. Keep the one that is easiest to maintain and remove the other.
Why would the checker see something different from Googlebot?
A server can vary its response by user agent, IP address, location or login state, and the checker is not Googlebot. Sites that verify Google's crawler by reverse DNS may treat any other request differently. When the two disagree, the crawled page and URL Inspection in Search Console are the authority.