Duplicate & canonical issues

Compare declared and Google-selected canonicals and resolve contradictory consolidation signals.

Directional evidence Automatable now Advanced

Google groups duplicate or very similar pages and chooses one representative URL—the canonical—for indexing and serving. A duplicate exclusion is usually healthy when Google selects the URL you want users to reach. It becomes a problem when Google consolidates an intended page into an unsuitable URL or when the site sends contradictory signals.

A rel="canonical" annotation expresses a preference. It is not a command. Google may select a different canonical after evaluating page similarity, redirects, sitemaps, internal setup, HTTPS, hreflang, content, and other signals.

The three Page Indexing duplicate reasons

Alternate page with proper canonical tag

The URL is a supported alternate, such as an AMP or separate mobile variant, and correctly points to an indexed canonical.

Normal action: None if the canonical is correct and indexed. This status generally means consolidation is working. Google notes that alternate-language pages are not detected by this particular Search Console status.

Duplicate without user-selected canonical

Google considers the URL a duplicate, the site did not declare a preferred canonical, and Google selected another URL.

Normal action: Inspect the Google-selected canonical. If it is the page you would choose, no fix is necessary. If the selection is unsuitable, define and consistently support a preferred canonical.

Duplicate, Google chose different canonical than user

The site declared one URL as canonical, but Google selected a different representative.

Normal action: Compare all three URLs and the signals surrounding them:

The inspected URL.
The user-declared canonical.
The Google-selected canonical.

The mismatch can mean signals conflict, the declared target is not sufficiently similar, the preferred URL is inaccessible or lower quality, or Google's choice is actually more sensible.

Canonicalization is not a duplicate-content penalty

Google says some duplicate content is normal and is not a violation of its spam policies. Common sources include:

HTTP and HTTPS variants.
Hostname and subdomain variants.
Tracking and session parameters.
Sorting and filtering URLs.
Print or file-format versions.
Separate mobile and desktop URLs.
Regional pages with substantially the same primary content.
Staging, demo, preview, or accidental copies.

Canonicalization helps Google avoid showing multiple versions of the same result, consolidate signals, and reduce repeated crawling. The canonical page is normally crawled more often; duplicates are crawled less often.

The objective is not to remove every duplicate reason from Search Console. It is to make the preferred representative clear and keep accidentally public variants from multiplying.

How Google selects a canonical

Google first identifies the primary content of pages, groups pages that appear duplicate or very similar, and selects what its systems consider the most complete and useful representative for Search users.

Google's current documentation describes explicit canonical signals in this order:

Method	Relative influence described by Google	Appropriate use
Permanent redirect	Strong signal	Retire a duplicate URL and send users and crawlers to its replacement
`rel="canonical"` annotation	Strong signal	Keep duplicate URLs accessible while naming a preferred representative
Sitemap inclusion	Weak signal	List preferred canonical URLs at scale

Signals can stack. A redirect, canonical annotation, sitemap, and internal links that all support one URL make the preference clearer than one annotation surrounded by contradictory setup.

Google also describes HTTPS preference, participation in hreflang clusters, and site configuration as canonicalization inputs. None creates an absolute guarantee.

Build a canonical evidence matrix

For each problematic cluster, record:

Evidence	Inspected URL	Declared canonical	Google-selected canonical
Final HTTP status and redirect target
HTML canonical
HTTP `Link` canonical
Robots and indexing directives
Included in canonical sitemap
Internal-link destination
`hreflang` membership and return links
Protocol, hostname, case, and trailing slash
Primary-content similarity
Rendered content and canonical
Accessibility and response stability

This prevents a common diagnostic error: reading the <link rel="canonical"> from one page and assuming the audit is finished.

Inspect the cluster in Search Console

Use URL Inspection on the non-indexed URL:

Expand Page indexing.
Record User-declared canonical.
Record Google-selected canonical.
Inspect the selected canonical separately.
Compare its indexing state and last crawl date.
Run a live test to verify the current response, rendered page, and declared canonical.

The live test checks the current fetchable version but does not calculate a new Google-selected canonical. Canonical selection requires Google's broader indexing systems. A successful live test therefore cannot prove the mismatch is resolved.

Search Console may omit details if the selected canonical is outside a property you can inspect. Performance data is generally attributed to the canonical URL, so a cross-property selection can also explain why the duplicate page appears to have no Performance data.

Why Google may ignore the declared canonical

The pages are not actually duplicates

A canonical target should represent duplicate or very similar primary content. If a product page declares a category page, or a localized article points to a materially different article, Google may reject the relationship.

Choose one of two strategies:

If the pages serve the same purpose, make their relationship and signals consistent.
If both pages deserve indexing, make their primary content and purpose clearly and substantially different, and let each self-canonicalize.

Signals contradict one another

Typical conflicts include:

HTML canonical points to URL A while an HTTP Link header points to URL B.
A URL canonicals to A but permanently redirects to B.
The sitemap lists duplicate variants instead of the preferred URL.
Navigation and contextual links overwhelmingly point to the duplicate.
hreflang references noncanonical or redirecting URLs.
HTTP is declared canonical while all navigation and security signals favor HTTPS.
Mobile and desktop annotations are missing or reversed.
JavaScript changes a server-rendered canonical after load.

Choose one canonical policy and generate every signal from the same source of truth.

The preferred URL is weak or inaccessible

Google can select another version when the declared target:

Redirects unexpectedly.
Returns intermittent 4xx or 5xx responses.
Is blocked from crawling.
Contains noindex.
Has invalid TLS or redirects through HTTP.
Renders incomplete primary content.
Serves an error or soft-404-like state.
Is substantially less complete than the duplicate.

Test the preferred URL independently, not only the duplicate pointing to it.

The site exposes uncontrolled variants

Faceted navigation, case variants, trailing slashes, tracking parameters, print views, and staging hosts can create a noisy cluster. A canonical annotation can help consolidate these URLs, but preventing unnecessary variants from being linked or generated is cleaner.

Audit application routing, templates, sitemap generation, analytics parameters, and absolute URL configuration. Prevent staging and preview systems from becoming publicly crawlable; authentication is safer than relying on a canonical back to production.

Localized pages are configured incorrectly

Google recommends that each localized page have a canonical in the same language, or the closest substitute when one does not exist. hreflang is for language and regional alternates; canonicalization determines duplicate representatives.

Do not canonicalize translated pages to one global-language page merely to simplify indexing. If the primary content is genuinely translated, each language page normally self-canonicalizes and participates in a reciprocal hreflang cluster.

Pages whose header and footer are translated but whose primary body remains the same language can still be treated as duplicates.

Choose the correct consolidation method

Use a permanent redirect when

The old URL has been retired.
Users should never need the duplicate version.
A protocol, host, path, slug, or migration variant has one clear replacement.

Point directly to the final URL and avoid chains. Update internal links and sitemaps rather than relying indefinitely on the redirect.

Use `rel="canonical"` when

Duplicate URLs must remain accessible to users.
Tracking or filter variants serve a legitimate non-search purpose.
Similar HTML pages need a preferred representative.
A non-HTML document needs an HTTP Link canonical.

For HTML, place one valid canonical in the <head> and use an absolute URL. Google recommends a self-referential canonical on the canonical page. For PDFs and other supported non-HTML files, an HTTP Link response header can name the canonical.

Google supports HTML and HTTP-header canonicals, but using both is more error-prone because they can disagree. If both exist, ensure they are identical.

Use sitemap inclusion as reinforcement

List only preferred, indexable canonical URLs. Sitemap inclusion is a weak canonical signal, but it scales and clearly communicates the site's intended inventory.

Do not include URLs that redirect, return errors, contain noindex, or canonicalize elsewhere.

Use consistent internal links

Link directly to the canonical URL throughout navigation, breadcrumbs, pagination, related content, structured data, and content modules. Consistency helps Google understand the preference and prevents users and crawlers from repeatedly passing through variants.

What not to use for canonicalization

robots.txt: Google may index a blocked URL without fetching its content, and cannot see a canonical annotation on a blocked page.
Removal tool: It temporarily hides matching URLs and is not a consolidation mechanism. Google warns it can hide all versions of a URL.
noindex on a duplicate as a substitute for canonicalization: It asks Google to remove that URL from Search rather than consolidate it with a representative. Use the control that matches the intended outcome.
Arbitrary redirects to the homepage: Irrelevant redirects can confuse users and may be treated as soft 404s.
Canonical chains: Point every duplicate directly to the final indexable canonical.
Canonicalizing dissimilar pages: The relationship must make sense based on primary content.

If both pages should be indexed

Canonical annotations cannot make near-identical pages distinct. Google’s current troubleshooting guidance says resolving mistaken clustering technically requires making the pages sufficiently different.

Strengthen differences in:

User intent and task.
Primary information, evidence, data, or product set.
Language or regional substance, not only boilerplate.
Availability, pricing, service, regulations, or local details when legitimately different.
Titles, headings, and internal context as reflections of real content differences.

Remove any canonical pointing one intended page to the other, self-canonicalize each, link to each in the appropriate context, and include both in a canonical sitemap.

Google says a corrected page can remain in a duplicate cluster for up to two weeks while being reevaluated, and pages generally split faster when the difference is clear and significant. That is guidance, not a guaranteed deadline.

Syndicated and copied content

Google's canonical troubleshooting documentation says rel="canonical" is not recommended as the primary way to prevent syndication partners' copies from appearing, because syndicated pages can differ substantially. The most effective solution is for partners to block indexing of the syndicated copy.

If an external copy is selected and you do not control it:

Confirm your original is accessible, complete, and consistently canonicalized.
Maintain clear publication and authorship evidence.
Ask legitimate partners to prevent indexing when that is the agreement.
If content was copied without permission, contact the host and consider Google's copyright removal process.
Check for a compromised site if canonicals or redirects unexpectedly point to spam domains.

Automate a canonical audit

A crawler or script can detect many contradictions at scale. For every intended indexable URL, collect:

Requested and final URL.
Redirect chain and status.
HTML canonical count and target.
HTTP Link canonical target.
Robots meta and X-Robots-Tag.
Sitemap membership.
Inbound internal-link targets.
hreflang targets and return annotations.
Rendered canonical when JavaScript is involved.

Flag:

Multiple canonical annotations.
Relative, malformed, blocked, redirecting, erroring, or noindex targets.
Sitemap URLs canonicalized elsewhere.
Internal links to noncanonical variants.
Different targets across canonical methods.
Canonicals crossing domains unexpectedly.
hreflang targets that are noncanonical.

Automation finds inconsistencies; it cannot decide whether two pages satisfy different user needs. Review content similarity and business intent manually.

Validate and monitor the fix

After correcting the cluster:

Test the duplicate and preferred URL live.
Verify responses, rendered annotations, sitemaps, internal links, and hreflang agree.
Request indexing for only the most important corrected URLs if useful.
Wait for Google to recrawl and reprocess the cluster.
Reinspect both URLs; do not rely on a successful live test as proof of selection.
Monitor the Page Indexing reason and Performance attribution.

Success means the preferred URL is indexed and duplicate variants consolidate as intended. It does not mean every duplicate row disappears from Search Console.