"Alternate Page With Proper Canonical Tag": When to Worry

"Alternate page with proper canonical tag" means Google found a URL that points to a different canonical, agreed with your choice, and indexed the other URL instead. It sits under "Not indexed" in the Page Indexing report, but it is not an error, and for most of the URLs in that bucket there is nothing to do.

There are two cases where it is a real loss of traffic, and Search Console shows both of them exactly the same way it shows the harmless ones. This post is about telling them apart.

What Google actually says, and the part everyone drops

Here is the definition, verbatim from Google's Page Indexing report documentation:

"This page is marked as an alternate of another page (that is, an AMP page with a desktop canonical, or a mobile version of a desktop canonical, or the desktop version of a mobile canonical). This page correctly points to the canonical page, which is indexed, so there is nothing you need to do."

Two things in that sentence are worth slowing down on.

The definition is narrower than the behaviour. Google describes AMP and mobile variants. In practice, Search Console applies this label to any URL that declares a canonical elsewhere and gets Google's agreement: ?sort_by= parameter URLs, page 2 of a paginated archive canonicalised to page 1, WordPress tag and attachment pages, Shopify's /collections/x/products/y duplicates, uppercase and lowercase variants of the same path. None of that is AMP. So most people who look this status up are looking at something the official definition does not describe, which is a plausible reason the search results for it are dominated by people asking each other: as of August 2026, five of the top eight are forum threads.

The reassurance is conditional. Read the clause again: "which is indexed, so there is nothing you need to do." The "nothing to do" depends on the canonical target being in the index. Google states that as an assumption, not as a guarantee, and Search Console does not verify it for you. That single clause is where the second failure case below lives.

The two cases where it is a real problem

Case 1: the alternate was a page you wanted to rank

This is accidental canonicalisation, and it is the case most guides cover. A page you wrote deliberately, with its own purpose and its own target query, is pointing its canonical at something else. Google obeys, indexes the other URL, and your page is quietly out of the running.

The usual sources:

• A hardcoded or templated canonical applied sitewide, so every page in a section points at the section hub.
• A staging or pre-migration canonical left in place, still pointing at the old domain or the old URL structure.
• An SEO plugin setting applied more broadly than intended.
• Paginated pages canonicalised to page 1, taking their unique items out of the index with them.
• Faceted or filtered pages that were genuinely useful landing pages, collapsed into their parent category.

The tell is simple: an important URL, one you can name and describe the purpose of, is sitting in this bucket.

Case 2: the canonical target is not indexed either

This is the one nobody checks, and it is invisible by design.

Note what it is not. The familiar version of "the target is broken" is a canonical pointing at a redirect, a 404, or a noindexed URL, which the canonical tag checker tests directly by fetching each target. This case is worse, because the target is not broken at all. It returns 200, it is crawlable, it carries no noindex, and Google simply did not index it.

Page A declares page B as canonical. Google agrees. Google then declines to index page B, for its own reasons: thin content, low perceived value, or a crawl backlog. Now neither URL is in the index. Nothing appears in search for either.

Search Console's report on page A still reads "alternate page with proper canonical tag", which is technically accurate and completely misleading. The canonical tag is proper. The consolidation worked. It consolidated into nothing.

This case matters most where a lot of URLs consolidate onto a few targets: a large catalogue with variant URLs, a programmatic set canonicalised to hub pages, or a site that recently migrated and canonicalised broadly to a smaller URL set. One unindexed target can take hundreds of alternates out of search with it, and the report will show all of them as fine.

If you find yourself here, the problem is not canonicalisation at all. It is on the target, and it is usually a value or crawl-priority problem: see why pages get crawled but not indexed and discovered, currently not indexed for the fixes that apply to the target URL.

How to tell which one you have

Two questions resolve every URL in the bucket. Ask them in this order.

Did you want this URL indexed?	Is its canonical target indexed?	Verdict
No	Yes	Working as intended. Ignore it.
No	No	The alternate is fine; the target is your problem. Fix the target.
Yes	Yes	Wrong canonical. Make it self-referencing.
Yes	No	Two problems. Fix the canonical first, then the target's indexability.

The second column is the one that gets skipped, and it is the only one Search Console will not answer for you from the report itself. Before you use it, rule out the cheaper failure: if the canonical target redirects, 404s, or carries a noindex, the tag is broken rather than unlucky, and a canonical tag checker that follows each target will find it in one pass.

Why this bucket goes untriaged

The information you need to answer those two questions is not in the report you are looking at.

The Page Indexing report gives you a list of URLs and a last-crawled date. It does not include a column for the canonical target, and it does not include the target's index state. Google's own documentation caps what you can see: "Note that the list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status, even when less than 1,000 items." On a site with 40,000 alternates, you are looking at a sample and you cannot choose which sample.

To resolve even one URL properly you need the URL Inspection Tool, which reports the user-declared canonical and Google's selected canonical, one URL at a time. Programmatically, the URL Inspection API is capped at 2,000 queries per day and 600 per minute for a single property, so a full 1,000-URL export costs half a day's quota and only tells you about the alternates, not about the targets they point to.

So people do one of two things: ignore the bucket entirely because Google said it was fine, or spot-check five URLs and conclude the same. Case 2 survives both.

A triage that fits in an afternoon

You do not need per-URL coverage. Alternates are generated by rules, and rules produce patterns, so a sample per pattern answers for the pattern.

1. Export the bucket. Accept the 1,000-URL cap. You are sampling deliberately now, not pretending to be exhaustive.
2. Group by URL shape. Sort by path prefix and query string. Most buckets collapse to a handful of groups: one parameter, one paginated archive, one duplicate product path, one taxonomy. If a group has no name you can give it, that is a finding on its own.
3. Inspect two or three URLs per group. The user-declared canonical will have the same shape across the whole group, so you learn the rule, not the row.
4. Collect the distinct canonical targets. Usually there are far fewer targets than alternates, which is the entire point of canonicalisation and the reason this step is cheap.
5. Check whether those targets are indexed. This is a bulk index check across a short list, not a per-URL inspection across a long one. A bulk index checker answers it in one pass.
6. Act only on the groups that fail. A group whose targets are all indexed and whose members you never wanted ranking is done. Close it and do not revisit.

Step 2 is what turns an untriageable list into four or five decisions. Step 5 is the one that catches case 2.

How to fix it, and when to leave it alone

If the canonical is wrong (case 1): change the tag on that URL to point at its own address, a self-referencing canonical, using an absolute URL in the <head>:

<link rel="canonical" href="https://example.com/the-page-you-want-indexed" />

Then make the rest of your signals agree, because rel="canonical" is a signal rather than a directive. Google describes it as "a strong signal that the specified URL should become canonical", which means conflicting internal links, sitemap entries, and redirects can still outvote it. Point internal links at the URL you want, include it in the sitemap, exclude the variant, then request indexing.

WordPress, Shopify, and other CMS cases

On a CMS you almost never edit that tag by hand, and the status is usually produced by a rule rather than a mistake:

• WordPress. Yoast, Rank Math, and AIOSEO all canonicalise paginated archives, attachment pages, tag and category variants, and feed URLs to a primary page by design. Override the canonical per-post in the plugin's advanced settings, and only for URLs you actively want ranking. If a whole post type is affected, the cause is a template or plugin default, not the individual posts.
• Shopify. The same product is served at /products/handle and at /collections/name/products/handle, and the theme canonicalises the collection path back to the clean URL. That is correct. The improvement is to stop generating the duplicates: switch theme links off within: current_collection, as covered in Shopify product pages not indexed.
• After a migration. Templates that keep emitting the old URL form will canonicalise your new pages back to a domain or path you no longer use. This one is a genuine emergency, and the migration checklist covers it.

If the target is not indexed (case 2): stop editing canonical tags. The consolidation is working correctly and the target has an indexing problem of its own. Treat it as a normal crawled-but-not-indexed case on the target URL.

If it is genuinely benign: leave it, and specifically do not try to clean up the report count. Two tempting fixes both make things worse:

• Do not noindex the alternates. Google's guidance is explicit: "We don't recommend using noindex to prevent selection of a canonical page within a single site, because it will completely block the page from Search." A noindex on a canonicalised duplicate can be read as applying to the pair rather than consolidating it.
• Do not block them in robots.txt. Google's wording again: "Don't use the robots.txt file for canonicalization purposes. Google may still index URLs that are disallowed in robots.txt without their content." A blocked URL cannot be crawled, so the canonical tag on it cannot be read, and the consolidation you were relying on stops happening.

A large "alternate page with proper canonical tag" count on a site with parameters, pagination, or a product catalogue is not a score to reduce. It is the report telling you the mechanism works.

Where it sits among the other duplicate statuses

Three statuses in the same report describe three different states of agreement between you and Google. They are easy to confuse and they need different responses.

Status	Who declared a canonical	Does Google agree	What it means for you
Alternate page with proper canonical tag	You did	Yes	Google accepted your choice. Verify the target is indexed, then move on.
Duplicate without user-selected canonical	Nobody	Not applicable	Google picked for you. Declare one explicitly if its pick is not the URL you want ranking.
Duplicate, Google chose different canonical than user	You did	No	Google overruled you. Your pages read as more similar than you intended, or your signals contradict your tag.

The third row is the one worth escalating. If you are seeing it alongside the first, your canonical signals are inconsistent rather than merely verbose: Google is reading your tag and then finding your internal links, sitemap, or redirects pointing somewhere else.

Watching it, rather than checking it once

Canonical assignments are not settled. Google re-evaluates them, and a URL can move between these three statuses after a template change, a plugin update, a migration, or a broad quality reassessment. So can the index state of a canonical target: it can be indexed the week you triage and dropped a month later, at which point every alternate pointing at it goes dark with no status change at all and no notification.

That is the practical reason to track index state rather than to read status strings. What you want to know is not "does this URL say it is properly canonicalised" but "is the URL Google actually kept still in the index". SearchOptimo re-checks that on a schedule and alerts you when it changes, which is the moment case 2 becomes visible instead of the quarter later when someone notices the traffic. For the wider workflow, see how to monitor index status at scale, or run your canonical targets through the bulk index checker once to see where you stand today.

Key takeaways

• It is an outcome, not an error. Google found a URL, agreed with its canonical, and indexed the other one. For most URLs in the bucket, nothing to do.
• Google's "nothing you need to do" is conditional on the canonical target being indexed. Search Console does not check that clause for you.
• Two cases are real: a page you wanted to rank is canonicalised elsewhere, or the target it points at is not indexed either, which takes both URLs out of search silently.
• The report cannot answer it. No canonical column, a 1,000-URL example cap, and a 2,000-per-day URL Inspection API quota. Group by URL pattern and sample instead.
• Do not noindex or robots.txt-block properly canonicalised alternates. Google advises against both, and blocking prevents the canonical tag from being read at all.
• A high count is not a problem to reduce. On a site with parameters or pagination, it is evidence the consolidation is working.

Want to know whether the canonical targets on your site are actually in the index? Start a free trial and watch their status over time, or read our honest breakdown of whether automated index monitoring is worth it first.