Audit an exact URL variant
Check the parameterized, protocol, host, or path variant that is actually in question instead of assuming every version exposes the same canonical signals.
Canonicalization Checker
Free, no signup. Check the canonical Google can see, the HTTP Link header, and whether the chosen target is actually a clean, live URL.
Checks run from our server; we fetch the URL you enter and don't keep the results. The URL and its canonical target are fetched to build this report. The full URL is not stored; after a successful check, only its domain may be remembered in this browser. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Example result
Illustrative example — fixed signals, not a live URL claim
Page checked: https://example.com/product?color=blue
Observed canonical signals
html canonical: https://example.com/product
Google override-risk predictorLOW — Parameterized page canonicals to a clean URL. Fix: This is usually good when parameters do not change content; ensure internal links and sitemap use the clean URL.
This example assumes the canonical target returns a direct 200. If it redirected or failed, the same engine would add a high-risk finding instead of hiding that evidence.
How to use it
- Enter the exact URL variant you want to audit, including parameters when they are part of the question.
- Choose Audit canonical. The report shows every HTML and HTTP Link-header canonical observed.
- Read the override-risk explanations and fixes, then confirm that the target resolves directly to a live page.
- Use Search Console URL Inspection to compare the user-declared and Google-selected canonical for a verified property.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Observed canonical signals
Google override-risk predictor
This is a deterministic signal check, not a claim about Google’s indexed canonical.
Why these verdicts and how to verify them
Portable baseline
Download this result as JSON, then import it after a later run of the exact same URL. The baseline stays in your files and is not uploaded.
Rate this tool
What the results mean
The report checks the observable signals involved in CanonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. and estimates when conflicts may lead Google to select another URL.
- High marks a direct conflict such as disagreeing canonicals, noindex plus canonical, an unreachable target, or a target that redirects.
- Medium marks a meaningful consistency risk, including cross-domain targets or hreflang that omits the canonical URL.
- Low means the observed signals are internally consistent or describe a normal parameter cleanup. It is not a promise that Google agrees.
How it works
One bounded server request collects the final URL, response headers, and HTML body. A deterministic parser reads canonical and hreflang links from the head plus canonical Link headers, resolves relative URLs, records duplicates and noindex, and then checks each unique canonical target through the status endpoint. The predictor maps those observed signals to explicit risk reasons and fixes.
Features
- HTML and HTTP Link-header canonical discovery.
- Relative, missing, multiple, and conflicting canonical checks.
- Noindex, hreflang, cross-host, protocol, and parameter consistency signals.
- Bounded canonical-target status and redirect verification.
- Plain-language likelihood labels without claiming Google's selection.
Limitations
The checker reads the server response and does not render JavaScript. It cannot compare page content across duplicate URLs, inspect all internal links or sitemap signals, access Search Console, or observe Google's selected canonical. A low-risk result only describes the evidence fetched in this run.
Frequently asked questions
Can this tell me Google’s selected canonical?
No. Google’s selected canonical is only observable through Search Console URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate "Test live URL" mode fetches the current version. for a verified property. This tool predicts override risk from observable HTTP and HTML signals.
Does it fetch rendered JavaScript canonicals?
No. It reads the server response. A canonical injected only after JavaScript runs is discouraged and should be verified in URL Inspection.
Should every indexable page have a self-referencing canonical?
A self-referencing canonical is generally useful because it makes the preferred URL explicit and helps keep parameters or alternate URL forms from becoming ambiguous. It is still a hint, not a directive.
Can a canonical point to a redirect?
It can, but it creates a conflicting and inefficient signal path. Point the canonical directly to the final live 200 URL and align internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., redirects, and sitemap entries with it.
Why might Google ignore a canonical tag?
Google may choose another URL when content, redirects, internal links, sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others., protocol or host signals disagree, or when the declared target is unavailable. This checker tests several observable conflicts but cannot see Google’s full index-level evidence.
Feature requests for Canonical Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Reconcile HTML and HTTP declarations
Compare canonical links found in the server-rendered HTML head with canonical Link response headers and surface declarations that disagree.
Verify the declared target is usable
Follow the canonical target through a bounded status check and catch redirects, errors, or an unreachable destination before treating the declaration as clean.
Triage Google override risk
Turn observed noindex, hreflang, host, protocol, parameter, and target-response evidence into explicit high, medium, or low risk reasons without claiming Google's selected canonical.
Compare a later run with a portable baseline
Download a one-URL JSON baseline, keep it locally, and import it after a later run of the exact same URL to identify changed declarations, targets, or predictions.
Watch the full workflow
Canonicalization Checker walkthrough
Read the transcript
Canonicalization Checker
Hi. Canonicalization Checker helps you understand which page address a website says search engines should prefer. I’ll show you how to check one exact URL, read each warning, verify the destination, and compare a later result with a saved baseline.
Step 1
A canonical is a hint that names the preferred address for a page when similar versions exist. This checker shows the canonical signals in the public server response and tests whether the preferred destination works. It cannot see which URL Google ultimately chose.
Step 2
The common use cases are shown here. Check one exact URL version, compare canonical declarations from two places, test the preferred destination, understand conflicting signals, or compare today’s result with an earlier saved baseline.
Step 3
Enter the exact address you are investigating. Keep anything after the question mark when it matters; those extra pieces are called URL parameters. The checker reads the server response and does not run JavaScript that changes the page later.
Step 4
The fixed example shows a common cleanup pattern. A product URL with a color parameter points to the clean product URL, and that destination returns HTTP 200, meaning the page responded successfully. The low label describes this fictional example, not a live site.
Step 5
For the walkthrough, I’m using a fictional product URL with color and campaign parameters. Its HTML names one preferred product address. An HTTP Link header, which is canonical information sent before the page body, names a slightly different plural address.
Step 6
I’ll choose "Audit canonical." The checker reads the fictional page response, collects its canonical declarations, and checks the first declared destination. The report appears only after that evidence is available, so an unavailable check is not presented as a clean result.
Step 7
Here’s the first important result. The HTML canonical ends in singular trail-runner. The HTTP Link-header canonical ends in plural trail-runners. Because they name different addresses, the tool shows "Signal conflict" instead of silently choosing one for you.
Step 8
The report separates three findings. The two declarations disagree, so that is high risk. The first preferred destination redirects to another page, which is also high risk. Removing tracking parameters can still be a normal low-risk pattern when those parameters do not change the content.
Step 9
High, medium, and low are rule-based consistency labels. They are not percentages, and they do not report what Google indexed. A low result only means the public signals checked in this run did not show a high or medium conflict.
Step 10
Open "Why these verdicts and how to verify them" for the detailed evidence. Each finding keeps the checked page, both canonical declarations, noindex state, and final destination together. It also explains the fix and tells you to rerun the audit to verify the change.
Step 11
A baseline is simply a saved reference result. Choose "Download baseline" to save this one-URL report as a JSON file. The file stays with you; the checker does not upload it or quietly store a copy on the site.
Step 12
Now I’ll choose "Import baseline" and load an earlier clean fictional result for this exact URL. The checker finds five changed categories: canonical declarations, hreflang targets, signal conflicts, destination response, and the override-risk result.
Step 13
The comparison shows when the baseline was created and lists all five changes. It only compares the exact same submitted URL. That protects you from treating a different parameter combination as though it were a newer result for this page.
Step 14
The page defines each severity. High means a direct problem such as conflicting declarations, noindex, a failed destination, or a redirect. Medium means a meaningful consistency concern. Low means the observed signals agree or show a normal cleanup pattern; it is still not Google’s answer.
Step 15
The checker works in two steps. First, it reads the final page address, response headers, and HTML. Then it extracts canonical, hreflang, duplicate, and noindex signals and checks each unique canonical destination before applying the risk rules.
Step 16
The supporting checks cover missing or multiple canonicals, relative URLs, different hosts or protocols, parameters, noindex, and redirects. Hreflang links, which connect language or regional versions, are also checked for consistency with the canonical.
Step 17
The checker does not run JavaScript, compare the actual content of duplicate pages, crawl every internal link or sitemap entry, sign in to Search Console, or see Google’s selected canonical. It reports only the public evidence collected in this run.
Step 18
After you make the public signals agree, open URL Inspection in your verified Google Search Console property. That is where you can compare your declared canonical with the canonical Google selected. This public checker intentionally leaves that private answer to Google.
Choose one preferred URL and make every signal agree.
That’s the complete workflow. Make the canonical declarations agree, point them directly to the intended live page, and run the same URL again after your fix. Use Google Search Console when you need Google’s selected canonical. The checker is free at patrickstox.com slash tools slash canonical-checker.
Common issues & how to fix them
- Warning Canonical is missing Fix: Add one self-referencing absolute canonical URL to the page.
- Error Canonical is relative or invalid Fix: Replace the relative reference with a valid absolute HTTPS URL.
- Error Multiple canonicals conflict Fix: Choose the intended value, align the conflicting signals, and rerun the check.
- Warning Canonical points elsewhere Fix: Point the canonical at the intended preferred URL, or confirm that consolidation is deliberate.
- Error HTML and HTTP canonicals disagree Fix: Choose the intended value, align the conflicting signals, and rerun the check.
- Error Canonical target is not a live 2xx URL Fix: Restore a live 2xx response at the evaluated URL, then rerun the check.