Alternate Page With Proper Canonical Tag: Is It Actually a Problem?

If you've opened the Coverage report in Google Search Console and seen "Alternate page with proper canonical tag" next to a handful of URLs, your first instinct is probably panic. It sits in the same list as real indexing errors, uses the word "excluded," and gives almost no context. The good news: in the vast majority of cases, this status means Google is doing exactly what you told it to do.

What "Alternate Page With Proper Canonical Tag" Actually Means

This status appears when Google crawls a URL, finds a rel="canonical" tag pointing to a different URL, and agrees with your choice. Google then indexes the canonical target instead of the page you're looking at, and lists the page you're looking at as an "alternate" — a duplicate that correctly defers to another version.

It is not an error. It is not a penalty. It is Google confirming that your canonicalization is working as designed. The word "excluded" in the Coverage report is misleading here — the page is excluded from being indexed on its own, but its content is still represented in search through the canonical URL.

Typical situations where this is completely normal:

• A product page reachable through both /shirts/blue-shirt and /products/blue-shirt?ref=nav, canonicalized to one clean URL
• Paginated or filtered category pages (?sort=price, ?page=2) that canonicalize back to the main category page
• HTTP vs. HTTPS or www vs. non-www duplicates left over from a migration
• Print-friendly or AMP versions pointing back to the primary article

Is This Status a Problem? Short Answer: Usually No

If the canonical target is the URL you actually want ranking, this status is Google confirming your setup is correct — not a bug to fix. Trying to "fix" every instance of this status by removing canonical tags usually makes things worse, because it reintroduces true duplicate content that Google now has to resolve on its own, often incorrectly.

The distinction that matters is intent versus accident. If you deliberately pointed the canonical tag at another URL, this status is a green light. If you didn't — if the canonical tag exists because of a templating default, a broken plugin, or a copy-paste from another page — that's where it becomes worth investigating.

How This Differs From Other Coverage Statuses

Search Console groups several similar-sounding statuses together, and mixing them up leads to wasted effort:

• Duplicate without user-selected canonical — Google found duplicates and you never specified a canonical, so Google picked one for you. This is worth fixing because you're leaving the decision to an algorithm.
• Duplicate, Google chose different canonical than user — you specified a canonical, but Google disagreed and indexed a different URL instead. This is worth investigating.
• Alternate page with proper canonical tag — you specified a canonical, and Google agreed. This is the healthy outcome the other two statuses are trying to reach.

If you're auditing your Coverage report, prioritize the first two categories. The third is largely informational.

When It Actually Signals a Problem

There are a few situations where this status deserves real attention:

1. The canonical points to a page that doesn't actually contain the same content. Google will still often honor a mismatched canonical for a while, but ranking signals get diluted and the wrong page can end up representing the wrong query.
2. A page you want indexed independently is showing up here. For example, two blog posts covering different subtopics accidentally share a canonical because of a templating bug — you lose a page from the index that should have ranked on its own.
3. The list is unexpectedly large and growing. A sudden spike often points to a technical issue: a CMS update that started injecting a default canonical tag across all pages, or a faceted navigation system generating URLs faster than your canonical logic can keep up.

How to Audit Your Alternate/Canonical Pages

A quick manual check: pick five to ten URLs from the list and confirm two things — that the canonical tag in the page's HTML <head> points where you expect, and that the target URL genuinely represents the same content. For a handful of pages this is fast to do by hand in the browser's "View Source."

For ongoing monitoring, checking this manually every time isn't realistic once a site has hundreds of pages generating these statuses. Traffic Monitor tracks your Search Console coverage data over time and flags when the "alternate page" count moves outside its normal range, so a templating regression shows up as a trend change instead of getting buried in a list you only check once a quarter.

Common Causes of Unintended Canonical Alternates

• CMS or theme defaults that set a self-referencing or parent-page canonical without your input
• URL parameters (tracking, session IDs, sort/filter options) that aren't being stripped before the canonical tag is generated
• Staging or localized duplicates that were never fully separated after a migration, pointing back at the production URL
• Syndicated or cross-posted content where the canonical correctly points to the original publisher — expected, not a bug

If you're chasing down a new spike in this status, the CMS/templating layer is almost always a faster place to look than individual page content.

Quick Checklist

• Confirm whether the canonical was set intentionally — if yes, this status usually needs no action
• Spot-check a sample of flagged URLs to make sure the canonical target actually matches the page's content
• Watch for sudden increases, which usually point to a templating or parameter-handling issue rather than a content problem
• Keep this separate from "duplicate without user-selected canonical," which is the version of this issue that actually needs fixing

Related reading: Duplicate Without User-Selected Canonical: What It Means (And How to Fix It) covers the version of this status where Google is left to guess — and what to do about it.