Alternate page with proper canonical tag: is it a problem?
Alternate page with proper canonical tag means Google honoured your canonical and indexed that URL. It only hurts when a template canonicalises every page.
LLaunchScaler·Published ·8 min read
Alternate page with proper canonical tag means the listed URL declares another URL as its canonical, Google agreed, and Google indexed that other URL instead. For tracking-parameter URLs, print views and AMP or mobile variants this is the correct result and needs no fix; it only hurts when a template bug makes pages that should rank point their canonical at the homepage or at one article.
Telling those two situations apart takes a few minutes with the example list and URL Inspection.
What does "Alternate page with proper canonical tag" mean?
It means your rel="canonical" worked. The listed URL names a different URL as the preferred version, Google accepted it, and the preferred URL is in the index. Search Console's help says the page "correctly points to the canonical page, which is indexed, so there is nothing you need to do."
Google treats this and the duplicate statuses as good news in general: "Having a page marked duplicate or alternate is usually a good thing; it means that we've found the canonical page and indexed it." The status sits in the not-indexed table because the alternate URL itself is not indexed, which is the point of declaring a canonical in the first place. The page indexing report guide lists this row among the ones that usually need no action.
The help's own examples are AMP pages with a desktop canonical and separate mobile or desktop versions. In practice the row fills with parameter URLs too, and Google's help says pages that filter or sort a common collection "will be labeled as 'duplicate' or 'alternate' in the Page indexing report."
Which URLs normally show up here?
Any URL that is a variant of a real page and carries a canonical to that page. Typical sources are tracking parameters, sort and filter parameters, print views, AMP pages and separate mobile URLs. If every example URL in the row is one of these, and each points at the clean version of the same page, the report is confirming your setup works.
Source
Questions, answered
What people ask about this
01
What does alternate page with proper canonical tag mean?
It means the listed URL has a rel=canonical tag pointing at another URL, Google accepted that choice, and the other URL is the one indexed. Google's help says there is nothing you need to do.
02
Is alternate page with proper canonical tag bad for SEO?
The gclid example comes from Google's own canonical documentation, which uses it to show why you would want the clean URL in search results rather than the tagged one.
How do you confirm Google agrees with your canonical?
Inspect one example URL in URL Inspection and compare two fields in the Page indexing section: User-declared canonical, the URL your tag names, and Google-selected canonical, the URL Google picked. When both show the same clean URL, Google has accepted your choice and the alternate URL is correctly out of the index.
Open the Alternate page with proper canonical tag row and copy two or three example URLs from different sections of the site.
Paste each into the URL Inspection bar at the top of Search Console.
Expand Page indexing and read User-declared canonical and Google-selected canonical.
Inspect the canonical URL itself and confirm it says "URL is on Google."
Your template is canonicalising pages away; fix it
URL Inspection's live test does not check canonical selection, so read these fields on the indexed result, not in Test live URL.
Should you block or remove the alternate URLs?
No. The canonical is already doing the job, and the tools people reach for next make it worse. Google's canonical guidance lists three things not to do: use robots.txt for canonicalization, use the URL removal tool for it, or use noindex to steer which page becomes canonical within a site.
Each one backfires in its own way. A robots.txt block stops Google reading the alternate page, so it never sees the canonical tag, and Google says it "may still index URLs that are disallowed in robots.txt without their content." The removal tool "hides all versions of a URL from Search," which can take the clean URL out along with the tagged one. And noindex on a duplicate "will completely block the page from Search," where Google calls rel="canonical" "the preferred solution."
The one change worth making is on your side: link internally to the canonical URL, not the variants. Google says "when linking within your site, link to the canonical URL rather than a duplicate URL," which keeps the variants out of Google's crawl in the first place.
When is this status a problem?
It is a problem when the listed URLs are pages that should rank as themselves: articles, product pages, feature pages, docs. That happens when a shared template writes the same canonical on every page, usually the homepage or the first article in a collection. Google does what the tag asks, indexes one URL, and lists every other page here as its alternate.
The signs are easy to spot once you look:
The row's count jumped right after a deploy or a theme or plugin change.
The example list holds real content URLs, not parameter or print variants.
URL Inspection on an article shows https://example.com/ as the User-declared canonical.
Pages you expect in search no longer appear for their own titles.
The usual causes:
A canonical set once in a shared layout or header include, with a fixed URL instead of the current page's URL.
A framework layout that sets a canonical inherited by every child route. In Next.js, metadata from a layout is inherited by pages that do not set the same field, and the docs' own metadataBase example sets alternates: { canonical: '/' }, which renders <link rel="canonical" href="https://acme.com" />. Placed in app/layout.js, every page that does not override alternates inherits the homepage as its canonical.
An SEO plugin or CMS setting misconfigured. Google's troubleshooting guide warns that "some content management systems (CMS) or CMS plugins can make incorrect use of canonicalization techniques to point to undesired URLs."
Paginated pages all pointing at page 1. Google's pagination guidance says "Don't use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL."
JavaScript that rewrites the canonical after load. Google advises setting it in the HTML source and making sure "JavaScript doesn't change the canonical link element."
To confirm, read the tag on two different pages as served, not in DevTools, where a script may have changed it:
If both lines print the same href, the template is the bug.
How do you fix a page that should rank on its own?
Give it a self-referencing canonical: one <link rel="canonical"> in the <head>, holding the page's own absolute URL. Google recommends a self-referential canonical on the canonical page itself, absolute rather than relative URLs, and says the element "is only accepted if it appears in the <head> section of the HTML." Then confirm the fix live and ask Google to recrawl.
Generate the canonical per page from the page's own URL, never from a fixed string in a shared layout.
Write it as an absolute URL: <link rel="canonical" href="https://example.com/blog/how-to-launch" />. Google says relative paths "can cause problems in the long run," for example when a test site gets crawled.
Keep one canonical per page. If you also send a Link: <...>; rel="canonical" HTTP header, Google says using both "is more error prone"; pick one.
Point your internal links and sitemap at the same URL. Google says linking consistently to the canonical "helps Google understand your preference."
Run Test live URL on one fixed page to confirm the page loads, then click Request indexing. Repeat for your most important pages only, because requests have a daily quota.
In Next.js App Router, set metadataBase once in the root layout and set the canonical per page:
With metadataBase: new URL("https://example.com") in the root layout, that relative path renders as an absolute URL. Remove any alternates.canonical from the root layout itself, or set the homepage's canonical in app/page.tsx instead, so no page inherits it by accident.
After the fix, the affected URLs move out of this row as Google recrawls them. The canonical tag mistakes guide covers the other ways canonicals go wrong.
Check the canonical your page actually sends
To read what your page declares right now, run the free scan on LaunchScaler. It takes a URL, needs no account, and runs 156 checks across 6 of its 7 categories at no cost. Its canonical checks flag a page with no self-referencing canonical or one pointing at a different URL, a canonical aimed at a URL that redirects, returns 404 or is noindexed, a canonical or robots directive that contradicts what the URL actually returns, and invalid HTML in the <head> that closes it early and drops the canonical below it. It reads your live page rather than Google's index, so run it on one page from each template, fix what it flags, and inspect the same URL in Search Console.
Usually not. Google says having a page marked alternate is usually a good thing, because it means Google found the canonical page and indexed it. It is only harmful when pages that should rank on their own point their canonical somewhere else.
03
How do I fix alternate page with proper canonical tag?
Fix it only for URLs that should appear in search as themselves. Give each of those pages a self-referencing canonical, an absolute URL to its own address in the head, then test the live URL and request indexing.
04
Why are my blog posts showing as alternate page with proper canonical tag?
Almost always because a shared template sets the same canonical on every page, typically the homepage or the first article. Check the canonical in the page source of two different posts; if they match, the template is the bug.
05
Should UTM links show as alternate page with proper canonical tag?
Yes, that is the expected result. A URL like /pricing?utm_source=newsletter should carry a canonical to /pricing, so Google indexes the clean URL and lists the tagged one as an alternate.
Blocked by robots.txt means a rule stops Googlebot fetching the URL. Find the group Googlebot obeys and the longest matching rule, then edit that line.
A 403 to Googlebot usually comes from bot protection, not your app. Find the layer in your WAF logs and allow verified crawlers by IP, never by user agent.
