Alternate Page With Proper Canonical Tag: Fix It or Ignore It?

"Alternate page with proper canonical tag" means the page has a canonical tag pointing to a different URL, Google accepted it, and that other URL is the one in the index. In most cases this is precisely what you wanted, and Google's own help page says there is nothing to do. It only needs fixing when a page that should be indexed in its own right is canonicalised to something else by mistake.

So this article is mostly about telling the two situations apart quickly.

Reading the status correctly

The name has two parts, and both are good news on their face:

• Alternate page: this URL is a version of another page.
• Proper canonical tag: its canonical correctly points to the main version, and Google indexed that one.

Inspect one of the listed URLs in Search Console and expand Page indexing. You will see:

• User-declared canonical: some other URL
• Google-selected canonical: the same other URL

Your hint and Google's choice agree. Compare that with the two statuses where they do not:

Status	You declared a canonical?	Google agrees?	Action
Alternate page with proper canonical tag	Yes, to another URL	Yes	Usually none
Duplicate without user-selected canonical	No	Google chose for you	Declare one
Duplicate, Google chose different canonical than user	Yes	No	Align your signals

When to ignore it

If the URLs in the list look like these, close the report and do something more useful:

URL type	Example	Canonical points to
Tracking parameters	/pricing?utm_source=newsletter	/pricing
Ad click IDs	/pricing?gclid=abc123	/pricing
Sort and view options	/shoes?sort=price_asc	/shoes
Session IDs	/cart-help?sid=9f2c	/cart-help
AMP versions	/amp/article-name	/article-name
Print views	/article-name?print=1	/article-name
Product variants	/t-shirt?color=blue	/t-shirt
Same product in several categories	/sale/runner-x	/shoes/runner-x
Syndicated copies you host for partners	partner-specific URL	the original

A large number here is not alarming in itself. An online shop with filters will have many times more alternates than indexed pages, and that is the canonical tag doing its job.

When it is a real problem

Open Indexing > Pages, click the status, and scan the example URLs for pages that should rank by themselves. Better still, switch the filter at the top from "All known pages" to "All submitted pages". Your sitemap should contain only canonical URLs, so any alternate page that appears in the submitted view is a contradiction worth looking at: either the sitemap is wrong or the canonical is.

The mistakes I find most often:

A template canonical that is the same on every page

Someone hard codes the tag in a layout file:

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

Every page now claims to be a copy of the homepage. Google often ignores such an obviously wrong hint, but not always, and pages can disappear from the index one by one.

Pagination pointing to page one

<!-- on /blog/page/3 -->
<link rel="canonical" href="https://www.example.com/blog/">

Page 3 is not a duplicate of page 1. It lists different posts. Canonicalising it away can make Google ignore the links on it, which hurts discovery of older content. Each paginated page should canonicalise to itself.

Translations pointing to the original language

<!-- on /de/preise -->
<link rel="canonical" href="https://www.example.com/pricing">

A German page is not a duplicate of the English one. With this tag the German page stays out of the index and your hreflang annotations stop working, since hreflang must reference canonical URLs. Each language version needs a self-referencing canonical. The hreflang checker helps verify the pair.

Near-duplicates that have their own search demand

A shop canonicalises /t-shirt?color=blue to /t-shirt. Fine, unless people search for "blue t-shirt" and the blue variant deserves its own landing page. That is a business decision: if a variant has demand, give it unique content and a self-referencing canonical.

Leftovers from a migration or a staging site

• Canonicals still pointing to the old domain, or to http://, after a move to HTTPS.
• Canonicals pointing to staging.example.com because the staging database was copied to production.
• Canonicals pointing to URLs that now redirect or return 404.

Plugin and CMS settings

SEO plugins let editors set a custom canonical per page. A value pasted in years ago, or copied along with a duplicated page, keeps working silently. In WordPress with Yoast or Rank Math, check the "Advanced" section of the page's SEO box. In Shopify, check how the theme's theme.liquid outputs canonical_url and whether an app overrides it.

Canonical changed by JavaScript

The raw HTML has one canonical and a script rewrites it after load. Google may use either. Compare the page source with the rendered HTML from Test live URL > View tested page. Keep the canonical in the initial HTML and do not modify it with JavaScript.

How to fix the bad cases

1. Find the declared canonical. View the source and search for rel="canonical", and check the response headers for a Link: <...>; rel="canonical" header, since a CDN or server rule can add a second canonical that conflicts with the one in the HTML. The canonical checker shows both at once.
2. Correct it at the source: the template, the plugin field, the CDN rule or the server config. For a page that should be indexed, the tag should be self-referencing:

<!-- on https://www.example.com/blog/page/3 -->
<link rel="canonical" href="https://www.example.com/blog/page/3">

3. Align the supporting signals. Internal links and the sitemap should use the same URL. If the page was the target of a redirect from its own canonical, remove the loop.
4. Test. Inspect the URL, click Test live URL, and confirm the new value under User-declared canonical.
5. Request indexing for the most important pages, and for a large batch use Validate fix on the issue. Google says validation typically takes up to about two weeks and can take much longer.
6. Expect a transition. After recrawling, the page should move to "Indexed". If the content really is a near copy of the old canonical target, Google may still fold them together, and you will see "Duplicate, Google chose different canonical than user". That is a content problem, not a tag problem.

For more than a handful of pages, audit in bulk. Crawl the site with any SEO crawler, export URL and canonical, and filter for rows where the two differ. Then judge each pattern once, not each URL.

Housekeeping that reduces the noise

You do not need to reduce this count, but a few habits keep crawling efficient on larger sites:

• Link to canonical URLs internally. If your navigation links to /shoes?view=grid, you are generating alternates yourself.
• Keep alternates out of the sitemap.
• Do not block alternates in robots.txt to tidy the report. Google cannot read the canonical on a page it cannot fetch, so consolidation stops.
• Do not add noindex to alternates. A canonical says "treat this as that page". A noindex says "drop this page". Sending both is contradictory.
• Strip tracking parameters from internal links. UTM tags belong on links from outside, not on your own menus.
• On large faceted catalogues, where filter combinations run into the millions, canonicals alone will not stop Google crawling them. That needs crawl control, covered in faceted navigation and indexing.

A two minute triage

1. Open the status in Indexing > Pages.
2. Switch to "All submitted pages". If the count drops to zero, you are almost certainly done.
3. If not, export the examples and look at the URL patterns.
4. Parameters, AMP, print, variants: ignore.
5. Clean URLs of real pages: inspect one, read the user-declared canonical, and fix the template or setting that produced it.

If you want the background on how Google chooses between URLs and how strongly each signal counts, read the canonical tags guide. If a page is missing from Google and you are not sure this status is the reason, follow the flow in why is my page not indexed.