What is a canonical URL?
A canonical URL is the address a site names as the preferred version of a page that can be reached at several URLs — with tracking parameters, with and without www, in another letter case. It is declared with rel="canonical" (RFC 6596) in the HTML head or an HTTP Link header, and search engines treat it as a strong signal rather than a command, alongside redirects, sitemaps and internal links.
How to use Website Canonical Checker
- Enter the full URL of the page — including any query string you want to test, such as ?utm_source=news.
- Choose who to fetch as: the default Mutqan checker, a Googlebot User-Agent or a mobile browser User-Agent.
- Keep "Also request the canonical URL" ticked to check the target too, then press Check canonical.
- Read the Summary and Findings, then the Declarations table to see where each canonical came from.
Website Canonical Checker features
- Fetches the page through the Mutqan server with a choice of User-Agent (Mutqan checker, Googlebot or a mobile browser), following and listing up to five redirects
- Reads canonical declarations from the HTML head and from the HTTP Link header, and classifies the result: self, another URL, another host, an http:// downgrade, relative, conflicting or missing
- Explains near misses: a canonical that differs only by a trailing slash, letter case or query string, or that points to the URL which redirected here
- Flags canonicals placed in the body, relative or invalid hrefs, fragments and duplicate declarations
- Requests the canonical URL once more (no redirects followed) to show whether it answers 200, redirects, fails, is noindex or declares another canonical
- Checks the hreflang alternates beside it: valid codes, absolute URLs, a self-reference, x-default and alternates placed on a non-canonical page
- Reports noindex from meta robots or X-Robots-Tag, which overrides any canonical
Inputs and outputs
Inputs
- Page URL — any public http(s) page; the Mutqan server fetches it and follows up to five redirects.
- Fetch as — one of three fixed User-Agents (Mutqan checker, Googlebot, mobile browser); no other header can be set.
- Also request the canonical URL — on by default; one extra request to the canonical target without following redirects.
Outputs
- Summary — the canonical relation (self, other-page, cross-host, http-downgrade, relative, multiple or missing), where it was declared, the page status, redirects and hreflang count.
- Canonical — requested and final URL, the canonical URL, what the canonical answers, and the indexing directives found.
- Findings — every problem with the canonical, or "No canonical issues found."
- Declarations, hreflang alternates and Redirect chain — each declaration with its source and placement, the alternates, and the hops before the final URL.
Website Canonical Checker example
A tracking URL whose canonical redirects
Input:
http://example.com/products/blue-shirt?utm_source=news · Fetch as: Mutqan checker · Also request the canonical URL: onOutput:
Canonical other-page (points to another URL) · Declared in link · HTTP status 200 · Redirects 1 · hreflang 2
Canonical URL https://www.example.com/products/blue-shirt · Canonical answers 301 Moved Permanently
Findings: The canonical strips the query string: expected for tracking or filter parameters, wrong if the parameters change the content. · The canonical URL redirects (HTTP 301 to https://www.example.com/products/blue-shirt/): point the canonical at the final URL, which must answer 200.
hreflang findings: No x-default alternate … · hreflang alternates on a page whose canonical points elsewhere are ignored; put hreflang on the canonical page.How to read the Website Canonical Checker results
self is the healthy result for the URL you want indexed: the canonical equals the final URL. other-page is right for a duplicate (a tracking or filter URL) and wrong for a page that should rank on its own.
cross-host is legitimate for syndicated content or the www and non-www variant you redirect to; anywhere else it hands the page's signals to another site. http-downgrade on an https page is almost always a template mistake.
multiple means two or more different canonical targets (HTML and Link header, or two link elements): search engines may ignore all of them. missing means search engines choose a canonical themselves.
"Canonical answers 301" or 404 means the canonical is a dead end; it must answer 200 and declare itself as canonical. A noindex on either page overrides the canonical.
When to use Website Canonical Checker
- Check that tracking, sorting and filter URLs point their canonical at the clean product or article URL.
- Find out why Search Console reports "Duplicate, Google chose different canonical than user": look for redirects, conflicting declarations or a canonical that redirects.
- After a migration to https or a new domain, confirm that canonicals use the new scheme and host and no longer point at redirected URLs.
- Compare what the page declares to Googlebot and to a mobile browser when a site serves different HTML by User-Agent.
Troubleshooting
- missing although the canonical is visible in the browser's inspector: the link is added by JavaScript after load. The checker reads the HTML the server sends and runs no script; render the canonical on the server.
- cross-host for www and non-www: decide which host is canonical, redirect the other to it, and make canonicals use the same host.
- "The canonical URL could not be requested": the target host refused the request, timed out, or resolves to an address the Mutqan server may not contact. Untick the option to check the page alone.
- The page answers 403 or a challenge page: the site blocks automated clients by User-Agent or IP range. Try the Googlebot profile, or check the page source in your browser.
Frequently asked questions about Website Canonical Checker
Should every page have a self-referencing canonical?
It is the recommended default: a page that names its own clean URL as canonical tells search engines which version to keep when tracking parameters, session ids or letter-case variants create duplicates. The checker shows the relation "self" when the canonical equals the final URL after redirects, ignoring only the #fragment.
Why does a canonical in the body not count?
Google honours rel="canonical" only in the head of the page. A link element placed after the body starts — often injected by a script or a misplaced template — is reported as a finding and left out of the result.
What happens when the HTML and the Link header disagree?
Two different canonical targets are a conflicting signal, and Google may ignore both and choose a canonical itself. The checker reads the HTTP Link header (rel="canonical") as well as the HTML link elements and reports when their targets differ.
Why does the checker request the canonical URL as well?
A canonical is only useful if it leads to a page that answers 200. A canonical that redirects, answers 404, declares yet another canonical or is noindex sends mixed signals. The second request does not follow redirects, so a redirecting canonical shows up as such. Untick the option to make a single request.
Is the canonical a directive search engines must obey?
No. RFC 6596 defines it as the author's preferred URL, and Google treats it as a strong signal — weaker than a redirect, stronger than sitemap inclusion — rather than a rule. Consistent signals — redirects, sitemap URLs and internal links that all use the canonical — make it far more likely to be followed.
Technical notes
The canonical link relation is defined by RFC 6596; the Link header syntax by RFC 8288. Both sources are read: link elements with rel="canonical" in the HTML, resolved against the document base (the first base element, else the final URL), and Link header entries with rel="canonical", resolved against the final URL.
Comparisons ignore only the #fragment: the scheme, host, path, letter case, trailing slash and query string are all significant, as they are to a search engine. A canonical after the body starts is reported and left out, because Google accepts rel="canonical" only in the head.
hreflang codes are checked against the pattern Google documents — an ISO 639-1 language with an optional ISO 15924 script and ISO 3166-1 region, or x-default — and the set is expected to reference the page itself.
Limitations and methodology
The page is fetched once from the Mutqan server on Cloudflare's network. Sites that vary their HTML by country, cookie or verified crawler IP may show search engines a different canonical.
Only server-sent HTML is read (up to 512 KiB): canonicals inserted by JavaScript are not seen, which is also how many crawlers first see the page.
A canonical is a strong signal, not a rule: the checker shows what the page declares; which URL a search engine finally indexes depends on redirects, internal links and sitemaps as well.
Security and privacy
The page URL (and the canonical URL, when the second request is on) is sent to the Mutqan server, which fetches it with a fixed header set and returns the response. Nothing is stored.
The fetched HTML is parsed as text in your browser and is never rendered or executed, so scripts on the page do not run.
References
- RFC 6596: The Canonical Link RelationDefines rel="canonical": the preferred version of a resource among duplicates, in an HTML link element or an HTTP Link header, and the cases where it must not be used.
- How to Specify a Canonical with rel="canonical" and Other MethodsHow Google chooses a canonical: redirects and rel="canonical" are strong signals, sitemap inclusion a weak one; the link is accepted only in the head, and noindex is not a way to pick a canonical.
- Localized Versions of your Pageshreflang annotations in HTML, HTTP headers and sitemaps: language and region codes, x-default, and why every version must list itself and all the others.