Alternate Page With Proper Canonical Tag: Fix or Ignore?

"Alternate page with proper canonical tag" is not an error, and in most cases it is Google telling you your setup worked. Google's own description of the status ends with the words "so there is nothing you need to do." The page is a duplicate or a variant, it points at the canonical version with a rel=canonical, Google agreed, and it indexed the canonical instead. That is the system behaving correctly.

The reason it fills up support forums anyway is that Search Console files it under Why pages aren't indexed, next to statuses that genuinely are broken. Seeing 40,000 URLs sitting under a heading about pages not being indexed sets off alarms it was never meant to set off. This article covers what the status actually means, the three specific situations where it does point at a real problem, and how to tell those apart from the ordinary case in about ten minutes.

What does "alternate page with proper canonical tag" mean?

It means Google found a URL that declares another URL as its canonical, checked that the declared canonical is itself indexed, and accepted the arrangement. Google's wording in the Search Console documentation is that the page "correctly points to the canonical page, which is indexed, so there is nothing you need to do."

Three conditions have to hold before a URL lands in this bucket. Google crawled the alternate page. The page carried a rel=canonical tag pointing somewhere else. And the target of that canonical is indexed. If any one of those fails, the URL gets a different status, which is why the neighbouring statuses are the useful comparison:

The middle two rows are the ones worth your attention. Duplicate without user-selected canonical means you left the decision to Google. The third row means you made a decision and Google overruled it. Only the first row is a clean pass.

Is "alternate page with proper canonical tag" an error?

No. It is an informational status describing pages Google deliberately chose not to index because a better version exists and you told it which one. Nothing is wrong, nothing is lost, and the consolidated ranking signals flow to the canonical URL. A site with clean canonicalization and a lot of URL variants should expect this number to be large, and a growing count is usually a sign of growth rather than decay.

The confusion is a reporting artifact. Search Console groups every non-indexed URL under one heading regardless of whether the reason is a problem or a preference, so a correct canonical setup and a server error appear in the same list. Read the status name, not the heading above it.

What causes alternate page with proper canonical tag?

Ordinary site architecture, almost always. The patterns below account for the overwhelming majority of these URLs, and none of them is a defect:

• Product variants. The same shirt in six colors, each on its own URL, all canonicalizing to the main product page.
• Faceted and filtered navigation. Sort orders, price filters and pagination parameters that produce a distinct URL for the same underlying listing.
• Tracking parameters. UTM tags, affiliate IDs and session parameters appended to otherwise identical pages.
• Trailing slash and case variants. Two spellings of the same address that both resolve.
• AMP and mobile versions. The original meaning of the status, and still common on publisher sites.
• Print and syndication views. Alternate renderings of one article.
• Language and region variants that canonicalize to a single primary version.

If you can look at a sample of 20 flagged URLs and place each one in a bucket above, you are done. The status is describing your site accurately and the correct response is to close the tab.

When alternate page with proper canonical tag is actually a problem

There are three cases where this status is a symptom rather than a status, and all three are worth checking before you dismiss it.

The wrong page won. The status confirms a canonical was respected, not that it pointed somewhere sensible. A miswired template can canonicalize every product in a category to the category page, or every paginated result to page one. Search Console reports that as a clean pass, because mechanically it is one. The tell is a page you expect to rank being absent from search entirely. Inspect the URL, read the Google-selected canonical, and confirm it is the page you would have chosen.

The volume does not match the site. A 500-page site reporting 90,000 alternates is generating URLs it does not know about, usually through uncapped filter combinations. Nothing is being indexed incorrectly, but Googlebot is spending its time fetching variants instead of your real pages. That is a crawl budget problem wearing a canonical costume, and the fix is upstream: stop generating the URLs, or block the parameter patterns from being crawled at all.

The count is climbing without a matching release. A steady rise with no new templates or products usually means a parameter loop, a calendar generating infinite dates, or a faceted navigation that can combine filters without limit. Left alone, these grow indefinitely.

How do I fix alternate page with proper canonical tag?

In the normal case you do not fix it, you verify it. The check takes about ten minutes and is worth running once rather than never:

1. Export the URLs from the Page indexing report and group them by pattern. Sorting by the part of the path or query string they share puts them into buckets fast.
2. Sample each bucket. Take two or three URLs per pattern and run them through the URL Inspection tool. You are reading one field: the Google-selected canonical.
3. Confirm the target is the page you want indexed and that it is genuinely in the index. A canonical pointing at a URL that is itself excluded is the failure mode worth catching, because both pages then go missing.
4. Check for canonicals pointing at 404s, redirects or noindexed pages. These are real defects. Google treats a canonical as a strong hint rather than a directive, so a broken target produces unpredictable results.
5. Cap the generators if the volume is disproportionate. Limit filter combinations, strip tracking parameters server-side, and use consistent internal links so you are not minting variants through your own navigation.

On a large site this stops being a manual job quickly. Pulling the declared canonical off every URL in a list is the kind of thing you can hand to a scraper you point at the list and describe the field you want in plain English, then diff the declared canonical against the Google-selected one in a spreadsheet. The gap between those two columns is where the real problems live.

One thing not to do: adding noindex to alternate pages. Google lists using noindex to canonicalize as a mistake, and a noindexed page makes a poor canonical target because the signal you were trying to consolidate has nowhere to land. Let rel=canonical do its job.

Does alternate page with proper canonical tag affect SEO?

Not negatively in the normal case. Canonicalization is how ranking signals from duplicate URLs get consolidated onto one address, so the status describes a mechanism that helps you. The alternate URLs are not competing with the canonical, they are feeding it.

It affects SEO in the abnormal cases described above, and always indirectly. A miswired canonical costs you an indexed page. Runaway URL generation costs you crawl efficiency, which on a large site eventually costs you indexing speed on pages you care about. Both show up as pages missing from search, not as a penalty.

How long does it take for the status to update?

Weeks, typically, and there is no way to force it. Google re-crawls alternate URLs on a low-priority schedule precisely because it has already decided they are duplicates, so a canonical change on a variant page can sit unnoticed for a long time. Google's guidance on revisiting pages after a directive change is that it may take months.

If you have changed a canonical that matters, the practical move is to make the change visible rather than wait for a variant to be re-crawled. Update the internal links so the new target is what your own navigation points at, make sure the canonical target is in your XML sitemap, and request indexing on the target page rather than on the alternates. Then track it, because this is exactly the kind of change that quietly does not take. Watching index status per URL over time is the only way to know whether a canonical change actually landed, which is what the index monitoring side of Indexing is built for.

The short version

Alternate page with proper canonical tag means the duplicate pointed at the right place and Google listened. Google says there is nothing to do, and for most sites that is the correct reading. Spend ten minutes confirming that the canonical targets are the pages you actually want indexed and that the volume is proportionate to your site, then leave it alone. If a page you care about is missing from search, the answer is almost never in this report, and the page indexing report as a whole will point you at the status that does explain it.

Not sure which of your URLs are indexed and which are quietly sitting as alternates? Paste your list into the console at the top of this page. Indexing checks index status across Google and Bing, names the reason for every gap in plain English, and keeps watching so a canonical change that fails to take does not go unnoticed for a quarter.