Canonical tag checker

Start with the URL that should appear in search

Write down the exact public page address before looking at any tags. Include HTTPS, the preferred hostname and the intended path. For example, the preferred address for a fictional repair guide might be https://example.com/guides/puncture-repair. That is different from the homepage, a preview deployment, the same route with a trailing slash, or a link carrying a campaign parameter. The checker compares against your decision; it cannot decide which page deserves to be indexed.

A canonical declaration expresses which version represents duplicate or very similar content. It is not a shortcut for ranking every page under the homepage. If a service page explains a distinct service, it usually needs its own preferred address. Pointing that page to home can tell a search engine that the service page should be consolidated away. First decide whether the two pages answer the same need, then choose the destination.

Collect a complete, reproducible HTML sample

Open the public page in a private browser window and use View Page Source. Copy the document, including the complete head, into the checker. Keep the page address and collection date beside the result. A copied fragment with no canonical is only evidence about that fragment. It does not establish that the live document lacks a canonical, and it does not include HTTP response headers.

The tool parses HTML as data. It lists canonical link elements in the head, counts duplicates and compares absolute destinations with the URL you entered. Scripts and embedded resources are not executed or fetched. Results remain in the page's memory and disappear when you reload. If you only have confidential application HTML, remove private data before sharing the result with another person; the checker itself does not upload the sample.

Read the findings without turning them into a ranking score

One declaration that matches your preferred address is a useful configuration check. It does not prove that the destination returns a successful response, that its content matches this page, or that Google selected it. Open that destination separately. Follow any redirects and make sure the final page is public, useful and intended for indexing. If the canonical points through a redirect, update the declaration to the final preferred address.

Multiple declarations deserve a source review even when their values match. A shared layout and a page component may both emit the tag. Keep one clear owner for the declaration so a later edit cannot make them disagree. For a relative value, the checker intentionally asks for review instead of resolving it against a guessed base. Check the document base and publish an absolute destination so the same page remains clear on every host.

A worked example: the homepage canonical leaked into a guide

Suppose a fictional site has /, /pricing and /guides/first-launch. All three return useful, different content, but each head contains a canonical for the homepage. Inspecting only home would miss the defect. Copy the guide's source, enter the guide's full preferred address, and run the checker. The mismatch identifies a concrete question: does the shared layout hardcode the homepage, or does a page override fail to reach the server response?

Repair the source that owns the tag. Give each public route its intended absolute URL and remove the competing declaration. Publish the change, then fetch the same three routes again. The guide should point to itself, pricing should point to pricing and home should point to home. Record the before and after values. This is an illustrative repair procedure, not a report about a customer site or a promise that its ranking will improve.

Check hosts, slashes and links together

A custom domain can coexist with a hosting-provider subdomain or a preview deployment. Decide which is the public home of the product. Point internal links, sitemap entries and canonical declarations at that same origin. Where you control an old public host that has been permanently replaced, a permanent redirect to the corresponding new path gives visitors a clear route too. Do not redirect every old deep link to home; preserve the matching content when it exists.

Test the slash variant deliberately. If /guide is preferred, open /guide/ and observe its actual response. A consistent redirect policy is easier to maintain than two independently served copies. Also inspect query-string links used in campaigns: they may load the same page while the canonical names its clean URL. Do not remove meaningful parameters from a page whose content genuinely changes with them without considering what visitors need.

Compare with Search Console after publication

In URL Inspection, compare the user-declared canonical with Google's selected canonical when the indexed record provides those fields. Keep the date of that record in mind. It may describe an older crawl, while the page you just fetched contains the new value. The live test answers a current accessibility question; it does not replace the indexed record or guarantee which URL Google will eventually choose.

If the selections differ, review the content relationship, redirect chain, internal links and sitemap together. A canonical is one signal among several, and Google can choose another version. Repeatedly requesting indexing of an unchanged page does not resolve contradictory signals. Fix the observed inconsistency, submit the preferred URL once when appropriate, and check the record again after a new crawl. Keep ranking changes separate from these configuration checks.

When to stop using this checker

This tool is finished when you have an accurate record of the supplied tags and a specific next action. Use a full crawl to find site-wide duplicates, an HTTP client to inspect headers and redirects, and Search Console for Google's indexing evidence. For JavaScript-dependent pages, compare the initial response with the rendered browser head as well. An ordinary static fetch may differ from the response served to a verified crawler on some hosting setups.

Keep a small evidence log: page URL, preferred URL, observed declaration, response status, change made, publication date and next inspection date. That log is more useful than a single pass badge. It lets you explain what was fixed, catch regressions after a template change and avoid treating every missing search result as a canonical problem.

Sources and further reading

• Google: consolidate duplicate URLs
• Lovable: SEO and AI search