Alternate Page With Proper Canonical Tag: What It Means in GSC

You opened the Page Indexing report in Google Search Console, scrolled the "Why pages aren't indexed" list, and saw "Alternate page with proper canonical tag" with a count next to it — sometimes hundreds, sometimes thousands of URLs. The natural reaction is to assume something is broken. In almost every case, it isn't. This status is the healthy outcome of canonicalization working correctly. This guide explains exactly what Google means by this exact phrase, when you can ignore it, and the narrow set of conditions under which it actually represents a problem you need to fix.

What "Alternate Page With Proper Canonical Tag" Actually Means

Decoded into plain English, the status reads: "We found a URL on your site that is a duplicate of another URL. You correctly told us, via a rel="canonical" tag, that the other URL is the canonical version. We agreed with you. We are indexing the canonical version instead of this one."

Three things happened, in order, for a URL to land in this bucket:

1. Google discovered the URL. It found the alternate URL through internal links, the sitemap, or links from other sites, and crawled it.

2. Google identified it as a duplicate. Either through content similarity or because the page declared itself a duplicate via canonical tag, Google determined this URL is not unique content.

3. Google honored your canonical declaration. The canonical tag on the alternate page points to a different URL, that URL returns 200 and can be indexed, and Google’s other signals agreed with your choice — so it indexed the canonical version instead. A canonical tag is a strong hint, not a command.

The word "alternate" in the status name is literal. Google is calling this the alternate version of a canonical page. The alternate is correctly excluded from the index. The canonical version it points to is indexed. Both behaviors are intentional.

Why This Is Usually Good (Not an Error)

Compare it with the other two duplicate statuses in Google’s Page indexing report to see why this one is the desired outcome:

"Duplicate without user-selected canonical" — bad. You did not declare a canonical and Google had to pick one for you. You lost control of the signal.

"Duplicate, Google chose different canonical than user" — bad. You declared a canonical but Google overrode you, indexing a version you did not want.

"Alternate page with proper canonical tag" — good. You declared a canonical, Google agreed, and the canonical version is indexed. The alternate is not in the index — by your design.

Common URL patterns that legitimately end up in this bucket and should stay there:

UTM-tagged URLs (?utm_source=newsletter) that canonical to the clean URL. Print-friendly versions (/page?print=1) that canonical to the article. Sort and filter parameter URLs on category pages that canonical to the base category. Separate mobile URLs (m.example.com) whose canonical points to the desktop page, with rel="alternate" on the desktop page pointing back. AMP pages that canonical to the canonical HTML page. Trailing-slash variants that canonical to the main version instead of redirecting (a 301 is cleaner, but this works).

One pattern that does not belong here: language or country versions. Each should have its own self-referencing canonical and be linked to the others with hreflang; pointing them at one canonical hides all but one language from search. (Search Console’s help notes that alternate language pages aren’t detected for this status at all; Google’s own examples are AMP pages and separate mobile or desktop versions.) And don’t use this bucket for paginated pages: Google’s guidance is that page 2 and beyond each keep their own canonical rather than pointing to page 1.

If your URLs in this bucket fit any of those patterns, the count being in the hundreds or thousands is normal. A store with faceted navigation can have tens of thousands of URLs in this bucket and be perfectly healthy.

When It Actually Is a Problem

The status becomes a problem in three specific cases. None are detectable from the GSC summary alone — you have to inspect a sample of the affected URLs to find them.

Case 1: The canonical points to the wrong URL. Your product page /products/red-sneakers has a canonical pointing to /products/blue-sneakers. Google honors the (incorrect) canonical, leaves the red sneakers page out of the index, and the page never ranks for "red sneakers." This usually happens when a CMS template variable is hardcoded, a duplicate content tool was misconfigured, or a developer copy-pasted a canonical reference without updating the dynamic value.

Case 2: A canonical chain. Page A canonicals to B, B canonicals to C. Canonicals are hints, and a chain weakens the hint: the summary can look fine while Google settles on a URL you didn’t intend. Always point the canonical straight at the final destination, never through an intermediate page.

Case 3: Canonical to a noindex, redirected, or 404 page. The alternate page canonicals to a URL that has <meta name="robots" content="noindex">, returns a 301/302, or returns 404/410. The tag is valid, but it points Google at a URL that can’t be indexed. Google may ignore the hint and pick its own canonical, or neither URL ends up in search. Either way, the page you meant to rank isn’t the one indexed.

If your traffic dropped after a site change and you see a sudden spike in this bucket, check these three cases first. The bucket count alone does not reveal it — you have to inspect URLs.

How to Verify the Status Is Healthy

The fastest verification path is GSC's URL Inspection tool combined with a quick HTML check. From the "Alternate page with proper canonical tag" report:

1. Click into the status to see the affected URL list. 2. Pick a sample URL — ideally one of your most important pages, not a random parameter variant. 3. Click the magnifying glass icon next to the URL to open URL Inspection. 4. Look at the "Indexing" section. You should see: "User-declared canonical" pointing to the URL you intend, and "Google-selected canonical" matching the user-declared canonical. Both fields should agree.

If they disagree, you have a different problem (Case 1 above) — investigate the canonical target. If they agree but you did not expect this URL to be excluded, your CMS is generating a canonical you did not anticipate.

For bulk verification, fetch the canonical tag directly:

# Inspect the canonical tag of an alternate URL
ALTERNATE="https://example.com/category/?sort=price"
curl -sL "$ALTERNATE" | grep -i 'rel="canonical"'
# Expected output:
# <link rel="canonical" href="https://example.com/category/" />

# Now confirm the canonical target is indexable
TARGET="https://example.com/category/"
curl -sIL "$TARGET" | grep -iE 'HTTP/|x-robots-tag'
# Expected: HTTP/2 200, no noindex header

# Confirm no meta robots noindex on the target
curl -sL "$TARGET" | grep -i 'name="robots"'
# Expected: no match, OR a tag without noindex (e.g. index, follow)

If all three checks pass, the status is healthy and you can ignore the URL. If the canonical target returns anything other than 200 with no noindex, you found a real issue.

How to Fix When the Wrong URL Is Canonical

If your inspection turned up Case 1 — the canonical points somewhere wrong — the fix is changing where the canonical points. The mechanics depend on your platform:

Static HTML: Edit the <link rel="canonical"> in the page's <head> directly. Always self-canonical unless you have a specific reason otherwise, and use an absolute URL (https://example.com/page), which Google recommends over a relative path.

<!-- Wrong: canonical points to a different page -->
<link rel="canonical" href="https://example.com/products/blue-sneakers" />

<!-- Right: self-referencing canonical on a unique page -->
<link rel="canonical" href="https://example.com/products/red-sneakers" />

<!-- Right: alternate page canonicalizing to its primary -->
<!-- On URL: /products/red-sneakers?utm_source=newsletter -->
<link rel="canonical" href="https://example.com/products/red-sneakers" />

Next.js App Router: Set alternates.canonical in the page's metadata export. Make sure the value is computed from the route, not hardcoded.

// app/products/[slug]/page.tsx
import type { Metadata } from 'next';

export async function generateMetadata(
  { params }: { params: Promise<{ slug: string }> } // params is a promise in Next.js 15+
): Promise<Metadata> {
  const { slug } = await params;
  return {
    alternates: {
      canonical: `https://example.com/products/${slug}`,
    },
  };
}

WordPress + Yoast: Open the affected post in the editor, scroll to the Yoast meta box, click "Advanced," and clear or correct the "Canonical URL" field. Leaving it blank lets Yoast self-canonical, which is usually correct.

Shopify: Custom canonicals require theme code changes. Edit theme.liquid and ensure the canonical block uses Shopify's {{ canonical_url }} Liquid variable, not a hardcoded value. Removing any custom canonical Liquid restores the default (correct) behavior.

After deployment, request indexing on the corrected URL via GSC URL Inspection > "Request Indexing." Google decides when to recrawl; requesting indexing puts the URL in the queue but doesn’t guarantee a date.

Cleaning Up Your Sitemap to Remove Non-Canonical URLs

Even when the canonical setup is correct, listing alternate URLs in your XML sitemap is a low-grade signal mismatch — you are telling Google "index this" via the sitemap and "don't index this" via the canonical at the same time. Google sides with the canonical, so the alternate stays in the "Alternate page with proper canonical tag" bucket, but you are wasting crawl budget and creating noise in the report.

The clean rule: only canonical URLs belong in your sitemap. Filter your sitemap generator to exclude any URL whose canonical tag points to a different URL.

Here is a Node.js audit script that takes your existing sitemap, fetches each URL, and lists the ones that should be removed because their canonical points elsewhere:

// audit-sitemap-canonicals.mjs
// Usage: node audit-sitemap-canonicals.mjs https://example.com/sitemap.xml

const sitemapUrl = process.argv[2];
const xml = await (await fetch(sitemapUrl)).text();
const urls = [...xml.matchAll(/<loc>([^<]+)<\/loc>/g)].map(m => m[1]);

const toRemove = [];
for (const url of urls) {
  try {
    const html = await (await fetch(url)).text();
    const match = html.match(
      /<link[^>]+rel=["']canonical["'][^>]+href=["']([^"']+)["']/i
    );
    const canonical = match ? match[1] : null;
    if (canonical && canonical !== url) {
      toRemove.push({ sitemap: url, canonical });
    }
  } catch (err) {
    console.error('Failed:', url, err.message);
  }
}

console.log(`Found ${toRemove.length} URLs to remove from sitemap:`);
toRemove.forEach(r =>
  console.log(`  ${r.sitemap}\n    -> canonical: ${r.canonical}`)
);

For Next.js sites using app/sitemap.ts, filter at the source by only emitting routes you intend as canonical. For WordPress with Yoast, the sitemap already leaves out any post whose Yoast "Canonical URL" field points to a different URL (you can see the check in Yoast’s open-source sitemap code). If alternates still show up, the canonical is probably being set somewhere else, such as by the theme or another plugin.

After redeploying the cleaned sitemap, resubmit it in Search Console (Indexing > Sitemaps, enter the sitemap URL, Submit). To track those URLs, click the sitemap row and choose "See page indexing". The affected URLs shift out of the "Alternate page" report gradually, and some stay visible for a long time because Google still finds them through internal links and old crawl history.

Related GSC Canonical Statuses

Two other statuses sit close to this one in the Page indexing report. Mistaking them for "Alternate page with proper canonical tag" — or vice versa — leads to wrong fixes. Here is how each differs:

"Duplicate without user-selected canonical." No canonical tag is present on the alternate page. Google had to guess which URL is canonical. Fix: add a self-referencing canonical to the unique page and a canonical pointing to the primary on each duplicate.

"Duplicate, Google chose different canonical than user." A canonical is present, but Google ignored it. This means Google's signals (internal links, sitemap inclusion, content similarity) outweighed your tag. Fix: align all signals — make sure your internal links point to the URL you want canonical, your sitemap lists it, and the canonical tag matches.

A note on older guides: some still mention "Duplicate, submitted URL not selected as canonical." That name comes from Search Console’s old Coverage report; the current Page indexing report lists the three statuses above. If a sitemap URL is being overridden, you’ll now see it as "Duplicate, Google chose different canonical than user."

The pattern: "Alternate page with proper canonical tag" means the system worked. The other two mean the system disagreed with you somewhere along the chain. For deeper debugging, see the canonical error fix guide and non-canonical URL fix guide.

What Happens After You Fix It

Google doesn’t publish recrawl times, so expect the change to show up in stages rather than on a date:

Right away: URL Inspection’s "Test live URL" shows the corrected canonical, but the Page indexing report still shows the old state; it updates only after Google recrawls.

Important URLs first: pages you submit with "Request indexing" and pages Google crawls often are usually re-evaluated before the rest.

The long tail later: parameter variants and rarely crawled URLs are re-evaluated last, so report counts keep drifting for a while.

The reliable check is the same at any point: sample ten previously affected URLs in URL Inspection. When "Google-selected canonical" matches your intended URL on all ten, the fix has taken hold, whatever the bucket count says.

The Short Answer

"Alternate page with proper canonical tag" in Google Search Console is not an error. It is the report's way of confirming that Google found a duplicate URL on your site, your canonical tag correctly told Google which version to index, and Google honored that signal. The non-canonical URL is intentionally excluded from the index — exactly what you want.

Treat it as a problem only when (1) the canonical points to the wrong URL, (2) you have a canonical chain, or (3) the canonical target is noindex, redirected, or returns a non-200. Verify with URL Inspection. Clean up your XML sitemap to exclude alternate URLs. Otherwise, leave it alone and use the bucket count as a passive health signal — sudden spikes are worth investigating, steady counts are normal.

• Non-Canonical URL Fix
• Canonical Issues: How to Find and Fix Them
• Canonical Tags
• GSC Sitemap Errors