Alternate Page With Proper Canonical Tag: Usually Nothing to Fix

"Alternate page with proper canonical tag" means Google found a URL whose canonical tag points to a different URL, agreed with it, and indexed that other URL instead. In most cases this is the system working as designed, and there is nothing to change. It becomes a problem only when a page you want in search results is on the list, which usually traces back to a template writing the wrong canonical.

The status appears under "Not indexed" in the Page indexing report. Google's Portuguese help pages name the same reason "Página alternativa com tag canônica adequada".

What Google means by "Alternate page with proper canonical tag"

Google's Page indexing report documentation (checked October 2026) describes these as pages marked as an alternate of another page, and gives 3 examples: an AMP page with a desktop canonical, a mobile version of a desktop canonical, and a desktop version of a mobile canonical. It then says the page "correctly points to the canonical page, which is indexed, so there is nothing you need to do."

Two more details matter. The "Not indexed" section says those pages are not indexed "not necessarily because of an error", so a count here is not a defect count. And the entry ends: "Alternate language pages are not detected by Search Console." A translated page that shows up here is therefore a warning sign.

Google has 3 canonical statuses, and they differ on 2 questions: did the page declare a canonical, and did Google agree with it.

This is the only one of the 3 where your instruction and Google's decision match. If your URLs sit in the third row instead, the guide to duplicate without user-selected canonical covers that case.

Which URLs normally land in this status

Any URL whose canonical tag names a different page can end up here once Google agrees. The usual sources:

• Tracking and campaign parameters. Links in ads, emails and social posts add parameters such as ?utm_source= or ?gclid=. Google's own example canonicalizes a product URL with a gclid parameter to the clean product URL.
• Sorting and filtering. Category pages that reorder or filter the same products (?sort=price, ?color=blue) produce many URLs for one page.
• AMP pairs. The AMP specification requires an AMP page's canonical to point to the regular HTML version, or to itself if no regular version exists. Every paired AMP page is an expected entry.
• Separate mobile URLs. A site that serves m.example.com beside www.example.com canonicalizes one version to the other.

For all of these, being "not indexed" is the goal: one URL per piece of content in search results, which is what the canonical tag asked for. Google's canonicalization documentation adds that duplicate URLs are crawled less frequently than the canonical.

Is it a problem? Leave it, monitor it, or fix it

The verdict depends on what is on the list, not on how long the list is.

• Leave it when the example URLs are variants you never wanted indexed and each canonical names the version you want in search. This is the normal state, even with thousands of entries.
• Monitor it when the count rises in step with something you did: a new category filter, an ad campaign, a new AMP template. Check a few examples, confirm the pattern, move on.
• Fix it when a page you want indexed appears here. That usually means a template is writing the wrong canonical on many pages at once.
• Investigate when the count jumps without a change you can name. Open the examples: a new source of parameter links is harmless, while article, product or language paths point back to a template.

flowchart TD
    A["URL listed as an alternate page"] --> B{"Should this URL appear in search on its own?"}
    B -->|no| C{"Does its canonical name the version you want indexed?"}
    C -->|yes| D["Leave it: the status is expected"]
    C -->|no| E["Point the canonical at the right version"]
    B -->|yes| F{"Is it a translated page?"}
    F -->|yes| G["Fix: canonical to itself, in its own language"]
    F -->|no| H{"Is it page 2 or later of a series?"}
    H -->|yes| I["Fix: each page canonical to itself"]
    H -->|no| J["Fix the template that writes the canonical"]

The 4 patterns that put real pages here, each one a fix:

1. Every page points to the homepage. A theme or header include builds the canonical from the site address instead of the current page's address. Article and product pages then ask to be folded into the homepage, and when Google agrees they land here.
2. Paginated pages point to page 1. Google's pagination documentation says not to use the first page of a series as the canonical; each page should have its own.
3. Translated pages point to the original language. Google's canonicalization documentation treats language versions as duplicates only if the primary content is in the same language, and asks you to specify a canonical in the same language. A French page canonicalized to its English twin removes the French page from the index. The full pattern is in our analysis of canonical tags that point across languages.
4. Variants point to the wrong parent. A colour or location page with its own search demand, canonicalized to a generic parent because one rule was applied to a whole page type.

How to confirm which case you have

Search Console tells you which URLs are affected. Confirming the cause takes 4 steps.

1. Group the examples by pattern. Open the reason in the Page indexing report and export the examples. The documentation says examples are limited to 1,000 items and may not include every URL, so treat the export as a sample. Sort by path and parameter: a list of ?utm_ and ?sort= URLs is a "leave it" list; blog posts, products or /fr/ paths are the ones to investigate.

2. Inspect one URL from each suspicious group. In URL Inspection, read "User-declared canonical" and "Google-selected canonical" under "Page indexing". For this status both normally name the canonical target, not the URL you inspected. The documentation notes that the live test cannot predict which URL will be chosen as canonical, so read these fields from the indexed result.

3. Inspect the canonical target. It should be indexed, answer with a 200 status, carry no noindex and name itself as canonical. A target that redirects or is noindexed contradicts the canonical that points to it, and Google may then choose a different URL; the page indexability guide covers how those signals interact.

4. Read the canonical in the HTML your server sends. Google's documentation asks you to make sure JavaScript does not change the canonical link element, so compare the raw HTML with what the browser shows:

# Canonical tag in the HTML the server returns
curl -s "https://example.com/blog/my-post/" | grep -Eio '<link[^>]*rel=.?canonical[^>]*>'

# Canonical sent as an HTTP header (used for PDFs and other non-HTML files)
curl -sI "https://example.com/files/guide.pdf" | grep -i '^link:'

If the raw HTML and the rendered page name different URLs, a script is rewriting the tag after load. In 34 external sites where SEOReport compared the server's raw HTML with the rendered homepage between May and October 2026, 6 (18%) had at least one of title, meta description, canonical or H1 present only after rendering. The JavaScript rendering guide covers how to move those elements into the server response.

How to fix each case

The fix is always the same in principle: every page you want indexed declares itself as canonical, with an absolute URL in the <head>, and every variant points to that page.

<!-- On https://example.com/fr/tarifs/ : the French page names itself -->
<link rel="canonical" href="https://example.com/fr/tarifs/" />

<!-- On https://example.com/shoes/?sort=price : the variant names the main page -->
<link rel="canonical" href="https://example.com/shoes/" />

For the 4 cases: build the canonical from the page's own path, not the site's base address; give each page of a series its own canonical; let each language version name itself and leave the linking between versions to hreflang (the hreflang implementation guide has the markup); and give variants with their own search demand a self-referencing canonical.

Then align the supporting signals, because Google advises against sending different canonical instructions through different methods: list only canonical URLs in your XML sitemap, and link internally to the canonical URL rather than a variant. A self-referencing canonical on every indexable page is the baseline. In 45 external websites SEOReport audited between May and October 2026, 14 (31%) served a homepage with no canonical tag in the HTML the server returned.

Two changes to avoid on healthy entries: adding noindex (covered in the questions below), and blocking variants in robots.txt. A robots.txt block stops Google from reading the canonical at all, and Google's documentation notes that disallowed URLs may still be indexed without their content.

How to verify the fix

After the template change is live, inspect a fixed URL, run the live test to confirm Google can fetch it, and use "Request indexing" for a few important pages. Once Google recrawls, "User-declared canonical" in the indexed result should show the page itself, and the page should leave this status.

For a fix that affects many URLs, use "Validate fix" on the reason in the Page indexing report. Google's documentation says validation typically takes up to about 2 weeks and can take longer. Expect the count to fall over days to weeks as Google recrawls, and do not expect it to reach 0 on a site with tracking links, filters or AMP pages. A smaller count made of the right URLs is the target.

What a full diagnosis checks for this status

A full SEOReport diagnosis does not see which URLs Google grouped as alternates; only Search Console shows that. It checks the side you control: whether the canonical target your homepage names is healthy (no redirect, indexable, canonical to itself), whether the homepage canonical differs between smartphone and desktop or between raw HTML and the rendered page, whether alternate-language pages carry a canonical that points somewhere other than themselves, and canonical destinations that none of the pages it examined link to. Each finding names the URLs it found. Our canonical tags guide explains how canonical tags work.

Common questions

Does a large number of alternate pages hurt my site?

No. A large count from parameters, filters or AMP pages only reflects how many URL variants exist. It matters when it contains pages you want indexed.

Should I add noindex to these URLs to clean up the report?

No. The canonical tag already keeps them out of the index, and Google recommends rel="canonical" rather than noindex for choosing a canonical within a site. Adding noindex only adds a conflicting instruction. The article on URL marked 'noindex' covers when noindex is the right tool.

Why is my translated page listed here if Search Console does not detect alternate language pages?

Because its canonical tag names a different URL, usually the original-language page, and Google honored it. Change its canonical to point to itself.

Why do URLs I never linked to appear here?

Google finds URLs through links anywhere, including ads, emails and social posts that add tracking parameters. Those URLs serve your page's canonical tag, so Google folds them into the main URL.

How long after a fix will the page leave this status?

Google has to recrawl the page and process the new canonical, which takes days to weeks. "Request indexing" asks Google to crawl individual important pages, and "Validate fix" tracks the whole group.