How to Check Canonical URLs and Google’s Selected Canonical

Key takeaways

• Read the actual canonical declaration and target.
• Compare pages before assuming they are equivalents.
• Use indexed inspection data for Google’s selected canonical.
• Fix conflicting signals without treating canonical as a command.

To learn how to check canonical URL choices, start with three checks. Read the signal served by the page. Open the target and compare its answer. Then review Google’s selected URL where indexed data is available. Finding a tag alone does not prove the setup is correct. Start with the crawling and indexing guide for the wider process.

This guide checks the main page choice. It helps explain a mismatch. It is not a full audit of duplicate pages. It does not cover every cause of a missing search result.

Define which page should represent the content

Use a focused crawler-access test when a version is blocked. A crawl restriction is not a duplicate-page choice.

Ask the site owner which live address should be the main version and why. Identify the alternate versions under review. A page choice makes sense only when the pages are duplicates or very similar answers, not merely pages that share a keyword.

Record the reader task and key content on each version. Two services in different areas may need distinct pages rather than one preferred target. Do not combine distinct needs just to reduce the number of URLs in a report.

Keep a small list of exact addresses with their expected role. Name the tester and the person who can change the page or template. That turns an unclear warning into a check the team can repeat.

How to check canonical URL output on the page

Use the rendering test when scripts change the head or the answer used in the comparison.

Open the exact live address and inspect its head for a rel=”canonical” link. Also review relevant HTTP headers when the setup uses a header-based signal. Record the target served, not only the value shown in a CMS field.

A simple HTML example is escaped below. It illustrates a signal; it is not markup applied to this article:

<link rel="canonical" href="https://example.com/guides/repair/">

Check whether more than one component writes the signal. A theme and a plugin may produce conflicting targets. If the source and rendered page differ, note both states and ask which code changes the head.

A missing signal is not by itself proof that Google cannot choose a main URL. A clear choice can help align the site. But the check still needs context about the page family and planned target.

Open and review the declared target

Check the target’s indexing instruction rather than assuming that an accessible page is eligible for indexing.

Follow the target address and inspect the route, final page, and key content. Confirm that it is a real live version rather than a staging page, an error response, or an unrelated offer.

Read both answers before accepting the match. A short overview may not preserve the key detail of a long guide. If the target does not serve the same need, return the choice to the owner rather than approving a signal that points to the wrong answer.

Review the target’s own signal too. A target that points elsewhere needs review. Keep what each page says apart from your planned outcome so a chain of inconsistent choices is visible.

Compare Google-selected canonical using indexed data

Follow the URL Inspection workflow for the shown stored note and its limits.

In Search Console, inspect the relevant property and exact URL. In the indexed result, compare the user-declared canonical with Google’s chosen URL when those fields are shown. Note the crawl date and any limit on the data.

The live test answers live access and processing questions. But it cannot predict which URL Google will choose as canonical. Google’s choice is determined during indexing. Do not use a passing live test as confirmation of that future choice.

If the field is missing, state that limit. An absent value in the shown note is not permission to invent the choice. Keep live page notes and Google’s stored data as distinct parts of the review.

Investigate mismatches by checking related signals

Check the sitemap’s main URL set for another signal that may agree or conflict.

Google describes redirects and canonical signals as strong signals, while sitemap inclusion is weaker. Signals can support the same choice or conflict. Review them together without treating a single tag as a binding command.

Check whether internal references and the sent URL set always favor the planned version. Note redirects, indexing restrictions, and differing content that may need another owner. Do not start by removing unrelated pages.

Keep the review scoped to the cause supported by facts. A stale template target needs a template fix. A truly different page may need a different content decision. A report from an old crawl may need a later check after a checked correction.

Example: two article routes disagree about the main version

Imagine a fictional repair guide shown at two live paths. The owner intends the newer route to be the main version, but an old template points one page to a general services page. No traffic loss or ranking outcome is assumed.

The tester records the signals, reads the targets, and checks the indexed stored note. The services page does not provide the guide’s answer, so the team treats that target as a scoped mismatch rather than a valid match.

The developer corrects the relevant output. The tester checks both routes again and records the new state. If Google’s stored choice still reflects an old crawl, they preserve that date instead of making another unsupported change.

Verify changes without mixing up the questions

After release, check the live signal and target. If a shared template changed, check sample pages that use it. Keep the old comparison cases so a correction on one route does not hide a new mismatch elsewhere.

Use a live check for what the page currently serves and indexed inspection data for Google’s recorded choice. Allow for processing differences; do not promise an immediate canonical change or a fixed recovery date.

DEX can help organize page-quality and search review. That does not make a DEX score proof of Google’s chosen URL. The signal, live page behavior, and search-engine note remain distinct checks.

Close the review with a supported next step

Record the planned main page, the found signal, the target check, and the shown Google choice. Assign open conflicts to an owner and state what facts is still missing.

A successful review can end with no change if the setup and found choice match the site’s needs. It can also end with a narrow correction or a documented wait for fresh facts. Avoid changing canonicals repeatedly just because a tool offers a warning without explaining the underlying mismatch.

FAQ

Does a canonical declaration force Google to choose that URL?

+

No. It expresses a preference. Google can choose another representative URL.

Can a live URL Inspection test predict Google’s canonical choice?

+

No. Google-selected canonical is determined during indexing; use indexed inspection data where available.

Is canonical the same as a redirect?

+

No. A declaration can leave both pages accessible. A redirect changes where a request is sent.

Sources

1. Specify a canonical URL · Google Search Central

Dex SEO

Dex SEO is an AI SEO agent for small businesses. Every article here is planned from search data, drafted by Dex, fact-checked against the sources it cites, and reviewed by the team before it is published.

How this article was made: planned and drafted by Dex from search data, fact-checked by Dex (5 claims checked), then approved by the Dex SEO team.