Alternate Page with Proper Canonical Tag

TL;DR — “Alternate page with proper canonical tag” is a status in Google Search Console that looks scary because it’s filed under “Why pages aren’t indexed” — but it’s not an error. It means the page is a copy or alternate version of another page, and it correctly tells Google to index that other page instead. Google’s own advice is that there’s nothing you need to do. Only worry if a page you wanted in Google is stuck here.

What this status means

When you open the Page Indexing report in Google Search Console, you’ll see a list of reasons pages aren’t indexed. “Alternate page with proper canonical tag” Evidence for this claim Google defines Alternate page with proper canonical tag as an alternate that correctly points to an indexed canonical, requiring no action. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report is one of them — and it’s the one that trips people up, because it sounds like a problem when it usually isn’t.

Here’s what’s actually happening. You have two URLs with the same (or nearly the same) content. One of them — the “alternate” — has a canonical tag that points at the other one, saying “that’s the real version, index that instead of me.” Google looked at it, agreed, indexed the page being pointed to, and filed the alternate here. That’s the expected canonicalization outcome. Evidence for this claim Google uses canonical signals to select a representative URL from duplicate pages. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Canonicalization

Common examples of pages that legitimately end up here — Google’s own definition names the mobile/AMP/desktop pairs specifically, and print or tracking-parameter duplicates show up here too. One exception worth knowing: Google says alternate-language pages aren’t detected under this exact status, even though translated content can still canonicalize elsewhere in the broader system.

• A mobile version (like m.example.com) pointing at the desktop version.
• An AMP or print version pointing at the normal page.
• A URL with tracking parameters (?utm_source=...) pointing at the clean URL.

The thing to understand

This page isn’t broken, blocked, or penalized. It’s a duplicate that’s correctly saying “don’t index me, index the other one” — and Google listened. The content still ranks; it just ranks under the canonical URL, which is what you wanted.

So the panic most people feel when they see a big number here is misplaced. A large count is normal on stores, multilingual sites, and anything with filters or parameters. The number alone doesn’t mean anything is wrong.

When you should actually care

One question sorts it out: are there pages in this bucket that you wanted indexed and ranking?

• No — then ignore it. This is the system working.
• Yes — then something’s off. A page you care about is telling Google to index a different page instead of itself. That’s worth fixing (more in the Advanced tab).

Want the full version — the three canonical statuses side by side, the short list of real problems, and how to check with URL Inspection? Switch to the Advanced tab.

TL;DR — This is the one canonical/duplicate status in the Page Indexing report that’s working as intended — your declared canonical and Google’s chosen canonical agree, and the canonical is indexed. Google’s exact wording is “there is nothing you need to do.” High counts are normal on ecommerce, faceted, parameterized, and multilingual sites — Google publishes no numerical threshold, so triage by which URL patterns and pages are affected, not the raw count. There’s nothing to validate, and per Mueller, no ranking penalty from canonical consolidation itself. The decision gate: are pages you actually wanted indexed sitting here? If no, ignore it. If yes, check declared vs Google-selected canonical in URL Inspection and fix the canonical target. Don’t confuse it with its two siblings — “Duplicate without user-selected canonical” (no canonical declared) and “Duplicate, Google chose different canonical than user” (Google overrode yours) — which do warrant scrutiny.

Start here: this is the happy path

I want to lead with the reassurance because the framing of this status causes more unnecessary anxiety than almost anything else in Search Console. The Page Indexing report files everything under “Why pages aren’t indexed,” and “Alternate page with proper canonical tag” lands in that list right next to genuine errors like server errors and noindex. So people see it, assume it’s broken, and go hunting for a fix.

It isn’t broken. Google’s own definition is about as clear as it gets: Evidence for this claim Google defines Alternate page with proper canonical tag as an alternate that correctly points to an indexed canonical, requiring no action. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report the page “correctly points to the canonical page, which is indexed, so there is nothing you need to do.” That’s the whole status in one sentence. Of all the canonical and duplicate buckets in this report, this is the only one Google describes as fully working as intended.

What’s physically happening: the URL is a duplicate, or an alternate version of another page, and it carries a rel="canonical" pointing at that other page. You declared a canonical; Google agreed with it; Google indexed the canonical and not the alternate. Your signal and Google’s decision agree — there’s no conflict to resolve. The alternate isn’t indexed because its canonical is, and that’s the intended outcome of consolidation.

What an “alternate” page actually is

Canonical declarations are signals Google uses when selecting a representative URL from duplicate pages. Evidence for this claim Google uses canonical signals to select a representative URL from duplicate pages. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Canonicalization

Google’s status-specific definition names a narrow set of examples: an AMP page with a desktop canonical, a mobile version of a desktop canonical, or the desktop version of a mobile canonical. Notably, Google says alternate-language pages are not detected by Search Console under this exact status, even though translated or regional duplicates can still canonicalize elsewhere in the broader canonicalization system.

Beyond those status-specific examples, the broader canonicalization system — the one my deep dive on canonicalization covers — recognizes a wider set of duplicate/alternate patterns that can consolidate via canonical, some of which you’ll also see surface under this GSC status in practice:

• Parameter and faceted URLs — ?color=blue, ?sort=price, session IDs, filter combinations.
• Print versions and other same-content format variants.
• Tag, archive, or pagination pages when their primary content is genuinely the same as (or a close subset of) the page they’d canonicalize to. Google clusters by content similarity, not by URL pattern alone, so don’t assume every paginated or tag page belongs canonicalized to page one — check the actual content overlap first.
• UTM-tagged URLs from campaigns, all pointing back at the clean URL.
• HTTP→HTTPS and trailing-slash / case variants of the same page.

All of these are supposed to consolidate to a canonical when the content really is equivalent. When they show up here correctly, the system is doing its job.

Why high counts are usually fine

The single most common reason people land on this status is a big or growing number, and they assume the size itself is the problem. It usually isn’t. A large ecommerce catalog with faceted navigation, or a multilingual site with country variants, will legitimately produce thousands of alternates — that’s the math of having filters, parameters, and variants. Google publishes no numerical threshold for this bucket — there’s no official count where it flips from “fine” to “a problem.” So don’t triage by raw count at all. Triage by which URL patterns and which specific pages are affected: is this bucket made up of variants you never wanted indexed, or does it include pages you actually cared about? That question tells you more than any number will. (If you want a gut-check heuristic anyway — mine, not Google’s, so treat it as a rule of thumb and not a rule: five thousand alternates on a 300-page site would make me look twice; five thousand on a million-URL store wouldn’t.)

Two related cautions: GSC counts lag and sample, so don’t panic over the raw number on any given day. And on the ranking-penalty question specifically: John Mueller has said there’s no negative ranking impact when Google picks a canonical, and that you shouldn’t lose sleep over the version it chooses. That’s Mueller’s own scoped remark about canonical consolidation — I’m treating it as exactly that, not as a blanket platform-published guarantee — and I’ll keep it as a paraphrase here rather than a quote, because the exact wording comes via secondary coverage.

The three canonical statuses, side by side

This is the distinction that clears up most of the confusion, so it’s worth being precise. There are three related buckets in the Page Indexing report, and they describe three different situations:

The key axis is agreement. With this status, your declared canonical and Google’s chosen canonical line up — no conflict. With Duplicate without user-selected canonical, you gave no signal at all, so Google guessed. With Duplicate, Google chose different canonical than user, you gave a signal and Google disagreed with it — which is the one that genuinely warrants a look, because something is telling Google your declared canonical isn’t the best one (often the two URLs aren’t truly equivalent, or stronger signals like internal links and redirects point elsewhere).

Those two siblings sit right alongside this one in the same report. The diagnosis is different for each, so the first move is always to read which status a URL is actually under before you act.

The decision gate: do you even need to do anything?

Skip straight to one question: are the pages in this bucket ones you actually wanted indexed and ranking?

• No — and this is the common case — ignore it. Making those alternates self-canonical instead would create real duplicate-content problems, splitting signals across URLs you never wanted competing in the first place. There’s also nothing to “Validate Fix” here — it’s a status, not an error — so resubmitting or requesting indexing just fights your own correct canonical.
• Yes — now, and only now, it’s worth debugging. A page you care about is telling Google to index something else instead of itself.

Quick audit workflow (for a large bucket)

Before you inspect URLs one by one, work at the cohort level:

1. Export the URL list from the Page Indexing report for this status.
2. Group by URL pattern — parameters, mobile/AMP pairs, trailing-slash/case variants, pagination, and so on. Most rows collapse into a handful of patterns.
3. Sample a few URLs per pattern and run them through URL Inspection to compare the declared vs. Google-selected canonical.
4. Apply the decision gate per cohort, not per URL: does this pattern include pages you actually wanted indexed?
5. Fix the root cause for any cohort that fails the gate — a template, plugin, or config change — rather than patching individual URLs.

That sequence gets you through a five-figure bucket in minutes instead of URL by URL. The deeper diagnostics below — what “actually a problem” looks like, and the mechanics of URL Inspection — apply once you’ve narrowed to the cohorts worth a closer look.

When it actually is a problem

If a wanted page is stuck here, it’s almost always one of these:

• A wanted page is canonicalized to the wrong page. A mis-set canonical — a template pointing every product at a category, or a page pointing at a near-match that isn’t really the same content. The page you wanted indexed is voluntarily stepping aside.
• The canonical points at a 404, a redirect, or a mismatched page. The target should be a live, 200, genuinely-equivalent URL. If it 404s, redirects, or isn’t actually the same content, the canonical is broken.
• Counts wildly disproportionate to site size, which usually means a structural issue generating alternates you didn’t intend — runaway parameters, an infinite filter space, or a trailing-slash/case inconsistency multiplying URLs.
• A previously-ranking page newly dropped into this bucket alongside a traffic drop — a strong sign a canonical was changed (often by a template or plugin edit) and is now pointing the wrong way.

How to check: URL Inspection

Don’t guess — verify. As I always say about canonicals, your main source of truth for what Google chose is the URL Inspection tool in Google Search Console. Enter the URL and it shows the user-declared canonical (what your page says) next to the Google-selected canonical (what Google actually chose). For a healthy alternate page, both fields point at the same canonical URL. If they diverge — or the declared canonical isn’t the page you expected — that’s your signal to investigate. Run it on a representative sample before you touch anything.

How to fix it — only if needed

Only if the gate above said “yes, a wanted page is here”:

• Correct the canonical target so the page that should rank either self-references (points its canonical at itself) or points at the right equivalent URL.
• Align trailing slash, case, host, and protocol so variants resolve to one consistent canonical (https://, your canonical host, one slash convention).
• Fix hreflang so a country/language variant’s canonical points to a same-language page (or the closest available substitute language) — never across languages. Translated primary content isn’t a duplicate of the original just because the template and navigation are shared; treat it as a duplicate only when the primary content itself is genuinely the same language and substantially the same text.
• Redirect only when you’re actually deprecating a duplicate — a 301 is the right move for a URL that shouldn’t be reachable at all anymore, not a reflex response to Google choosing a different canonical than you declared. Redirecting a page you still want live, just because Google currently prefers another URL, throws away a page you might need.
• Self-canonical the pages that should index, and leave the genuine alternates (parameters, filters, print versions) consolidating where they belong.

How Google chooses a canonical (briefly)

I won’t re-explain the whole selection process here — that lives on the canonicalization hub. The short version: canonicalization is the process search engines use to determine the main version of a URL to index and show when there are duplicates, and Google weighs a large set of signals (around 40) to do it — the canonical tag, redirects, sitemap URLs, internal and external links, hreflang, HTTPS, shorter URLs, and more. The canonical tag is a strong signal but a hint, not a rule — which is exactly why this status is the happy path: Google honored your hint. When it doesn’t, you end up in the “Duplicate, Google chose different canonical than user” bucket instead.

For the mechanics of implementing the tag correctly, see the canonical-tag guide; for the reasons you’re reaching for one in the first place, see duplicate content and URL parameters. The two sibling statuses — duplicate without user-selected canonical and duplicate, Google chose different canonical than user — are the ones to read next if a URL isn’t actually under this status.

AI summary

A condensed take on the Advanced version:

• It’s the happy path, not an error. Filed under “Why pages aren’t indexed,” but it’s the one canonical/duplicate status Google describes as working as intended: the page “correctly points to the canonical page, which is indexed, so there is nothing you need to do.”
• What it is: Google’s status-specific examples are narrow — mobile, AMP, and desktop pairs — and Google says alternate-language pages are not detected under this exact status. In practice you’ll also see broader canonicalization patterns (parameters, filters, print, pagination when content genuinely overlaps, UTM, HTTP/trailing-slash variants) surface here, all declaring a canonical that Google agreed with and indexed instead.
• High counts are usually normal on ecommerce, faceted, parameterized, and multilingual sites — but Google publishes no numerical threshold for this bucket. Triage by which URL patterns and pages are affected, not the raw count. GSC counts also lag/sample — don’t panic on a given day’s number. Per Mueller, no ranking penalty from canonical consolidation itself (a scoped remark, not a platform-published guarantee).
• Three statuses, one axis (agreement): Alternate page w/ proper canonical (you declared, Google agreed — fine) vs Duplicate without user-selected canonical (no declaration, Google picked) vs Duplicate, Google chose different canonical than user (you declared, Google overrode — investigate).
• The decision gate: are pages you actually wanted indexed sitting here? No → ignore (and don’t self-canonical them, that creates duplicate problems; there’s nothing to Validate Fix). Yes → debug.
• Real problems: wanted page canonicalized to the wrong page; canonical points to a 404/redirect/mismatched page; counts wildly disproportionate to site size; a previously-ranking page newly dropped here with a traffic loss.
• Verify with URL Inspection — compare user-declared canonical to Google-selected canonical; for a healthy alternate they match.
• Fix only if needed: correct the canonical target / self-reference, align slash/case/host/protocol, fix hreflang, 301 true duplicates.
• It’s a hint, not a rule — this status means Google honored your hint; the override case is the sibling status instead.

Official documentation

Primary-source documentation from the search engines.

Google

• Page Indexing report — the report itself, including the verbatim definition of “Alternate page with proper canonical tag” and its two sibling duplicate statuses.
• What is URL canonicalization — the concept doc: what a canonical URL is, the “hint, not a rule” line, and the signals Google weighs to choose one.
• Consolidate duplicate URLs (specify a canonical) — how to declare a canonical, and the note that none of the methods are required.
• Fix canonicalization issues (troubleshooting) — decoding the Search Console canonical states, including when Google chooses a different canonical than you declared.
• URL Inspection tool — how to see the user-declared vs Google-selected canonical for any URL.

Bing / Microsoft

• Does Duplicate Content Hurt SEO and AI Search Visibility? (Dec 2025) — Bing doesn’t use Google’s exact label, but treats rel="canonical" as a consolidation/clarity signal the same way; useful context, not a like-for-like report.

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — the status itself (the whole point)

• “This page is marked as an alternate of another page… This page correctly points to the canonical page, which is indexed, so there is nothing you need to do.” — Google Search Console Help, Page Indexing report. Jump to quote

Google — the two sibling statuses, for contrast

• “This page is a duplicate of another page… Google has chosen the other page as the canonical for this page, and so will not serve this page in Search.” (Duplicate without user-selected canonical) Jump to quote
• “This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical.” (Duplicate, Google chose different canonical than user) Jump to quote

Google — why this status is the honored hint

• “indicating a canonical preference is a hint, not a rule.” — Google Search Central docs. Jump to quote
• “While we encourage you to use these methods, none of them are required; your site will likely do just fine without specifying a canonical preference.” Jump to quote

The mental models

1. The three statuses are about agreement. The whole canonical/duplicate cluster in the Page Indexing report collapses to one question — did your declared canonical and Google’s chosen canonical agree?

• They agree → Alternate page with proper canonical tag. Fine.
• You declared nothing, Google picked → Duplicate without user-selected canonical. Check the pick.
• You declared one, Google overrode it → Duplicate, Google chose different canonical than user. Investigate the disagreement. Read which bucket a URL is in before you do anything.

2. The “did you want it indexed?” gate. For this status only one thing decides whether to act: were these pages ones you wanted ranking?

• No → ignore. The system consolidated correctly. (Self-canonicalling them would create duplicate-content problems, and there’s nothing to Validate.)
• Yes → debug the canonical target. A page you care about is stepping aside.

3. Status ≠ error. “Why pages aren’t indexed” is a list of reasons, not a list of problems. Not indexed is the intended state for most alternate URLs. Don’t treat a status as a to-do.

4. Verify, don’t assume. URL Inspection shows declared vs Google-selected canonical side by side. A healthy alternate has them matching. Check a sample before concluding anything from the raw count.

5. Count is relative, not absolute. A big number is meaningful only against site size and whether wanted pages are affected. Thousands of alternates on a faceted/multilingual store is expected; thousands on a tiny site is a structural signal.

”Should I worry about this?” checklist

Run this before you spend any time “fixing” the status:

• Confirm the status. In the Page Indexing report, verify the URL is actually under “Alternate page with proper canonical tag” — not one of the two sibling duplicate statuses, which have different diagnoses.
• Apply the gate. Are any of these pages ones you wanted indexed and ranking? If no → stop here, this is working as intended.
• Sanity-check the count against site size. Is the number proportionate to a faceted/parameterized/multilingual site, or wildly out of scale for how many real pages you have?
• Watch for sudden changes. Did a previously-indexed, traffic-earning page newly drop into this bucket? Pair it with a traffic check.
• Spot-check with URL Inspection. On a sample, does Google-selected canonical match user-declared canonical, and is that target the URL you’d expect?
• Check the canonical target’s health. Does the canonical point to a live 200 page (not a 404, not a redirect) that’s genuinely the same content?
• Only if a wanted page is affected: correct the canonical target / self-reference it; align slash, case, host, and protocol; fix hreflang to a same-language canonical; 301 true duplicates that shouldn’t be reachable.
• Don’t request indexing or hit Validate Fix to force alternates in — there’s nothing to validate, and it fights your own correct canonical.

Should I act on this status?

Walk through this before you touch anything. It’s the same decision gate from the Advanced tab, branched out to the four situations that actually warrant a fix.

The standing KPI: bucket size relative to site size

The raw count under “Alternate page with proper canonical tag” isn’t meaningful on its own — a store with faceted navigation is supposed to generate a large number, and Google publishes no numerical threshold for this bucket either way. What matters more than the ratio is which URL patterns and pages make up the bucket — a pattern and business-intent check catches real problems a pure ratio can miss. The ratio is still a useful trend signal, though: whether the count is growing in proportion with the site or outpacing it.

Alternate-page count as a share of total known URLs

• Metric — The count under this status in the Page Indexing report, tracked as a share of your total known/indexed URLs, checked quarter over quarter.
• What it tells you — Whether the bucket is growing in line with normal site growth (more products, more filter combinations, more locale variants) or outpacing it — which points at a structural issue like runaway parameters, an unbounded filter space, or a trailing-slash/case inconsistency multiplying URLs.
• How to pull it — GSC Page Indexing report, filtered to “Alternate page with proper canonical tag,” noting the count alongside the total Indexed count for the same property. Spot-check individual URLs’ declared canonicals with the Canonical Checker.
• Benchmark / realistic range — Google publishes no numerical threshold here, so don’t treat this as a pass/fail number — track the ratio trend and, more importantly, whether the affected URLs are patterns you expect (variants, filters, locales) or pages you actually wanted indexed. As a rule of thumb of mine, not a Google standard: five thousand alternates on a 300-page site would warrant a look; five thousand on a million-URL store usually wouldn’t. Baseline your own ratio the first time you check, then watch for it widening faster than the site itself is growing.
• Cadence — Quarterly as a standing check; immediately after a migration, template change, or faceted-navigation launch, when the ratio can move fast.

Runbook: a wanted page is stuck in this bucket

You’ve already applied the gate and confirmed a page you care about is sitting under “Alternate page with proper canonical tag.” Work through these in order — stop as soon as one step explains it.

1. Confirm you’re reading the right status. Re-check the Page Indexing report entry for this exact URL. It’s easy to confuse this status with its two siblings — “Duplicate without user-selected canonical” and “Duplicate, Google chose different canonical than user” — and each has a different diagnosis.

2. Compare declared vs. Google-selected canonical. Run the URL through URL Inspection in Search Console (or the Canonical Checker for a quick HTML/HTTP-level read). If the declared canonical isn’t the page itself and isn’t the URL you expected, that’s your answer — go fix the canonical target.

3. Check the canonical target’s health. If the declared canonical points where you expect, confirm the target actually resolves. Trace it with the Redirect Checker or curl -sI: it should be a clean 200, not a 404 or another redirect hop.

4. Check the count against site size. If the target looks fine, ask whether this is one mis-set page or part of a bigger pattern — is the count under this status wildly disproportionate to how many real pages you have? If so, look for a structural cause (parameters, filters, slash/case variants) rather than treating it as a one-off.

5. Check the timeline against traffic. If this page used to rank and only recently fell into this bucket, pull up Performance data for the URL. A drop that lines up with the date it appeared here points at a recent template, plugin, or config change that repointed the canonical.

6. Fix and re-verify. Correct the canonical target (self-reference, or point at the true equivalent), then re-run URL Inspection after Google recrawls to confirm the declared and Google-selected canonical agree again.

Test yourself: alternate page with proper canonical tag

Five questions on this status and how it differs from its siblings in the Page Indexing report.

Bulk-checking canonical targets

Checking one URL is a job for a tool. Confirming that a list of canonical targets all resolve cleanly — instead of quietly 404ing or redirecting — is a distinct, bulk task worth scripting.

Check a single URL’s declared canonical with the Canonical Checker:

1. Paste the URL you’re auditing.
2. Read the reported HTML and HTTP canonical signals, plus the canonical target’s status.
3. Use it to confirm whether a page is self-referencing or pointing elsewhere, and whether that target is actually reachable.

Confirm canonical targets return 200 across a URL list (curl)

macOS / Linux / WSL

#!/usr/bin/env bash
# Reads one URL per line from urls.txt, extracts its declared canonical target,
# then confirms that target returns a clean 200 — not a 404 or another redirect.
while IFS= read -r url; do
  target=$(curl -s "$url" \
    | grep -io '<link[^>]*rel="canonical"[^>]*>' \
    | head -1 \
    | grep -oE 'href="[^"]*"' \
    | cut -d'"' -f2)

  if [ -z "$target" ]; then
    echo "$url -> no canonical tag found"
    continue
  fi

  status=$(curl -s -o /dev/null -w "%{http_code}" "$target")
  echo "$url -> $target [$status]"
done < urls.txt

A clean row looks like https://example.com/page?utm_source=x -> https://example.com/page [200]. Anything ending in 404 means the canonical target is broken; anything in the 3xx range means the canonical points at another redirect instead of the final page — both are worth fixing. This grep-based extraction is a quick heuristic, not a full HTML parser — for anything ambiguous (multiple <link> tags, JS-injected canonicals), confirm with the Canonical Checker or URL Inspection instead of trusting the script blind.

Tools for inspecting and fixing this status

• Canonical Checker — audits HTML and HTTP canonical signals for a URL, checks whether the canonical target actually resolves, and explains signals that could cause Google to pick a different canonical than the one declared.
• Redirect Checker — traces a canonical target (or any URL) and reports the final status and every hop, so you can catch a canonical pointing at a redirect chain instead of a clean 200.
• Google Index Checker — checks observable indexability signals (redirects, noindex, canonical hints) for a URL; useful for a quick sanity check, though it can’t see Google’s actual selected canonical — that’s URL Inspection’s job.
• Indexation Reconciler — joins sitemap, fetched, canonical, redirect, and GSC Page Indexing evidence in one table, useful for spotting a disproportionate alternate-page count across many URLs at once.
• URL Inspection (Google Search Console) — the primary source of truth: shows the user-declared canonical next to the Google-selected canonical for any URL.

Common issues when a wanted page is stuck here

Four independent symptom-cause-fix cards for the situations that actually turn this status into a real problem.

A wanted page’s canonical points at the wrong page

Symptom: A page you care about shows “Alternate page with proper canonical tag,” but the declared canonical isn’t itself and isn’t the URL you expected.

Likely cause(s): A mis-set canonical — often a template pointing every item at a category page, or a canonical pointing at a near-match that isn’t really the same content.

Fix + check: Correct the canonical to self-reference (if the page should rank on its own) or point at the genuinely equivalent URL. Confirm with URL Inspection after Google recrawls that the Google-selected canonical now matches.

The canonical target 404s, redirects, or doesn’t match

Symptom: The declared canonical target is right in principle, but visiting it returns a 404, another redirect, or content that isn’t actually the same page.

Likely cause(s): The target page was removed, moved, or renamed without updating the canonical tags pointing at it.

Fix + check: Point the canonical at a live 200 page that’s genuinely equivalent content. Trace the target with the Redirect Checker or curl -sI to confirm it resolves cleanly with no further hops.

The count is wildly disproportionate to site size

Symptom: The number of URLs under this status keeps climbing and looks far too large for how many real pages the site has.

Likely cause(s): A structural issue generating alternates you didn’t intend — runaway parameters, an unbounded filter combination space, or a trailing-slash, case, or protocol inconsistency multiplying the same URL.

Fix + check: Identify and cap the URL-generating pattern (parameter handling, filter limits, one consistent slash/case/protocol). Re-check the count against total known URLs a few weeks later to confirm it’s leveled off.

A previously-ranking page just fell into this bucket, with a traffic drop

Symptom: A page that used to be indexed and ranking is now showing “Alternate page with proper canonical tag,” and its traffic has dropped.

Likely cause(s): A recent template, plugin, or config change repointed the page’s canonical at a different URL — often unintentionally.

Fix + check: Find what changed around the date the status appeared (deploys, plugin updates, template edits) and correct the canonical back to the page itself. Re-verify with URL Inspection and watch Performance data for recovery.

Prove a canonical fix actually took

Once you’ve corrected a mis-set canonical target, these are the checks that confirm Google actually picked it up — not just that the HTML changed.

Test 1 — The declared canonical now points where you intended

• Test to run — Run the URL through the Canonical Checker (or view source / curl -s and look at the <link rel="canonical"> tag).
• Expected result — The declared canonical is the page itself (if it should rank on its own) or the genuinely equivalent URL you intended.
• Failure interpretation — If the declared canonical still shows the old target, the fix didn’t deploy, was cached, or was overwritten by a template that still points the wrong way.
• Monitoring window — Immediate — the HTML response reflects the change as soon as it’s live and any cache clears.
• Rollback trigger — Not applicable at this step — don’t move to Test 2 until the declared canonical itself is correct.

Test 2 — The canonical target resolves cleanly

• Test to run — Trace the new canonical target with the Redirect Checker or curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" <target-url>.
• Expected result — A single-hop 200 on the exact URL you canonicalized to — no redirect chain, no 404.
• Failure interpretation — A 404 means the target doesn’t exist; a 3xx means you canonicalized to another redirect instead of the final page — point the canonical at the resolved destination instead.
• Monitoring window — Immediate.
• Rollback trigger — Target doesn’t resolve to 200 — fix the target before checking Google’s side at all.

Test 3 — Google’s selected canonical now matches your declared canonical

• Test to run — Run URL Inspection in Google Search Console on the fixed URL.
• Expected result — The Google-selected canonical field matches your user-declared canonical field, and the status under Page Indexing reflects the corrected relationship (self-indexed, or a clean alternate pointing at the right page).
• Failure interpretation — If Google-selected still shows the old target after a recrawl, a conflicting signal — internal links, sitemap entries, or a redirect — is still pointing the old way and needs to be aligned too.
• Monitoring window — Days to a few weeks, depending on how often Google recrawls the URL; request a recrawl via URL Inspection to speed up the check rather than waiting passively.
• Rollback trigger — Don’t abort and revert the canonical fix just because Google hasn’t recrawled yet — that’s expected lag, not failure. Only reconsider the fix itself if Google-selected still disagrees weeks after a confirmed recrawl.

Alternate page with proper canonical tag

A Google Search Console Page Indexing status meaning a page is a duplicate or alternate version that correctly points its canonical at another, indexed page. It's normal, healthy behavior — Google says there is nothing you need to do.

Parent concept: Canonicalization · Related: Duplicate Content, Canonical Tag, Canonicalization

Alternate page with proper canonical tag

“Alternate page with proper canonical tag” is a status in Google Search Console’s Page Indexing report. It’s listed under “Why pages aren’t indexed,” but unlike most statuses in that list it’s working exactly as intended and usually needs no action.

It means the URL is a duplicate — or an alternate version like a mobile, AMP, or print variant — of another page, and it correctly points its rel="canonical" at that other page, which Google has indexed. (Google says alternate-language pages specifically aren’t detected under this status, even though language duplicates can canonicalize elsewhere in the broader system.) Because the canonical is the one indexed and served in Search, Google doesn’t separately index the alternate. That’s the outcome you want.

People routinely panic when they see thousands of pages bucketed here, but in the large majority of cases it’s healthy site behavior, not an error. Google’s own line is that the page “correctly points to the canonical page, which is indexed, so there is nothing you need to do.”

The only time it’s worth investigating is when a page you actually wanted indexed has landed in this bucket — which means its canonical is pointing somewhere it shouldn’t.

Parent concept: Canonicalization · Related: Duplicate Content, Canonical Tag, Canonicalization

Changelog