Alternate page with proper canonical tag: is it a problem?

The status matters because the canonical is the URL Google can show in search and in the AI features built on its index, so a tag pointing the wrong way quietly removes a page you meant to rank. This guide quotes Google's definition, explains when the status is fine and when it isn't, and shows how to confirm it, fix a wrong canonical and ask Google to look again.

What does "Alternate page with proper canonical tag" mean?

"Alternate page with proper canonical tag" means the URL declares another URL as its canonical, Google accepted that choice, and the canonical is indexed. As of October 2026, Google's help page defines it like this: "This page is marked as an alternate of another page (that is, an AMP page with a desktop canonical, or a mobile version of a desktop canonical, or the desktop version of a mobile canonical). This page correctly points to the canonical page, which is indexed, so there is nothing you need to do." (Page indexing report help).

The same entry ends with a detail many guides miss: "Alternate language pages are not detected by Search Console." Translated versions linked with hreflang don't appear under this reason, so a language page missing from here isn't a sign anything is wrong.

Google treats canonicalization as picking "the representative –canonical– URL of a piece of content" from a set of duplicates, and says the canonical "will be crawled most regularly; duplicates are crawled less frequently" (Google Search Central: canonicalization). An alternate is simply a duplicate you labelled correctly.

How it compares with the two related statuses:

If the URL has no canonical tag at all, you're looking at the second row; see how to fix "Duplicate without user-selected canonical". The third status is Google overruling you: its help page says the page "is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical."

Is "Alternate page with proper canonical tag" a problem?

"Alternate page with proper canonical tag" is not a problem when the listed URLs are variants you never wanted in search. Google's report guide says "Having a page marked duplicate or alternate is usually a good thing; it means that we've found the canonical page and indexed it" and "Duplicate or alternate pages shouldn't be indexed" (Search Console Help).

A large count here is normal on sites with AMP, a mobile subdomain, faceted navigation or heavy campaign tagging. The number tracks how many variant URLs Google has found, not how healthy the site is.

It becomes a problem when:

• A page you want to rank is listed. A product, article or location page should be canonical to itself, so finding it here means its tag points elsewhere.
• The count jumps after a release. A theme, plugin or template change can start stamping the wrong canonical on many pages at once.
• Paginated pages point to page 1. Google's ecommerce guidance says "Don't use the first page of a paginated sequence as the canonical page" (Pagination and Search).
• Canonicals point to another domain you don't control, such as a staging host or an unfamiliar site.

If those wrongly canonicalized pages are spread across several client sites, check them in one list for free before you start editing templates.

What puts a URL in this status?

A URL lands here when its declared canonical points to another URL that Google also considers the right canonical. These are the common sources, all from Google's own documentation.

AMP pages

AMP pages are the example Google names first. URL Inspection's help says "For AMP pages, the canonical should be the non-AMP version unless it is a self-canonical AMP", and for its "URL is an alternate version" verdict it advises "Generally there is nothing to do, though you might check the Google-selected canonical to make sure that the canonical URL is the expected URL" (URL Inspection tool help).

Separate mobile URLs

Sites with an m-dot mobile site produce one alternate per page. Google's mobile-first indexing guide says "The desktop URL is always the canonical, and the mobile version is the alternate of that URL," with rel="canonical" on the mobile page and rel="alternate" on the desktop page (Mobile site and mobile-first indexing).

Parameter, filter and tracking URLs

Parameter URLs that carry a canonical to the clean URL show up here too. Google's help page says sites that "use parameters to filter or sort a common collection" get those pages "labeled as "duplicate" or "alternate" in the Page indexing report." A quick check on Google's own documentation shows the pattern: on October 17, 2026, fetching its canonicalization page with ?utm_source=test added returned a canonical pointing to the URL without the parameter.

Canonical tags pointing the wrong way

The cause that does need work is a tag pointing somewhere it shouldn't. Google's guide to fixing canonicalization issues says "Some content management systems (CMS) or CMS plugins can make incorrect use of canonicalization techniques to point to undesired URLs." The same guide warns that hacked pages can carry an injected cross-domain canonical "usually pointing to a URL hosting malicious or spammy content."

How do you confirm it with URL Inspection?

Confirm the status by inspecting an example URL in URL Inspection and comparing its two canonical fields in the indexed result. Open the reason in the Page indexing report, click a URL, and choose the inspect option.

1. Read "User-declared canonical". This is the URL your tag, HTTP header or sitemap points to. For an alternate it should be the page you consider the main version.
2. Read "Google-selected canonical". For this status it should match the user-declared one. Google's help notes that "sometimes Google might choose another URL that it considers a better canonical example"; when that happens, the URL appears under "Duplicate, Google chose different canonical than user" instead (URL Inspection tool help).
3. Inspect the canonical URL itself and check it shows "URL is on Google". URL Inspection gives canonical details only "if the canonical version is in a property that you own."
4. Check the tag in the page source. These commands print the canonical element and any canonical HTTP header (replace the URL with yours):

curl -sL "https://example.com/page?utm_source=test" | grep -ioE "<link[^>]*rel=[\"']?canonical[^>]*>"
curl -sI "https://example.com/page?utm_source=test" | grep -i "^link:"

Don't use Test live URL to judge canonicals. Google says "the live test cannot predict whether or not the tested version will be considered canonical," and its list of conditions the live test can't detect includes this exact status (URL Inspection tool help).

How do you fix a wrong canonical?

Fix a wrong canonical by making the page you want indexed point to itself, then making every other signal agree. If the listed URLs are true alternates, the right fix is to change nothing.

1. Sort the example URLs into true alternates (AMP, mobile, parameters) and pages that should be canonical.
2. Set a self-referencing canonical on each page that should be indexed, using an absolute URL in the <head>:

<!-- On https://example.com/services/seo-audit -->
<link rel="canonical" href="https://example.com/services/seo-audit" />

3. Find the source of the wrong tag: SEO plugin settings, theme templates, a hard-coded tag copied between pages, or JavaScript rewriting it. Google advises specifying the canonical "in the HTML source code and make sure that JavaScript doesn't change the canonical link element" (Google Search Central).
4. Give each paginated page its own canonical instead of pointing pages 2 and on at page 1.
5. Make the other signals agree. List only canonical URLs in your sitemap and link to them internally. Google warns: "Don't specify different URLs as canonical for the same page using different canonicalization techniques."
6. Don't strip the canonical from true alternates to get them indexed. Without it, they become candidates for "Duplicate without user-selected canonical" and Google picks the canonical itself.

If the parameter URLs are so numerous they compete for crawling, Google's ecommerce guidance offers noindex or robots.txt rules for unwanted filter and sort patterns; too many low-value URLs can also leave real pages stuck as discovered - currently not indexed.

How do you validate the fix?

Validate by clicking Validate fix on the reason once every wrong canonical is corrected, then re-inspect the pages you changed. Google says validation "typically takes up to about two weeks, but in some cases can take much longer" and asks you not to click it again "until validation has succeeded or failed" (Search Console Help).

• Skip validation when nothing was wrong. Google notes "It might not always make sense to fix and validate a specific issue on your website", and true alternates will stay in this status, correctly.
• Expect corrected pages to leave this status and, if Google indexes them, to show as indexed with their own URL as the Google-selected canonical.
• Allow time for re-clustering. Google says it "might hold pages in a duplicate cluster for up to two weeks" even after a fix (Fix canonicalization issues).
• If a corrected page still isn't indexed after that, the issue may be quality rather than canonicals; see pages Google crawled but chose not to index.

When should you push for a recrawl?

Push for a recrawl only for a page whose canonical you corrected, after the fix is live, and only if Google hasn't indexed it yet. Don't request indexing for true alternates; Google has already indexed their canonical and has no reason to index the copy.

• A few pages: use Request indexing in URL Inspection. Google says "there's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster" (Ask Google to recrawl).
• Many pages: resubmit your sitemap with accurate <lastmod> dates for the corrected URLs.
• Be patient. Google says crawling "can take anywhere from a few days to a few weeks."

Our guide to submitting a corrected URL to Google compares the routes, and our Google indexing guide explains the wider crawl-and-index process. Search Console only covers properties you can access, so for client portfolios you can run a visibility check on the canonical URLs to see which are seen by Google. FreshlyCited's smart push then sends only the invisible ones, re-checks on day 1, 3 and 7, and uses an index credit only if the link gets indexed; Google still decides. For other ways to check status at scale, read how index checkers work.

Corrected a batch of canonical tags? Check your pages free to see which ones Google has indexed and push only those it still can't see.