Alternate page with proper canonical tag: should you worry?

“Alternate page with proper canonical tag” in Google Search Console means Google found a URL that names a different URL as its canonical, agreed with that choice, and indexed the canonical instead. Google’s help says that in this case “there is nothing you need to do”. Its sibling, “Page with redirect”, means the URL redirects somewhere else, so the target can be indexed but the redirecting URL will not be. Both statuses usually show your canonicalisation working; they matter when a page you wanted in search turns up in either list.

What do the two statuses mean?

Both sit under “Why pages aren’t indexed” in the Page indexing report (Indexing → Pages), and neither is an error.

Google describes “Alternate page with proper canonical tag” this way: “This page correctly points to the canonical page, which is indexed, so there is nothing you need to do.” The URL served a page with a canonical tag naming another URL, and Google indexed that other URL.

“Page with redirect” is described as “a non-canonical URL that redirects to another page”, and Google adds: “As such, this URL will not be indexed.” The redirect target is judged on its own merits.

The status to watch is a third one, “Duplicate, Google chose different canonical than user”. That means you declared a canonical and Google picked something else. The two here mean Google did what you asked.

Why do they appear?

To a crawler, every variant of an address is a separate URL. One page on your site can be reachable as:

Variant	Example
www and non-www	https://www.example.com/pricing and https://example.com/pricing
http and https	http://example.com/pricing and https://example.com/pricing
Trailing slash	/pricing and /pricing/
Parameters	/pricing?utm_source=newsletter, /pricing?gclid=…, /shop?sort=price

Google finds these through old links, other people’s links, ad clicks, sitemaps and your own templates. Google’s documentation is clear that “some duplicate content on a site is normal and it’s not a violation of Google’s spam policies”; it groups the duplicates, picks one, and crawls the canonical most regularly and the duplicates less often.

Whether you see the www and http variants at all depends on the property. A Domain property covers every subdomain and protocol, so all of them land in one report. A URL-prefix property for https://example.com/ does not include www or http URLs. Domain vs URL-prefix properties explains the difference.

A real example: our own site

In October 2026, Search Console emailed us about querywatch.app, this site. Four www URLs were listed as “Alternate page with proper canonical tag”. When Google crawled them, the www addresses served the same pages as the apex domain, and each page’s canonical tag pointed to the apex version, so Google indexed querywatch.app and set the www copies aside. The http://www address, which redirects, was reported alongside them.

Nothing was broken. The canonical tags did their job, and Google’s own verdict was that there was nothing to do. What the email did point at was untidiness: the www hostname was serving full pages instead of sending visitors and crawlers straight to the apex domain. That is what the clean-up below is for.

When is it a problem?

Check one URL before deciding. Run it through URL Inspection and compare the User-declared canonical with the Google-selected canonical, then inspect the canonical itself to confirm it is indexed. Then match what you find against this list:

• Harmless: www, http, slash and parameter variants that point at the URL you prefer. Tidy them up when convenient.
• A problem: a page you want indexed is listed as an alternate. Its canonical tag points somewhere else, often because of a copied template or a plugin setting.
• A problem: many unrelated pages all canonicalise to one URL, such as the home page. That is a template bug, and it can take the affected pages out of the index.
• A problem: an important page appears under “Page with redirect” and nobody meant to redirect it.
• Worth a look: either count jumps after a deploy or a migration. Inspect a sample before assuming it is fine.

The 301 clean-up

Google’s guide to consolidating duplicate URLs ranks the signals by strength: redirects and rel=“canonical” are strong signals, sitemap inclusion is a weak one. It recommends permanent redirects when you are retiring a duplicate, server-side for the quickest effect, and notes that Google prefers HTTPS over HTTP as canonical unless something conflicts. For hostname and protocol variants, a redirect is the right tool, because nobody needs to read both.

1. Pick one canonical form: https, either www or the apex domain, and one trailing-slash convention.
2. Redirect every other host and protocol combination to it with a single permanent server-side redirect (301 or 308), keeping the path and query string. Send http://www straight to the final URL in one hop rather than through https://www; Google’s crawl budget guide advises avoiding long redirect chains.
3. Keep a self-referencing, absolute canonical tag on every canonical page. It handles the variants a redirect should not touch, such as tracking parameters.
4. Make internal links, sitemaps and hreflang annotations use the canonical form and nothing else.
5. Do not use robots.txt or the Removals tool to hide variants. Google’s guide says neither is for canonicalisation.

On Nginx, the redirect for a www host is a few lines (certificate settings omitted):

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Most hosting platforms and CDNs offer the same thing as a redirect rule. Afterwards, expect the www URLs to move from “Alternate page with proper canonical tag” to “Page with redirect” as Google recrawls them. That is the intended end state, not a new problem, and you do not need to validate it.

Where QueryWatch fits

QueryWatch is an independent app, not affiliated with Google. Its URL inspection, 5 a day on the free tier, shows the Google-selected canonical next to the canonical you declared, so you can check one of these URLs from your phone. On Pro you can watch your key pages and get a push alert when one changes its index verdict or coverage state, which catches a deploy that quietly points a canonical tag at the wrong place. The Google Search Console app page lists what is free and what is Pro, and the Page indexing report explained covers the other reasons in the same table.