Alternate Page With Proper Canonical Tag: What It Means and When to Fix It

The short answer

“Alternate page with proper canonical tag” means Google considers this URL an alternate version of another page. The alternate correctly identifies the canonical page, and Google indexes the canonical instead. When that matches your intent, nothing is broken and there is nothing to fix.

Google’s Page indexing report documentation describes this as a correct alternate-to-canonical relationship and says no action is needed. The report is showing that duplicate consolidation worked—not that Google failed to index a page it should have indexed.

Investigate only when the wrong URL is treated as the alternate, the canonical target is not the version you want in search, or the two pages are supposed to be distinct search results.

Click to expand

What “alternate,” “canonical,” and “proper” mean

When Google finds duplicate or very similar pages, it groups them and chooses one representative URL: the canonical. Other URLs in that group are alternates. Google generally shows the canonical in search and consolidates signals from duplicates around it.

The word proper in this status is important. It means the alternate points to the canonical and Google considers that relationship correct. Typical examples include:

• Tracking or campaign parameters that show the same content as a clean URL.
• Print or view variants.
• Mobile or AMP alternates with the intended desktop/non-AMP canonical.
• Product or category URLs reachable through more than one path.
• Protocol, host, case, trailing-slash, or default-document variants that have been intentionally consolidated.

Canonicalization is normal. Google says some duplicate content is expected and is not a violation of its spam policies. See Google’s explanation of canonicalization.

Is it bad?

Canonical tags are strong signals, not commands

The rel="canonical" annotation expresses a preference. Google can choose a different canonical when other evidence is stronger or when the suggested target is not an appropriate duplicate.

Google lists these canonicalization methods in descending strength:

1. Redirects: strong signal.
2. rel="canonical" annotations: strong signal.
3. Sitemap inclusion: weak signal.

Signals can stack. A preferred URL is easier to understand when it self-canonicalizes, receives internal links, appears in the sitemap, and duplicate URLs point or redirect to it. Conflicting signals—such as one canonical in HTML, another in an HTTP header, and a third in the sitemap—make outcomes less predictable.

Google’s complete implementation advice is in How to specify a canonical URL. The standards-level definition of the canonical link relation is RFC 6596.

When no action is required

Leave the status alone when all of the following are true:

• The alternate and canonical have duplicate or very similar primary content.
• The Google-selected canonical is the URL you want shown in search.
• The canonical returns 200 OK, is indexable, and is useful.
• Internal links and the sitemap primarily use the canonical URL.
• Users who need the alternate can still access it, or the alternate redirects appropriately.

You do not need every known URL indexed. Google explicitly says the goal is to index the canonical version of each important page, not all duplicate variants.

When this status needs investigation

1. The alternate URL should actually be canonical

Example: /products/blue-widget/ is the permanent product URL, but the page canonicals to /search?item=blue-widget. Google follows the signal and treats the clean product page as an alternate.

Fix the canonical on both pages, point internal links and the sitemap to the product URL, and redirect the search URL if users do not need it independently.

2. Both URLs should be independent pages

If two pages target different audiences or tasks but share nearly identical primary content, a canonical tag cannot make them both independent. Remove the cross-canonical, give each page a self-canonical, and make the main content meaningfully distinct.

Examples include regional pages with different inventory or regulations, separate products with genuinely different specifications, or documentation for different software versions. Cosmetic title changes are not enough if the body still serves the same need.

3. The canonical target is unusable

A canonical should normally be a relevant, indexable, canonical 200 OK page. Common mistakes include pointing to:

• A 3xx redirect or redirect chain.
• A 404, 410, 5xx, or soft 404 page.
• A URL with noindex.
• A URL blocked from crawling.
• A login page.
• A generic category or homepage that is not a close duplicate.
• A staging, HTTP, wrong-host, or malformed URL.

4. Templates generate the wrong canonical

CMS, ecommerce, and JavaScript frameworks can produce sitewide errors: every page canonicalizes to the homepage, paginated pages point to page one, category filters self-canonicalize unexpectedly, or a staging hostname leaks into production.

Audit representative URLs from every template and deployment environment. Google recommends placing a stable canonical in the HTML source and avoiding JavaScript changes that create ambiguous canonical information.

5. The canonical and other signals disagree

Examples:

• HTML canonical points to URL A, but the HTTP Link header points to URL B.
• The page canonicals to URL A, while the sitemap lists only URL B.
• Navigation links to parameter URLs instead of the preferred clean URL.
• HTTP URLs canonicalize to HTTPS, but internal links and hreflang use HTTP.
• A redirect points one way and the canonical points back.

Consistency does not guarantee Google’s choice, but inconsistency weakens the message.

How to diagnose the status step by step

Step 1: Inspect the alternate URL

In URL Inspection, record:

• User-declared canonical.
• Google-selected canonical.
• Whether the URL is indexed.
• Referring page and sitemap, if shown.
• Last crawl date.
• Whether Google could crawl and render it.

The indexed view—not only the live test—is essential. Google notes that the live test does not test duplicate or canonical conditions and does not show every indexed-state issue.

Step 2: Inspect the canonical URL separately

Do not assume that the target is healthy because its URL appears in the alternate’s report. Inspect it and confirm:

• It is indexed or eligible for indexing.
• It returns 200 OK directly.
• It self-canonicalizes.
• It is not blocked or marked noindex.
• Its rendered main content is complete.
• It is the correct language, region, protocol, host, and path.

Step 3: Compare the two pages

Ask whether they are true duplicates or close substitutes. Compare the rendered main content, not just titles and source-code tokens.

• If they satisfy the same user intent, one canonical is usually correct.
• If users need both but only one should rank, retain the alternate/canonical relationship.
• If they serve different intents, remove the cross-canonical and build clearly distinct pages.
• If the alternate has no independent user need, a redirect may be cleaner.

Step 4: inventory every canonical signal

Check:

• HTML <link rel="canonical">.
• HTTP Link: <...>; rel="canonical" header, if used.
• Redirects.
• XML sitemap entries.
• Internal navigation and contextual links.
• hreflang clusters.
• AMP or separate mobile annotations, where applicable.
• HTTP/HTTPS and www/non-www variants.

Use one canonical implementation method where possible. Google supports HTML and HTTP-header canonicals but warns that using both is more error-prone when they disagree.

Click to expand

How to implement canonicals correctly

HTML pages

Place one absolute canonical link in the valid HTML <head>:

<head>
  <link rel="canonical" href="https://example.com/preferred-page/">
</head>

Add the same self-referential canonical to the preferred page. Google supports relative URLs but recommends absolute URLs to reduce long-term mistakes.

PDFs and other non-HTML files

Use an HTTP Link response header:

Link: <https://example.com/preferred-page/>; rel="canonical"

This approach is defined by RFC 6596 and supported by Google for non-HTML resources.

When to redirect instead

Use a permanent server-side redirect when users do not need the duplicate URL to remain independently accessible—for example, after a site move or when retiring an old path. Google treats permanent redirects as a strong canonical signal. Avoid redirecting unrelated expired pages to the homepage.

Sitemaps and internal links

List only preferred canonical URLs in XML sitemaps. Link to those same preferred URLs in navigation, breadcrumbs, product grids, and article content. A canonical tag should not be used as a permanent cleanup mechanism for internal links you control.

International pages and hreflang

Canonical and hreflang solve different problems. Canonicalization chooses a representative among duplicates; hreflang identifies localized alternatives. Distinct language or regional pages should generally self-canonicalize and reference one another with valid reciprocal hreflang annotations. Do not canonicalize every translation to the English page merely because the layout is similar.

Google notes that alternate language pages are not reported under Alternate page with proper canonical tag, so do not use this row as an hreflang health report.

How to fix an incorrect alternate/canonical relationship

1. Choose the URL that should represent the content in search.

2. Make sure that preferred URL is a useful, indexable 200 OK page.

3. Give it a self-referential canonical.

4. Point true duplicates to it with a consistent rel="canonical", or permanently redirect duplicates that users do not need.

5. Update internal links, sitemaps, hreflang, and other annotations to the preferred URL.

6. Remove conflicting canonicals from HTML, headers, plugins, edge rules, and JavaScript.

7. Inspect both the alternate and preferred URL.

8. Request indexing for a small number of high-priority changed URLs, then allow time for recrawling and reclustering.

Google may need to crawl several members of a duplicate cluster before the report changes. A corrected live tag does not instantly rewrite the indexed canonical selection.

What not to do

• Do not remove a correct canonical merely to make the alternate’s exclusion count smaller.
• Do not use noindex to force Google to choose another canonical within the same site; Google recommends rel="canonical" instead.
• Do not block the alternate in robots.txt before Google can read its canonical.
• Do not canonicalize substantially different pages to one generic page.
• Do not point all expired products, articles, or locations to the homepage.
• Do not put conflicting canonical URLs in HTML, HTTP headers, sitemaps, redirects, and hreflang.
• Do not assume the user-declared canonical is guaranteed to be Google’s selection.

Example diagnosis

An ecommerce product is available at both /shoes/runner-2000/ and /products?id=4821&utm_source=email. Both show the same product. The parameter URL points to the clean product URL with rel="canonical"; the clean URL self-canonicalizes and is indexed.

The parameter URL appears as Alternate page with proper canonical tag. This is correct. The appropriate action is to keep campaign links when needed for measurement, ensure internal navigation and the sitemap use the clean URL, and avoid trying to index the campaign variant.

How BoastIndex helps

Use Google Index Monitoring to watch whether important URLs remain alternates or change status after a canonical fix. Index Status Reports make those shifts easy to share. BoastIndex cannot change Google’s canonical choice.

Authoritative sources and further reading

• Google Search Console: Page indexing report and status definitions
• Google Search Central: What is canonicalization?
• Google Search Central: Specify a canonical URL
• Google Search Central: Fix canonicalization issues
• Google Search Console: URL Inspection tool
• RFC Editor: RFC 6596, The Canonical Link Relation
• IANA: Link Relation Types registry
• Google Search Central: Redirects and Google Search