How to Diagnose 'Duplicate Without User-Selected Canonical' in Google Search Console

You open Google Search Console, check Page indexing, and find a URL under Duplicate without user-selected canonical. The page loads. Its content looks fine. You might even have submitted it in your sitemap. So why isn’t that URL indexed?

First inspect the URL in Search Console and find Google-selected canonical. A canonical is the address Google treats as the main version when pages are duplicate or very similar. If it chose the version you want, the excluded duplicate may not need a fix.

This status is not automatically an error. For example, ?utm_source=email and the same page without a tracking parameter often should not both appear separately in search results. The difference matters: you don’t want to “fix” a tracking URL by trying to make Google index it separately.

What the duplicate status means—and when it is normal

Google’s description is specific: it considers the inspected URL a duplicate, the page did not indicate a preferred canonical, and Google selected another URL to represent the content in Search. The inspected version therefore isn’t the one Google serves as the main search result.

That is not automatically a site error. It is a reason to check whether Google made the choice you wanted.

Three related labels are easy to mix up:

This article deals with the middle case. If Search Console shows the third label, start by examining the preference you already declared rather than assuming the page has no canonical.

Start with the inspected URL and Google’s chosen URL

Open URL Inspection for one affected URL. Use the indexed information, not just Test live URL, and record:

• The inspected URL — the address that has the duplicate status.

• User-declared canonical — the preference Google detected, if any. For this status, there may be no declared value.

• Google-selected canonical — the address Google currently treats as representative.

Suppose the inspection says:

Inspected URL:
https://example.com/products/red-shirt?utm_source=email

User-declared canonical:
None

Google-selected canonical:
https://example.com/products/red-shirt

If that parameter only records where the visitor came from, the two URLs lead to the same product. The clean URL is probably the one you want in Search. Google’s selection may be correct; the parameter URL doesn’t need its own ranking.

Now compare a different result:

Inspected URL:
https://example.com/guides/setup-for-teams

Google-selected canonical:
https://example.com/guides/setup-for-individuals

If these guides truly solve different problems, treating one as the duplicate of the other is much more concerning. You need to examine the content and purpose of both pages, not just their tags.

One important limitation: URL Inspection can show Google’s canonical choice from indexed data. A successful live test checks the current page’s accessibility and some indexability conditions, but it cannot predict Google’s future canonical selection. If you changed the page yesterday, those two views can legitimately disagree.

Decide whether Google should show one page or two

Should these URLs represent one page or two separate pages in Search?

This decision avoids a lot of unnecessary SEO work. It leads to four possible outcomes:

A canonical annotation is appropriate for some of these situations, but not all. For example, pointing a genuinely separate guide at another guide would undermine the page you’re trying to make discoverable.

Case 1: A tracking URL is being treated as a duplicate

Imagine a product link in an email includes ?utm_source=email. The product itself hasn’t changed. Google chooses the clean product URL as the canonical.

That’s generally the outcome you want. The indexed address remains predictable, and the marketing parameter can still serve its attribution purpose when someone follows the email link.

You can improve consistency by linking to the clean address internally, listing that URL in the sitemap and declaring the preferred canonical where appropriate. But don’t request indexing for every parameter variant simply because Search Console lists it as excluded.

Be careful about sweeping query-string rules. A parameter that only tracks a campaign is different from one that changes search filters, pagination, language or an important shareable view. Decide what each parameter does before redirecting or canonicalizing it.

Case 2: Google prefers the wrong HTTP or www version

Suppose you want https://example.com/page to represent the content, but Google has selected http://www.example.com/page.

A canonical tag alone may not resolve that contradiction. Inspect the actual redirects and what the site is telling Google elsewhere:

HTTP -> HTTPS redirects
www -> non-www redirects (or the reverse)
HTML rel="canonical" target
Sitemap URL
Internal navigation and article links
TLS certificate and HTTPS health

For example, if the HTTPS page declares an HTTP canonical, the sitemap lists HTTPS, and internal links use both hosts, those signals tell competing stories. Google generally prefers HTTPS, but redirects, canonical annotations and problems with the secure version can affect its choice.

Pick the preferred host and protocol, then make those signals agree. Use a permanent redirect when the alternate host/version doesn’t need to remain independently reachable.

Case 3: An old slug and a new slug display the same page

Consider these addresses:

https://example.com/blog/old-product-guide
https://example.com/blog/current-product-guide

If the first slug is retired and both lead to the same guide, a permanent redirect from old to current is normally cleaner than maintaining two interchangeable pages. Update links and sitemap entries so visitors and crawlers find the current URL directly.

A rel="canonical" link is more useful when a duplicate really must remain available as its own address. It expresses a preference; it doesn’t move the visitor to another URL.

Check that your redirect reaches the intended destination without a loop or an unnecessary chain. A site’s redirect configuration and its canonical declaration should not point in opposite directions.

Case 4: Google groups two pages you intended to keep separate

This is the case that deserves a content review rather than just a technical fix.

Imagine two landing pages both use the same introduction, examples and call to action, with only the headline changed. One says “for teams” and the other says “for individuals,” but their primary content is nearly identical. Google may reasonably treat them as duplicates.

If they really serve different needs, show that difference on the page: use distinct workflows, decisions, examples, constraints and explanations. Titles and headings should reflect genuine differences, not substitute for them. Then make sure each important page is accessible, internally linked and represented consistently.

A self-referencing canonical can express your intended preference, but it cannot create substantive uniqueness where the content does not provide any. Google’s own Page indexing guidance says to make the content differ substantially when you believe the page is not a duplicate.

Canonical signals need to tell one consistent story

Google treats redirects and rel="canonical" declarations as strong preference signals. Sitemap inclusion is weaker. Internal linking, protocol consistency and the pages’ actual content also matter. None of these signals is a command forcing Google to choose the URL you specify.

If two accessible pages should consolidate to one, an HTML page can declare:

<link rel="canonical" href="https://example.com/products/red-shirt" />

Use the complete intended URL. The page you want as canonical should normally declare itself canonical as well. Avoid putting several different canonical declarations on one page or allowing JavaScript, HTTP headers and HTML to disagree about the preferred address.

A quick signal check looks like this:

You don’t have to apply every method to every duplicate. You do need a clear reason for the methods you choose.

How to inspect the page without mistaking signals for Google’s decision

For an affected page, check the final URL after redirects, inspect its HTML source and any relevant HTTP Link header, and compare those values to the canonical selected in Search Console.

The Yoryantra Canonical URL Checker can help compare a page URL with a declared canonical and highlight host, path or query differences. The Redirect Checker can help examine redirect behavior.

Neither tool can tell you which URL Google selected for its index. That decision belongs to Search Console’s indexed URL Inspection data. The useful division of work is:

Search Console:
Which URL did Google choose?

Page/redirect checks:
Which URL does the website actually prefer?

If those answers disagree, investigate why. If they agree, don’t create a new problem just to make an exclusion count smaller.

Three shortcuts that usually send you in the wrong direction

Blocking the duplicate in robots.txt is not a canonicalization method. Google can sometimes know about a blocked URL without being able to inspect its content. Blocking the crawler also makes it harder for Google to see the canonical instruction on that page.

Adding noindex to make Google pick another page isn’t the recommended way to consolidate duplicates within your site. noindex removes a page from search eligibility; it isn’t a substitute for a canonical relationship. Google’s guidance recommends canonical annotations for that purpose.

Requesting indexing repeatedly doesn’t override Google’s canonical choice. A live test that says a page can be indexed is not evidence that Google will select it as the canonical URL after recrawling.

Likewise, the URL removal tool is for hiding content from Search temporarily—not telling Google which duplicate to prefer.

Diagnose one affected URL in five minutes

Take one representative affected URL, especially if a single template has produced dozens of similar exclusions. Then work through these steps:

• Inspect the URL in Search Console and write down the inspected, declared and Google-selected addresses.

• Open the inspected and selected pages. Are their primary content and purpose genuinely the same?

• Decide whether Google’s choice is correct. If it is, no urgent indexing fix may be needed.

• If the choice is wrong, check redirects, canonical declarations, sitemap entries, internal links and host/protocol consistency.

• Choose the fix that matches the relationship: redirect an obsolete URL, canonicalize a necessary alternate, or differentiate pages that should stand alone.

• Verify the live change. Then allow Google time to recrawl and reprocess the signals before judging the new indexed result.

For example, if many excluded URLs only differ by a marketing parameter and Google consistently chooses the clean product pages, the report may be describing healthy consolidation. If many supposedly independent pages all point toward the same selected canonical, inspect the shared template and content rather than fixing one URL at a time.

What to look for after making changes

First check the live site: the redirected URL really redirects, the canonical appears in the response you intended, and the sitemap and internal links don’t contradict it.

Then return to indexed URL Inspection data once Google has had time to recrawl. When you’ve declared a canonical, compare the user-declared value with the Google-selected value. Remember that the selected canonical may take time to reflect changes, and that Google can still choose a different URL.

The goal isn’t to eliminate every Duplicate without user-selected canonical entry. It’s to have the right page represent each piece of content. If Google has already made that choice, leaving the duplicate out of Search may be exactly right.

References

• Google Search Console: Page indexing report

• Google Search Console: URL Inspection tool

• Google Search Central: Canonicalization methods and best practices

• Google Search Central: Canonicalization troubleshooting