How to Fix 'Alternate page with proper canonical tag' in Search Console

What does “Alternate page with proper canonical tag” mean in Search Console?

“Alternate page with proper canonical tag” is a not-indexed status in the Page Indexing report that means Google found this URL, saw that it points to another page as its canonical, and indexed that canonical instead — so the alternate itself is intentionally left out of the index. Google’s own definition is narrow: the page is “an AMP page with a desktop canonical, or a mobile version of a desktop canonical, or the desktop version of a mobile canonical,” it “correctly points to the canonical page, which is indexed, so there is nothing you need to do.” The status name is the reassurance: proper canonical tag means Google is telling you the tag did its job. In the overwhelming majority of cases this is a healthy status, not an error — the one exception is when a page you wanted indexed on its own lands here because something stamped the wrong canonical on it.

I do both sides of this — I write the code and I run the SEO — and this is one of the Search Console statuses people panic about for no reason, then ignore in the one case where it actually costs them a page. The status is benign by definition. Google only files a URL here when the canonical relationship is working as intended. So the real question is never “how do I fix this status” — it is “did I intend this page to be an alternate?” This piece walks through the exact definition, the cases where you leave it alone, the narrow case where it signals a real problem, and how to tell the two apart in Search Console without guessing.

TL;DR — Key takeaways

• The status is not an error. It lives under the not indexed reasons in the Page Indexing report, and Google is explicit that these pages are not indexed “not necessarily because of an error.” A page marked alternate is usually a good sign — it means Google found the canonical and indexed it.

• It means “canonical received and honoured.” The URL declares another page as canonical (or is an AMP/mobile variant of one), Google agreed, and it indexed the canonical in this page’s place. “Proper canonical tag” is Google confirming the tag is valid and pointing at an indexed page.

• It is not the cross-language canonical bug. Google states plainly that “alternate language pages are not detected by Search Console.” If a translated page is being dropped, it surfaces under a Duplicate status — not this one. Do not diagnose an hreflang problem from this label.

• Leave it alone if the alternate is intentional. Separate mobile URLs (an m-dot site), AMP variants, and print/parameter versions that canonicalise to a main page are supposed to sit here. There is nothing to fix.

• It’s only a problem when a page you wanted indexed lands here. That means something applied a canonical you didn’t intend — usually a CMS or plugin stamping the wrong canonical. The fix is to correct the tag so the page self-canonicals, then wait.

• Confirm before you touch anything. Inspect the URL and read the Google-selected canonical field. If it’s the URL you expect, you’re done. If it’s a surprise, you have a misapplied canonical to chase.

The status decoded: alternate, canonical, and “proper”

Three words, three separate claims, and understanding each one tells you whether to act.

“Alternate” means Google is treating this URL as a secondary version of another page, not as its own indexable entry. Per Google’s Page Indexing documentation, the relationships that trigger this specific status are narrow: an AMP page whose canonical is the desktop page, a mobile-specific URL whose canonical is the desktop page, or the reverse. These are structural variants of one piece of content — the kind of setup where you want one URL in the index and the others deferring to it.

“Canonical tag” means the deferral is happening through an explicit signal — a rel="canonical" annotation (or an AMP/mobile alternate link) that names the preferred URL. Google treats rel="canonical" as a strong signal, second only to redirects and well above sitemap inclusion, so when a page carries one pointing elsewhere, Google usually honours it.

“Proper” is the part people skim past. Google is confirming the canonical target is valid and indexed. Contrast this with the adjacent status, Duplicate, Google chose different canonical than user, which means Google overrode your declared canonical because it thought a different URL was the better one. “Proper canonical tag” is the opposite outcome: your declaration was accepted. That single word is why this status needs no action in the normal case — Google is telling you it agreed with you.

When to leave it alone (the benign, majority case)

Most of the time this status is a report of success, and touching it would break a working setup. Leave it alone when the alternate is one you built on purpose:

• Separate mobile URLs. If you run an m-dot site (m.example.com), each mobile URL canonicalises to its desktop twin, and Google indexes the desktop version while filing the mobile URL here. Exactly as designed.

• AMP pages. An AMP variant whose canonical is the non-AMP page will sit under this status. Google’s URL Inspection guidance says outright that for an AMP alternate “generally there is nothing to do.”

• Print, parameter, and near-duplicate variants. A ?print=1 copy or a filtered/sorted parameter URL that canonicalises to the clean page is a duplicate you want consolidated. The status confirms the consolidation took.

The governing principle from Google is that your goal is to get the canonical version of every important page indexed — duplicate and alternate pages shouldn’t be indexed. A URL in this status is one Google deliberately kept out of the index in favour of the page you preferred. If that URL was never meant to rank on its own, the correct number of changes to make is zero.

One practical filter before you spend any time here at all: if your site has fewer than 500 pages, Google says you probably don’t need the Page Indexing report — a quick site: search for your key URLs tells you what’s indexed faster than reading status counts.

When it’s actually a problem

There is exactly one scenario worth your attention: a page you expected to be indexed on its own has landed in this status. That means a canonical is pointing away from it that you never intended to set. The usual culprit, straight from Google’s canonicalization troubleshooting guide, is a CMS or plugin making “incorrect use of canonicalization techniques to point to undesired URLs” — a theme that stamps a site-wide canonical from one template onto every page, so unique pages inherit a canonical to the homepage or a category hub.

The tell is a mismatch between intent and outcome: you wrote a distinct article, but Search Console is treating it as an alternate of something else. When that happens, the page never gets its own listing, and the traffic you built it for goes to the canonical instead.

Two honest caveats keep you from chasing the wrong bug:

• This is not where cross-language problems appear. If a translated page is being dropped in favour of the original language, that is a Duplicate status, because alternate language pages are not detected by Search Console under this label. The interaction between hreflang and canonical tags is a separate problem with its own failure modes — don’t diagnose it from here.

• Check whether you’re really looking at a Duplicate status instead. The genuinely damaging cases — a unique page with no self-canonical, or one where Google overrode your choice — usually file under Duplicate without user-selected canonical (“Google has chosen the other page as the canonical for this page, and so will not serve this page in Search”) or Duplicate, Google chose different canonical than user. These sit right next to “Alternate page with proper canonical tag” in the report and are easy to conflate. Read the exact label before acting.

How to diagnose it in Search Console

You cannot see a canonical relationship from the rendered page — you have to read the source or, faster, ask Google directly what it decided.

1. Inspect the URL and read the Google-selected canonical. Run the URL Inspection tool on the affected page and look at Page indexing → Google-selected canonical. Google’s help is explicit that “you can determine the canonical version only in the indexed data; the live test cannot predict whether or not the tested version will be considered canonical” — so use the indexed result, not the live test, for this.

2. Compare it to what you expected. If the Google-selected canonical is the URL you intended to be canonical (the desktop page, the clean parameter-free URL), the status is correct and you stop here. If it’s a surprise — a homepage, a category page, an unrelated URL — you have found a misapplied canonical.

3. Read the page’s declared canonical in the source. View source (or your browser’s dev tools) on the affected URL and find the <link rel="canonical"> element. If it points somewhere you didn’t intend, that is the tag to fix. Google only accepts the canonical if it’s in the <head>, so confirm it’s there and not injected into the body.

4. Don’t rely on the live test for this class of issue. Google notes that the live URL Inspection “doesn’t test all the issues” in the Page Indexing report — “most notably, duplicate or canonical conditions are not tested in the live test.” Canonical diagnosis comes from the indexed data.

This is the same read-the-report-precisely discipline that keeps you out of trouble elsewhere in Search Console — the technical SEO audit methodology treats every GSC status the same way: the label tells you Google’s intent, and the URL Inspection detail tells you what actually happened.

How to fix a page wrongly marked as an alternate

If diagnosis confirmed a canonical you didn’t intend, the fix is to make the page assert itself, then let Google re-evaluate.

1. Give the page a self-referential canonical. Every page you want indexed on its own should point its canonical at its own URL. Google recommends the self-referential canonical on the canonical page anyway:

<!-- On https://example.com/guides/canonical-tags -->
<link rel="canonical" href="https://example.com/guides/canonical-tags" />

Use an absolute URL, not a relative path — https://example.com/guides/canonical-tags, never /guides/canonical-tags.

2. Fix it at the source, not per-page. If a CMS or plugin is stamping the wrong canonical, correct the template or plugin setting so it stops overriding individual pages — Google’s guidance is to report the incorrect behaviour to your CMS provider if a plugin is doing this. Patching one page while the template re-breaks the next hundred is wasted effort.

3. Keep your signals from contradicting each other. Google warns not to specify different canonical URLs through different techniques — don’t name one URL in the rel="canonical" tag and a different one in your sitemap. Pick one canonical form per page and use it identically in the tag, the sitemap, and your internal links.

4. If it’s genuinely a separate mobile or AMP variant, leave the canonical pointing at the main page. The fix above is only for pages that should stand alone. A real mobile or AMP alternate should keep canonicalising to its desktop/non-AMP counterpart — that’s the correct configuration, and this status confirms it.

5. Request re-evaluation, sparingly. After the tags are corrected, use Request Indexing in URL Inspection — but Google notes this feature “is subject to quotas,” so reserve it for your most important URLs and let the rest re-crawl naturally.

How long recovery takes

Budget for a wait. Even after you correct the canonical, Google may hold pages in a duplicate cluster for up to two weeks before re-evaluating. Pages “split out faster if the difference between the new content and the other clustered pages is clear and significant” — so the more distinct the previously-suppressed page is from its former canonical, the quicker it earns its own listing.

The discipline that matters here is patience: verify the corrected canonical in URL Inspection, confirm the Google-selected canonical has flipped to the page’s own URL, and then stop touching it. Re-editing on day three resets your read on whether the fix worked. This is the same caution I’d apply before acting on any high-stakes Search Console signal — the kind of care that keeps you from, say, uploading a disavow file on a misread report and making a non-problem permanent.

Where this fits

“Alternate page with proper canonical tag” is one status inside the crawl-and-indexing layer, and it behaves like the rest of that layer: the tag tells you the intent, Search Console tells you what Google did with it, and the gap between the two is where the work is. Getting canonicals right on a few pages is a source-view check; keeping them right across a whole site — especially when a site migration reshuffles URLs and a stray template canonical can quietly suppress hundreds of pages — is a standing audit problem, which is the subject of the technical SEO audit framework.

If you’d rather have the indexing layer diagnosed and monitored than reverse-engineered one status at a time, that’s part of what I do: GEO and technical SEO consulting covers canonicalization, crawl budget, and the Search Console signals that tell you whether Google is indexing what you actually want ranked.

FAQ

Is “Alternate page with proper canonical tag” an error I need to fix?

No — in almost every case it’s the opposite of an error. Google files a URL here when it found the page, saw a valid canonical pointing to another page, and indexed that canonical instead. The word “proper” is Google confirming the tag worked. It only needs fixing if a page you wanted indexed on its own has landed in this status, which points to a canonical you set by accident.

Why is my page marked as an alternate when I want it indexed?

Because something is telling Google the page is a duplicate of another URL. The most common cause is a CMS or plugin applying an incorrect canonical — often a site-wide canonical from a template that overrides individual pages. Inspect the URL, check the Google-selected canonical field, and if it isn’t the page’s own URL, correct the rel="canonical" tag so the page self-canonicals.

What’s the difference between this status and “Duplicate, Google chose different canonical than user”?

They’re opposite outcomes. “Alternate page with proper canonical tag” means Google accepted your declared canonical and indexed it. “Duplicate, Google chose different canonical than user” means Google rejected your declared canonical and picked a different URL it judged to be the better canonical. The second one is the one worth investigating when a unique page isn’t ranking.

Does this status affect alternate language (hreflang) pages?

No. Google is explicit that alternate language pages are not detected by Search Console under this label. A translated page being dropped in favour of its original language shows up as a Duplicate status, not this one. The hreflang-and-canonical interaction is a separate issue with its own rules and failure modes, covered in combining hreflang and canonical tags.

How long after fixing the canonical will the page get indexed?

Up to about two weeks. Google may keep pages in a duplicate cluster for up to two weeks after you correct the tags, and they separate faster when the page’s content is clearly different from its former canonical. Verify the corrected canonical with URL Inspection, request indexing for your most important URLs, and let the re-evaluation finish before making further changes.

Next step

“Alternate page with proper canonical tag” is a status that’s right far more often than it’s wrong: it means a canonical did its job and Google indexed the page you preferred. The only move that matters is confirming intent — inspect the URL, read the Google-selected canonical, and if it’s the page you expected, leave it. If a page you built to rank on its own is sitting here, fix the canonical at its source, make it self-referential, and give Google two weeks. For the audit cadence that catches a stray canonical before it suppresses pages at scale, see the technical SEO audit framework; for the version of this problem that appears during URL changes, the site migration guide; and for an engagement that monitors the whole indexing layer end-to-end, GEO and technical SEO consulting.