Canonical Tag Checker

1. Enter the address you want to investigate. Include a query string when you are checking a tracking or filter variant.
2. Complete the verification and run the check. The tool makes a public server request; it does not use your signed-in browser session.
3. Compare the declarations. Review the HTML and HTTP-header evidence together. Where target verification is enabled and a single usable destination exists, review that destination’s available response evidence too.
4. Confirm the intended page. Decide whether the declaration matches the page’s purpose, then check important Google-specific questions in Search Console.

For the route a visitor follows between addresses, use the Redirect Checker. A canonical declaration and an HTTP redirect answer different questions.

HTML and HTTP declarations can come from different parts of a website. An SEO plugin may generate one while a CDN or web-server rule supplies another. Fix the configuration responsible for a disagreement, then request the page again.

An alternate address may exist for a useful reason: campaign tracking, an equivalent product route, a printable version or another presentation of substantially the same content. Review those relationships before deciding which URL should represent the content in search.

Different pages can also deserve independent visibility. A category, a detailed product page and a guide may discuss related topics while serving different needs. Pointing them all to a high-priority service page does not create a sound canonical strategy.

For language and regional versions, review the canonical alongside the language-alternate mapping. Use the Hreflang Generator to prepare the relationships you intend to publish, then validate the implementation. Avoid consolidating every translation into one language simply because the pages share a subject.

Where destination checks are available, investigate errors, redirects, indexing restrictions and a destination that declares a further preferred URL. Keep the page you requested, the address that returned content and the declared canonical distinct during review.

You still need to compare the actual content. A successful HTTP response does not establish that two pages are equivalent, that the destination is useful, or that Google will consolidate them.

For a separate review of crawling and indexing directives, use the Indexability Checker. For titles, headings, links and other page-level signals, continue with the SEO Checker.

Start with a written decision: which URL should represent this content, and why? Then locate the setting, template or response rule that generates the current value.

On a WordPress site, check the SEO plugin’s canonical field and any theme output before adding custom markup. In a hosted platform or a framework, review the documented page setting and shared templates. A global configuration change can affect many URLs, so validate representative pages before extending the change.

After the update:

• Request both the preferred page and a relevant alternate again.
• Confirm that declarations agree with the intended URL policy.
• Review internal links, redirects and sitemap entries for consistency.
• Inspect the page’s content and rendered experience.
• Use Search Console’s indexed inspection data when you need Google’s selected canonical.

If the problem spans important templates, markets or commercial pages, request SEO audit services for an agreed investigation and action plan. Share affected URLs, the intended destinations and examples of the conflicting evidence.

The documented checker reads canonical declarations from returned HTML and HTTP headers, preserves declaration evidence, resolves relative destinations and surfaces disagreements. It can report available destination evidence where verification is enabled. Header-based declarations also matter for supported non-HTML resources such as PDFs; reading a header does not mean reading the PDF’s content.

It does not render JavaScript, determine content similarity, inspect your Search Console account, or establish robots.txt access and sitemap membership. A restricted or incomplete response may differ from the page you see in your browser.

Treat the report as evidence from a particular request. Use the Privacy Policy for the site’s data-handling terms, and avoid submitting private or authenticated addresses.

Expanded evidence options: the public-fetch boundary above still applies. The supplied-evidence mode adds HTML/header analysis and optional supplied-DOM comparison; it does not make the checker a browser-rendering service. Exports and repair tasks document a proposed change rather than applying one.