Search Console Says “Alternate Page with Proper Canonical Tag”—Do You Need to Fix It?

17 hours ago

7 min read

“Alternate page with proper canonical tag” is often a healthy Search Console exclusion, not an error. It means Google found a duplicate or near-duplicate URL, accepted another URL as the representative version, and excluded the alternate from search results. The important question is whether Google consolidated the right pair of pages.

In site audits, the risky response is to treat every excluded URL as broken. That can lead to removed canonical tags, unnecessary noindex directives, redirect chains, or parameter pages entering the index. A better approach is to classify the URL first, inspect the canonical relationship, and change something only when the alternate page should rank independently or points to the wrong destination.

The quick answer: when should you fix this status?

Leave it alone when the excluded URL is a genuine duplicate, the canonical target is the page you want indexed, and your internal links and sitemap consistently support that target.

Investigate it when the excluded URL contains unique content, the canonical points to an unrelated page, the target redirects or cannot be indexed, or important internal links keep sending Google to the alternate version.

Expected: a tracking-parameter URL points to the clean page.
Expected: a filtered or sorted product URL points to the main collection or product page.
Expected: HTTP, www, trailing-slash, print or session variants consolidate to one preferred URL.
Potential problem: a location, language, service or product page with meaningful unique content is treated as a duplicate.
Potential problem: the canonical target is a redirect, 404, noindex page or a URL blocked from crawling.
Potential problem: the alternate URL is still listed in the XML sitemap or used widely in internal navigation.

What “alternate page with proper canonical tag” actually means

Canonicalization is Google’s process of selecting one representative URL from a group of duplicate or very similar pages. Google may discover several addresses that show essentially the same content, but it normally indexes only one of them. The others can appear in this Search Console status when their canonical signal points to the selected page.

Google describes redirects and rel="canonical" as strong canonical signals, while sitemap inclusion is weaker. Signals can be combined, which is why one conflicting input—such as an alternate URL in the sitemap—may not overturn the chosen canonical but can still waste crawling and complicate diagnosis. Read Google’s canonical URL guidance for the underlying rules.

This status is different from “Duplicate without user-selected canonical”. In that report, Google found duplication without a clear canonical preference from the site. Here, a canonical relationship exists and Google considers the alternate excluded appropriately—at least from its current understanding.

Start with one sample URL, not the entire report

Open a representative URL in Search Console and inspect it. Record the inspected URL, the user-declared canonical, and the Google-selected canonical. Do not change templates based only on the report label; two URLs in the same status can have completely different causes.

Choose a recent, commercially important sample instead of a random parameter URL.
Use URL Inspection to compare the user-declared and Google-selected canonical.
Open both URLs in a clean browser session and confirm whether their main content is truly the same.
Check the canonical tag in the rendered HTML, not only in the CMS settings.
Test the canonical target’s HTTP status, indexability and final destination.
Find how Google discovered the alternate: internal link, sitemap, redirect, external link, filter, tracking parameter or CMS-generated URL.

If Google selected a different target than the one declared, use Webcurry’s guide to Google-selected canonical conflicts before changing the tag. That is a different diagnosis from an accepted alternate.

Decide whether the two pages are really duplicates

A canonical is appropriate for duplicate or very similar pages. It is not a substitute for building a clear information architecture, and it should not be used merely because two pages share a template.

Usually safe to consolidate

UTM and advertising parameters that do not change the page’s primary content.
Sorting and filtering URLs that present the same inventory in a different order.
Uppercase, lowercase, trailing-slash, protocol or hostname variants.
Printer-friendly, session, preview or share-link versions of the same document.
Product URLs reached through multiple collection paths when the product content is identical.

Usually worth a closer review

City or service-area pages with distinct addresses, proof, services or customer intent.
Language or regional versions intended for different audiences.
Products with materially different specifications, availability or purchasing intent.
Paginated pages, articles or category archives that expose unique items.
A replacement page that resembles the old page but serves a different search need.

If a page deserves to rank on its own, give it a self-referencing canonical and make its main content, title, headings, internal links and purpose clearly distinct. Do not manufacture superficial differences solely to force indexation.

Check the canonical target before trusting the exclusion

A correct canonical target should return a stable 200 response, allow indexing, contain the preferred content, and avoid another canonical pointing elsewhere. A chain of canonical hints makes the intended destination harder to interpret.

The alternate URL should point directly to the final canonical, not to an intermediate URL.
The canonical target should not redirect. If it does, update the tag to the final URL.
The target should not carry noindex. If it does, resolve the conflicting instruction.
The target should not be a soft 404 or an empty template.
The canonical should use the preferred HTTPS hostname and normalized path.
The canonical page should normally reference itself with its own canonical tag.

If the target redirects, follow the diagnostic steps in Webcurry’s Page with Redirect guide. If it is excluded by a directive, use the noindex troubleshooting workflow to trace the source before removing anything.

Align your sitemap and internal links with the preferred URL

The sitemap should contain canonical URLs you want Google to index. When both the alternate and preferred URL are present, the sitemap sends a weaker signal that conflicts with the canonical relationship.

Internal links matter for the same reason. Navigation, breadcrumbs, related-post modules, product grids and body links should usually use the preferred URL directly. Do not make Google follow a duplicate URL merely to discover its canonical target.

Remove known alternate URLs from the XML sitemap.
Update internal links to point directly to the canonical URL.
Normalize URL generation in templates, filters, campaign links and CMS references.
Keep external campaign parameters when measurement needs them, but ensure they resolve to the same content and canonicalize cleanly.
Use redirects for obsolete URLs when visitors should never need the alternate version.

Redirecting every duplicate is not always practical. Filter and tracking URLs may need to remain accessible. In those cases, a direct canonical plus consistent sitemap and internal-link signals is normally the cleaner solution.

Platform-specific checks

Wix

Wix automatically creates a default canonical URL for pages. A custom canonical can be changed in the page’s SEO settings, but it should be changed only when multiple URLs truly represent the same page. Wix also warns that a page with a custom canonical pointing elsewhere may disappear from the sitemap.

Open the page’s SEO settings and review the canonical under Advanced SEO.
Remove an old custom canonical if the page should revert to its default self-referencing URL.
Check dynamic-page patterns and duplicated pages for inherited custom tags.
Confirm the canonical target is the exact live URL, including the preferred domain and path.
Use the Webcurry Wix SEO checklist to review the surrounding indexability signals.

For a broader platform review, follow the Wix SEO checklist. Wix’s own canonical-tag documentation explains the default and custom behavior.

WordPress

WordPress outputs canonical links for singular pages, while SEO plugins can replace or extend that behavior. Problems usually appear when a plugin, theme, migration rule or custom hook outputs a second canonical or points to an outdated domain.

View the rendered source and confirm there is exactly one canonical link element.
Compare the canonical generated by WordPress with the value configured in the SEO plugin.
Check whether category, tag, pagination, attachment or parameter pages are being consolidated intentionally.
After a domain or permalink migration, search the database and template settings for the old hostname.
Clear page, object and CDN caches after changing the canonical output.

If a recent update changed the output, use the WordPress update recovery checklist and test changes safely before altering production templates.

Shopify

Shopify themes commonly output the canonical_url Liquid object in the document head. Duplicate signals can arise from collection-based product paths, filters, sorting parameters, markets, apps or theme customizations.

Inspect the live theme and confirm the canonical link uses the platform’s canonical_url value.
Check that an app or custom snippet is not outputting a second canonical.
Compare /products/ URLs with collection-based paths that reach the same product.
Review market or language URLs separately; regional alternates need coherent canonical and hreflang signals.
Test a clean theme preview before editing production code.

Shopify documents the global canonical_url Liquid object for theme output.

Common fixes that make the situation worse

Removing every canonical tag because excluded URLs look alarming.
Adding noindex to duplicate pages while also blocking them in robots.txt, preventing Google from seeing the directive.
Pointing many loosely related pages to one high-authority page.
Canonicalizing local or language pages without confirming that their purpose and content are equivalent.
Leaving alternate URLs in navigation and the sitemap after choosing a preferred version.
Requesting indexing repeatedly before Google can recrawl the page and its canonical target.

Canonical tags are signals, not commands. A clean implementation uses the same preferred URL across redirects, canonical annotations, sitemaps, internal links and content. Repeated indexing requests cannot compensate for contradictory signals.

How to verify the repair

Fetch the alternate URL and confirm it returns the intended content and one correct canonical tag.
Fetch the target and confirm it returns 200, is indexable and self-canonicalizes.
Verify the alternate is absent from the sitemap and internal links use the preferred URL.
Inspect both URLs in Search Console after Google recrawls them.
Confirm the preferred URL is indexed and eligible to appear for the intended query.
Monitor the report trend; a remaining alternate count can be normal if parameter URLs continue to be discovered.

If the preferred URL remains excluded after its signals are aligned, investigate content quality and crawl state with Webcurry’s crawled-but-not-indexed guide rather than changing the canonical repeatedly.

The practical conclusion

“Alternate page with proper canonical tag” is a classification, not automatically a defect. The correct outcome is one strong, indexable canonical page supported by consistent links and sitemap entries—not the maximum possible number of indexed URLs.

Fix the report only when the relationship is wrong: the alternate should be independently searchable, the target is unsuitable, or the site sends conflicting signals. When the pair is genuinely duplicate and Google chose the intended page, document the decision and move on to issues that affect real pages, users and conversions.

For a broader audit of canonical tags, redirects, indexability and internal links, use Webcurry’s technical SEO checklist.