Canonical URL Checker

Next

Paste any URL and the checker fetches it, looks for the <link rel="canonical"> tag in the HTML head, the Link HTTP header, and reports which canonical Google will see — plus any conflicts, redirect chains or signals that might cause indexing trouble. Runs a short crawl so you can spot problems without digging through the page source yourself.

How the canonical checker works

  1. 1

    Enter a URL

    Any public page. HTTPS and HTTP both accepted; redirects are followed up to 5 hops.

  2. 2

    Page is fetched

    Both HTTP headers and rendered HTML are parsed. Crawler identifies itself as a standard browser UA by default.

  3. 3

    Canonical signals extracted

    All `<link rel="canonical">` tags in `<head>`, any `Link: rel="canonical"` HTTP headers, plus self-referencing vs. external targets.

  4. 4

    Conflicts flagged

    Duplicate tags with different targets, canonical pointing to a redirect, canonical pointing to a noindex page, missing canonical on duplicate content pattern.

What the checker reports

  • Canonical target URL: the href value from the tag or header.
  • Source: HTML tag, HTTP header, or both. If both, must match.
  • Self-referencing?: yes means canonical points back at the page itself. This is normal and safe.
  • Target reachable?: does the canonical URL return 200?
  • Redirect chain on canonical: the target should not redirect.
  • Matching protocol and host: canonical should match the live URL’s scheme.
  • Trailing slash consistency: mismatches cause URLs to be treated as different.
  • Multiple canonical tags: Google uses the first one; extras are warnings.

Common issues the checker catches

Issue Why it matters
Canonical to a 301/302 redirect Google may ignore or downgrade the signal
Canonical to a page blocked by robots.txt Google cannot verify; signal discarded
Canonical to a noindex page Conflicting signals; indexing behaviour unpredictable
Multiple canonical tags with different hrefs Only one is honoured; rest confuse diagnostics
Relative path without base Google resolves relative to current URL — usually fine but not explicit
Canonical to a different language version Should use hreflang instead
HTTP canonical on HTTPS page Signal weaker; Google may ignore
Canonical in <body> instead of <head> Google ignores it

How to fix bad canonicals

  1. Always target the final URL (no redirects).
  2. Match the live protocol and host exactly, including trailing slash.
  3. Place canonical in <head>, not in <body> or injected via JavaScript after render.
  4. One canonical per page — pick one target and stick with it.
  5. For paginated archives, self-canonicalise each page. Do not point all pages at page 1.
  6. For filter/sort variants, point back at the unfiltered list.
  7. Match internal links to the canonical URL — discovering a canonical the rest of the site does not link to dilutes the signal.

What it does not check

  • Whether Google has actually indexed the canonical (use Search Console for that).
  • Whether your internal linking reinforces the canonical.
  • Whether XML sitemap entries match the canonical.

Frequently Asked Questions

Not necessarily. Without a canonical, Google picks one itself based on internal signals (links, sitemap, content similarity). A self-referencing canonical is still best practice to avoid ambiguity, especially on pages with query parameters.

Canonical is a strong hint, not a directive. If Google judges the pages dissimilar, or the canonical is inaccessible, it may pick a different URL. Verify via Search Console’s “URL Inspection” tool for authoritative indexing status.

Duplicate canonical tags in <head> are a bug — some CMS themes add one, plugins add another. Google uses the first; remove the rest. The checker flags all occurrences.

Not directly — it fetches as an unauthenticated client. For gated content, inspect the page source manually after login or use a staging URL with no auth.

Related Tools