Canonical path trail
Every hop is drawn as a step, so a redirect followed by a canonical followed by another canonical reads as one clear trail instead of scattered values.
Canonical Tag Checker
Paste a URL to see which canonical it declares, whether every signal agrees, and where the canonical actually lands once the target page is followed.
The canonical target is fetched as well, which is how chains and loops surface.
HTML link element, Link response header, and og:url are compared against each other.
- Canonical path shown as one trail.
- Chains, loops, and redirects detected.
- Noindex and header conflicts flagged.
How to check a canonical tag on a page
Enter the URL, read the canonical path, then work through the audit before copying a corrected tag.
- 1
Enter the URL you want to inspect
Use the exact address including any query string, because a parameter version of a page is usually where canonical problems appear. Redirects are followed first, and the report tells you when the URL you entered was not the URL that finally answered.
- 2
Read the canonical path
The path shows each hop as a separate step: the URL you entered, the final URL after redirects, the canonical that page declares, and where that canonical target points next. A healthy page produces a short path that ends on itself.
- 3
Work through the audit groups
Findings are split into how the canonical is declared, how it agrees with other signals, where it points, and which indexing directives apply. Each row explains what a search engine does with the value found rather than only naming the problem.
- 4
Fix and re-check
If the page should be indexed under its own address, copy the self-referencing tag from the signals panel into the head. Deploy the change, then run the URL again to confirm the path now ends on the page itself.
Chain and loop detection
The canonical target is fetched once more, which reveals a page that canonicalises somewhere else again or points straight back at the page you started from.
Header and HTML compared
A canonical declared in the Link response header is read alongside the HTML link element, and any disagreement between the two is reported as an error.
Indexing conflict checks
Robots meta and X-Robots-Tag directives are read too, because a noindex page that still declares a canonical sends search engines two contradictory instructions.
Full signal table
The raw canonical value, its resolved absolute form, og:url, robots directives, tag count, and every hreflang alternate are listed exactly as the page declares them.
Ready self-referencing tag
When the canonical points elsewhere, the report builds the self-referencing link element for the current URL so a correction is one copy away.
Canonical Tag Checker privacy and processing
These notes describe which server performs the two page fetches, how long a report stays in the shared cache, and whether an account is involved in running a check.
Two server-side fetches
A Rune server requests the page, follows redirects, and reads the canonical link element, the canonical Link response header, og:url, and the robots directives. When the canonical names a different URL, that URL is fetched once more to see what it points at.
No stored audits
Reports live in the open tab and in a short shared fetch cache that expires by itself. No checked URL is written to an account, a history list, or a permanent record.
Canonical Tag Checker account access
Running a check, reading the canonical path, and copying a self-referencing tag all work without an account and without any sign-in step.
Before You Use Canonical Tag Checker
Canonical tags are a hint rather than a directive, so a clean report is a strong signal and never a guarantee.
Authority
Google treats a canonical as a suggestion and can still select a different URL as the indexed version.
Internal links, sitemap entries, redirects, and hreflang all feed that decision alongside the tag itself.
Rendering
A canonical injected by client-side JavaScript may not appear in the server response this check reads.
Google can pick up a rendered canonical, but a server-rendered one is far more reliable and easier to audit.
Intent
A canonical pointing away from a page is correct when the page is a genuine duplicate of the target.
The same setup on a unique page quietly removes it from search results, so check intent before changing anything.
Coverage
Only the URL you enter is inspected, so a site-wide problem needs several representative pages checked.
Parameter, pagination, filter, and print versions are the usual places where canonical mistakes hide.
Limits
Canonical Tag Checker inspects one public HTTP or HTTPS page per run and follows the declared canonical a single hop, so deeper chains need a second check on the next URL.
Runs are rate limited per address because each check costs two outbound fetches, and every result is cached briefly so a repeated check can return the earlier read.
Questions about Canonical Tag Checker
What does a canonical tag actually do?
It tells search engines which URL is the preferred version of a page when the same content is reachable at several addresses. Ranking signals from the duplicates are consolidated onto the URL the canonical names.
Should every page have a self-referencing canonical?
Google does not require one, but it is a strong safeguard. A self-referencing canonical protects against parameter versions, session identifiers, and scraped copies quietly competing with the page you actually want indexed.
What is a canonical chain and why does it matter?
A chain is page A naming page B while page B names page C. Google does not reliably follow more than one hop, so the signal can dissolve part way. Point every duplicate straight at the final URL instead.
Can I use a canonical instead of a redirect?
Only when both URLs should stay reachable, such as a filtered version of a category. When one URL has genuinely moved, a 301 redirect is stronger, faster to act on, and unambiguous for both crawlers and visitors.
Why is noindex plus a canonical a problem?
The two instructions contradict each other. Noindex says to drop this page while the canonical says to consolidate it onto another URL. Google warns against the combination because the resulting behaviour is unpredictable.
Does this check read JavaScript-rendered canonicals?
No. The fetch reads the server response only, which is exactly what most crawlers see first. If your canonical appears here as missing but exists in the browser, it is being injected on the client and should be moved server side.
4.3 (659 ratings)