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, external backlinks, or referrer data. Google 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 is reachable, returns 200, is not noindex, and is not itself canonicalized elsewhere — so Google accepted your signal and indexed the canonical version instead.
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 the three closely related GSC statuses 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.
"Duplicate, submitted URL not selected as canonical" — bad. You put the URL in your sitemap (telling Google to index it) but Google decided a different URL is canonical.
"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. Mobile-specific subdomains using rel="alternate" with reciprocal canonicals. AMP pages that canonical to the canonical HTML page. Trailing-slash variants intentionally redirected via canonical rather than 301 (rare but valid). Country/language alternates handled via canonical rather than hreflang in some legacy setups.
If your URLs in this bucket fit any of those patterns, the count being in the hundreds or thousands is normal. A WooCommerce shop with faceted navigation can have 50,000+ 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. Google generally follows one hop and may stop there, leaving B and possibly A in an inconsistent state. Both A and B will appear under "Alternate page with proper canonical tag" — looking correct in summary — but the actual indexing behavior is unpredictable. Always canonical directly to the final destination, never through an intermediate.
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 canonical declaration is technically "proper" from a syntax standpoint, but the target is not indexable. Result: neither the alternate nor the target is in the index. Both pages effectively disappear from search.
If your traffic dropped after a site change and you see a sudden spike in this bucket, one of these three cases is the likely cause. 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.
<!-- 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: { slug: string } }
): Promise<Metadata> {
return {
alternates: {
canonical: `https://example.com/products/${params.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 typically re-evaluates within 1–7 days for high-priority URLs.
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 module already excludes canonicalized-elsewhere URLs by default — if you see them anyway, a custom plugin or theme override is forcing inclusion.
After redeploying the cleaned sitemap, resubmit it in GSC (Indexing > Sitemaps > click the sitemap row > "See page indexing"). Google rereads the sitemap within hours and the affected URLs will gradually shift out of the "Alternate page" report — though they may stay visible for weeks because Google still discovers them through internal links and old crawl history.
Related GSC Canonical Statuses
Three other GSC 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.
"Duplicate, submitted URL not selected as canonical." The URL is in your sitemap but Google chose a different URL as canonical. Fix: either remove this URL from the sitemap (if it is intentionally a duplicate) or fix whatever signal is making Google prefer the other version.
The pattern: "Alternate page with proper canonical tag" means the system worked. The other three mean the system disagreed with you somewhere along the chain. For deeper debugging across all four, see the canonical error fix guide and non-canonical URL fix guide.
Recovery Timeline After Fixes
If you found a real problem and corrected the canonical, here is what to expect:
Immediate (0–24 hours): Your fix is deployed but GSC still shows the old state. URL Inspection on the corrected URL will reflect the fix if you click "Test Live URL" — but the Page Indexing report lags.
Short term (1–7 days): Google recrawls high-priority URLs. URLs you submitted via "Request Indexing" are usually re-evaluated in this window. The affected URLs begin moving out of the "Alternate page" bucket if the canonical now self-references.
Medium term (1–4 weeks): Bulk URLs (parameter variants, paginated pages) get recrawled. The Page Indexing report counts shift visibly. If you cleaned up your sitemap, the "Submitted but not selected as canonical" bucket should drop sharply in this window.
Long term (4–12 weeks): Long-tail URLs that Google rarely crawls finally get re-evaluated. Counts stabilize at the new baseline. If you were fixing a high-impact issue (e.g., Case 1 affecting product pages), organic traffic to recovered URLs typically returns within this window — though if the URLs were noindex-blocked previously, full recovery can take 8–16 weeks as Google rebuilds the ranking signals.
One reliable check: a month after the fix, sample 10 previously affected URLs in URL Inspection. If "Google-selected canonical" now matches your intended URL on all 10, the fix has fully propagated, regardless of what the bucket count looks like.
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.