Free tool
Canonical Tag Checker
Confirm which URL a page declares as canonical, and check the page that canonical points at.
The check could not be completed
Canonical check results
The three addresses
A canonical problem is almost always a mismatch between what you asked for, what answered, and what the page names as its preferred URL.
| Address | Value |
|---|
Findings
Every declaration found
| Canonical URL | Found in | Written as |
|---|
The page the canonical points at
| Field | Value |
|---|
rel="canonical" is a hint, not an instruction. A search engine weighs it against redirects, internal links, sitemaps, and the content itself, and it can choose a different URL. This check reports what the page declares and what that declaration points at; it cannot report which URL a search engine settled on.
What This Tool Does
The canonical tag checker reads which URL a page names as its preferred address, and then checks that the naming holds up. It compares three things that are easy to assume are the same and often are not: the address you asked for, the address that actually answered, and the address the page declares as canonical.
When the canonical points somewhere other than the page itself, that destination is fetched once as well, so the check can report whether it works, whether it redirects, and whether it asks to be left out of the index.
How to Use It
Enter one page address and read the three-address table first. Most canonical faults are visible there before you reach the findings.
- Check a page you believe is fine, so you know what a clean result looks like on your site.
- Check a page reachable with a tracking parameter, such as ?utm_source=news, and confirm the canonical still names the clean URL.
- Check page two of a paginated archive, where a canonical pointing back to page one hides the rest of the set.
- Check a page you recently migrated, where a canonical left behind from staging is a common and quiet mistake.
How the Tool Calculates or Retrieves Data
The page is fetched once from this website's server. Redirects are followed, and every hop is validated again before it is requested, so a public address cannot be used to reach a private one. The canonical is read from every link element with rel="canonical" and from the HTTP Link header, and each declaration is recorded with where it was found and whether it was written as an absolute or a relative reference.
A relative reference is resolved against the address that answered, which is how a browser and a crawler resolve it too. If the resulting canonical is a different URL, that URL is validated from scratch and fetched once, and its status, redirect behaviour, robots directives, and own canonical are recorded.
Results are cached for a period the administrator sets, so checking the same page twice in a row does not spend a second request.
Understanding Your Results
A self-referencing canonical is the ordinary case for a page that should be indexed under its own address, and it is what most pages should show. A canonical pointing elsewhere is not automatically wrong: it is exactly right for a duplicate, a parameter variant, or syndicated content whose original lives on another site. It is only wrong when the page it appears on is one you want indexed in its own right.
Two situations are worth treating as urgent. The first is conflicting canonicals, where two different URLs are declared, because a conflict is usually resolved by disregarding both. The second is a canonical whose destination returns an error, redirects, or declares noindex, because the page is then asking to be consolidated into something that cannot hold the ranking.
A missing canonical is a prompt, not a failure. A page reachable at exactly one address does not need one. A page reachable with parameters, with and without a trailing slash, or on both http and https usually does.
Frequently Asked Questions
Not by itself. If a page has exactly one address, nothing needs consolidating. It becomes a problem when the same content is also reachable with a parameter, with a different trailing slash, or on a different protocol, because the search engine then chooses which version to index and it may not choose the one you would.
Yes, and that is the intended pattern for syndicated content: the original publisher keeps the indexed version. On a page you own and want indexed, a cross-domain canonical is nearly always a mistake, and a staging or development hostname left in a template is the most common cause.
Both are valid. Absolute is safer, because a relative reference is resolved against whatever address served the page, so identical markup served at a second address quietly points somewhere else.
Because a canonical is only useful if its destination works. A canonical pointing at a 404, at a redirect, or at a page marked noindex is a common fault that reading the tag alone cannot reveal.