Alternate Page With Proper Canonical on Shopify: Ignore?
Search Console shows thousands of 'Alternate page with proper canonical tag' on Shopify? Why it happens, a quick test and the cases where you should act.
Quick answer: Often yes, you can ignore the count, provided a short check passes. Google describes “Alternate page with proper canonical tag” as a page that correctly points to a canonical page that is indexed, and says there is nothing you need to do. On a Shopify store the list can include extra addresses for pages you already have, such as products reached through a collection or links carrying tracking parameters. Inspect a sample of those URLs, and act only if the canonical is not the clean page you want or that page is not indexed.
You open Search Console, open the Page indexing report and scroll to the “Why pages aren’t indexed” table. Next to “Alternate page with proper canonical tag” is a number that keeps climbing. It sits in the same table as real problems, so it looks like one.
Often it is not. But “often” is not good enough when you are deciding whether to spend a developer’s hours, so this guide gives you a way to know. It covers what Google says the status means, why a Shopify store can collect so many of them, a quick test you can run on a sample, the cases where the status points at a real problem, and what not to do while you are looking.
It stays on reading and triaging the report. Canonical theory belongs to Google’s own documentation, which I link as I go, and if you find a real fault the next step is evidence for whoever built your theme or app, not a late-night edit to your theme code. For the fix side of duplicate product URLs, see our guide to Shopify duplicate content and canonical URLs. For two other indexing statuses founders worry about, see Crawled, currently not indexed and Discovered, currently not indexed.
All Google and Shopify documentation wording below was read on 30 October 2026. Help pages change, so treat it as “as at that date”.
What “Alternate page with proper canonical tag” means
Google’s Page indexing report help describes the status in short points. The page is marked as an alternate of another page (its examples are an AMP page with a desktop canonical, or a mobile version of a desktop canonical). It correctly points to the canonical page, which is indexed, so there is nothing you need to do. The same entry says alternate language pages are not detected by Search Console.
Two ideas from Google’s wider report help set the frame:
- “Not indexed” is not the same as “broken”. Google says not indexed is not necessarily bad, and that you should examine the reason given for each URL.
- Only canonical pages are expected to be indexed. Google says not to expect all URLs on your site to be indexed, only the canonical pages, and that your goal is the canonical version of every important page indexed.
Put those together and the status reads like this: Google found a second address for a page, followed the canonical tag to the address the page prefers, and that preferred address is indexed. The alternate sits in the “not indexed” table because it is working as designed.
The neighbouring statuses, side by side
The wording is close enough between a few duplicate-related statuses that it helps to see them together:
| Status | What Google says it means | Does it need action? |
|---|---|---|
| Alternate page with proper canonical tag | The page points to a canonical page that is indexed | Google says there is nothing you need to do |
| Duplicate without user-selected canonical | The page duplicates another and declares no preferred canonical, so Google chose the other page | Google says this is not an error. If you think Google chose the wrong URL, mark the canonical explicitly |
| Duplicate, Google chose different canonical than user | The page is marked canonical for a set of pages, but Google thinks another URL is a better canonical and indexed that one | Look. Google’s steps are to inspect the URL and compare the two canonicals |
| Page with redirect | A non-canonical URL that redirects to another page, so it will not be indexed | Check the status of the redirect target with the Inspect button |
Google describes the first two as needing no action or as working as intended. The third is the one to look at. If your report is dominated by the first row, you are mostly reading a list of duplicates that did their job.
Why a Shopify store can collect so many
Google counts URLs, not pages. Any time your store can produce more than one address for the same page, Google can find each address and record it. These are the sources I would check first.
1. The same product at more than one address. Shopify’s Liquid documentation describes the within filter as generating “a product URL within the context of the provided collection”. Its example output is /collections/sale-potions/products/draught-of-immortality, and the documentation warns that a standard product page and a product page in the context of a collection have the same content on separate URLs, so you should consider the SEO implications. Whether your theme uses that filter in its product links is something to check in your own theme, or by clicking through to a product from a collection page. If it does, every collection a product belongs to is another address for that product.
2. Tracking parameters. Google’s page on consolidating duplicate URLs uses a URL carrying a gclid tracking parameter as its example of an address you might rather people did not reach a page through, in favour of a clean one. Links in your ads, emails and social posts can carry parameters like that, and each combination is a separate address as far as a crawler is concerned.
3. Other URL parameters. Shopify’s own documentation describes several parameters that change the address without changing the page’s purpose: variant deep links (?variant=[variant-id]), the sort_by parameter on collection pages, and storefront filter parameters such as filter.v.option.color=red. I am not saying every store has all of them. Your own list will show which ones yours does, which is why the test below starts by grouping the URLs.
4. A canonical tag on every page. Shopify’s help centre says auto-generated canonical tags are added to pages to prevent duplicate content from appearing in search results. A Shopify blog post published on 14 August 2025 says canonical URLs are defined by default in Shopify’s first-party themes, and that if you use a third-party theme that lacks this you may need to assign custom canonical URLs. In Liquid, the canonical_url object is documented as “the canonical URL for the current page”, and Shopify’s theme documentation shows it placed in the head of theme.liquid.
Put together, any duplicate address that Google crawls, and that carries a canonical tag pointing at a preferred page that is indexed, lands in this status. That is the system doing what it was built to do.
One honest limit: the Shopify pages I read (the canonical_url reference, the within filter reference and the theme metadata guide) do not say what canonical_url returns for each type of address, or how your store answers a request for a collection-scoped product URL. Some stores may redirect that request, which Google would record under “Page with redirect”, and others may serve a page with a canonical tag, which Google would record under this status. Do not assume. The test below shows you what yours does.
How the count gets big (illustrative arithmetic)
This is an example, not a measurement from any store. Say a store has 150 products, and the average product belongs to three collections. If the theme links each product through each collection, that is up to 450 collection-scoped addresses for 150 pages. Now say ads, emails and social posts link to 20 of those products with 20 different tracking combinations each: that is another 400 addresses. Variant and sort addresses add more, so a 150-product store can pass 1,000 without anything being wrong. A catalogue of thousands of products gets there faster.
Is a big count a penalty or a crawl-budget problem?
Google’s page on consolidating duplicate URLs gives reasons to specify a canonical, among them consolidating signals for similar or duplicate pages and avoiding spending crawling time on duplicate pages. It also says that if you do not specify a canonical, Google will identify which version of the URL is best to show. I could not find a penalty described anywhere on that page.
On crawl budget, Google’s guide is written for large sites, which it describes as 1 million or more unique pages with content that changes about weekly, or 10,000 or more unique pages with very rapidly changing content (daily). Google calls those numbers a rough estimate, not exact thresholds. Count your own products, collections and pages against them: if you are nowhere near, that guide is not written for your store. It does say to eliminate duplicate content to focus crawling on unique content, so tidy internal linking is good practice. I would not treat this status as an emergency, as at 30 October 2026.
The quick test: ignore it or look closer
The aim is to decide, from a small sample, whether the status is the harmless kind. You need Search Console access and a browser. You do not need to change anything on your store.
Step 1: Group the list
Click the status in the Page indexing report to open its detail page. Google says the example list is limited to 1,000 items and is not guaranteed to show every URL in a status, so you are working from a sample. Many reports have an export button if you want a spreadsheet.
Sort the addresses into groups by pattern:
- Collection-scoped product addresses (
/collections/something/products/something) - Addresses with tracking parameters (
?utm_source=,?gclid=,?fbclid=and similar) - Variant addresses (
?variant=) - Sort and filter addresses (
?sort_by=,?filter.and similar) - Everything else
“Everything else” is the group to look at hardest. A clean /products/ or /collections/ address with no parameters sitting in this status is more interesting than the other groups.
You can also use the dropdown filter above the chart to show “All submitted pages”. Google counts a URL as submitted if it is listed in a sitemap you have submitted, even if Google also found it another way. Your sitemap should list the pages you want indexed, so a sitemap URL showing up as an alternate deserves a closer look.
Step 2: Inspect three to five URLs per group
Paste a URL from the group into the search bar at the top of Search Console to open URL Inspection. Look at the indexed version, not the live test, and note two fields:
- User-declared canonical: the canonical the page explicitly declared.
- Google-selected canonical: the page Google selected as the canonical when it found similar pages on your site.
Google’s own help says there is no guarantee Google will choose your preferred canonical (it takes your declaration into consideration), and that the Google-selected value can be a few hours out of date. For this status the two should name the same clean address, and that address should be the one you would put on a business card.
One trap: the live test is not the right tool for this question. Google says it cannot predict whether the tested version will be considered canonical, and does not test for all possible indexing issues, including whether a page is a duplicate or alternate. The indexed results come from the most recently indexed version of the page, which is what you want here.
Step 3: Read what the live page declares
In your browser, open one of the sampled addresses, then view the page source (in Chrome, put view-source: in front of the address). Search for rel="canonical". You are looking at what the page says now, whereas Search Console shows what Google saw at its last index. The two should agree. If you recently changed your theme, they may not yet, and that is worth knowing.
Also notice whether the address in the bar changed when the page loaded. If you typed a collection-scoped product address and it became the plain /products/ address, your store redirected the request. If it stayed, the page was served at that address and the canonical tag is doing the consolidating. Either result is a normal way for a store to behave. You are finding out which one yours uses.
For tracking parameters, do the same with a clean product address plus a made-up tag on the end, for example ?utm_source=test. The canonical in the source should be the clean address, without your test tag.
Step 4: Ask three questions
For each group, answer these about the canonical it points to:
- Is the canonical the address I would want? A clean
/products/handleor/collections/handle, not another product, a different collection or the home page. - Is the canonical itself indexed? Inspect it. It should say the URL is on Google. If it does not, the problem is the target page, not the alternate.
- Is it the same page? The alternate and the canonical should be the same product or collection under a different address, not two genuinely different pages.
If the answer to all three is yes for every group, ignore the count. Write the date and the number on a note, and move on to something that earns revenue.
If any answer is no, you have found one of the cases below.
The cases where the status points at a real problem
Here is what a “no” can look like, and what to do. The common thread is that you collect evidence and hand it to the right person. You are not hand-editing canonical logic from a blog post.
| What you find | What it may mean | What to do |
|---|---|---|
| The canonical points at the wrong page (a different product, a generic collection or the home page) | A theme or app is producing the wrong canonical tag | Send the developer or app vendor two or three example URLs and the canonical each one declares |
| The canonical carries your tracking parameters or is not the clean address | The page is declaring a messy address as the preferred one | Same: send examples. Do not strip the tracking tags from your campaign links to “fix” it |
| The canonical target is not indexed | The problem is the target page, not the alternate | Treat the target as its own indexing question, starting with the Crawled or Discovered guide |
| A page you want ranking is listed as an alternate of a different page | The page’s own canonical tag names another page, and Google followed it | Read the two side by side. If they are different products with their own demand, ask your developer why the tag points there |
| The count jumped after a theme change or app install | Something may have started producing extra addresses or wrong tags | Note the date of the change and look at what changed before touching anything else |
Google’s guide to troubleshooting canonicalisation supports the thinking. Its steps are to check which page Google considers the canonical, look for technical canonicalisation issues, make sure clustered pages are sufficiently different, and request re-indexing (reserved for your most important URLs, because of quotas). It names a CMS or plugin that makes incorrect use of rel="canonical" or a redirect as one cause, and says to contact the provider and report it. It also says re-evaluation takes time: even after fixing content issues, Google might hold pages in a duplicate cluster for up to two weeks. I read the guide as general canonical troubleshooting, so use the checking order, not the detail, for this status.
When a page you want indexed is the alternate
This one is the closest to a real loss. In this status, the page itself declares another address as its canonical, and Google followed it. If that other address is the same product at a different URL, that is the system working. If it is a different product, you may be asking Google to index the other page instead of this one.
One version: a store sells the same item as separate product pages by colour, and a theme setting or app points every colour at one of them. Ask whether each colour has its own search demand and its own reason to exist. If it does, the tag should not be sending Google elsewhere, and that is a question for your developer. If it does not, combining the colours into one product with variants can be simpler to manage, and our product page SEO checklist covers what a product page needs to stand on its own. Separate colour pages that each declare themselves canonical may land in “Duplicate, Google chose different canonical than user” instead, which is a separate decision from this list.
When the alternate is a filtered or tag collection
A filter or tag address whose own canonical points at itself is not an alternate of anything, so it will not be listed under this status. That is a different decision (index it, or do not), which our guide to Shopify filter URLs and index bloat walks through. Do not mix the two.
What not to do
Most damage from this status comes from people trying to make the number go to zero. Google describes it as nothing you need to do, so there is no zero to reach.
- Do not block the alternates in robots.txt. Google says not to use robots.txt for canonicalisation, and that it may still index URLs disallowed in robots.txt without their content. See our Shopify robots.txt guide before touching that file.
- Do not noindex product pages to tidy up. Google does not recommend noindex to prevent selection of a canonical page within a single site, because it completely blocks the page from Search. You could remove the version you want to rank.
- Do not use the removal tool as a canonical fix. Google says the URL removal tool hides all versions of a URL from Search, so it is not a canonicalisation method.
- Do not request indexing for the alternates. They are meant to be non-indexed. Google says to reserve Request indexing for your most important URLs, so use it on the canonical pages you care about, after a real change.
- Do not strip tracking tags from your own campaign links to shrink the list. The tags are how you know which channel brought which order. Our piece on why attribution breaks on Shopify covers why you want that data intact.
- Do not mix canonical signals. Google says not to specify different URLs as canonical for the same page using different techniques, for example one URL in a sitemap and a different one in the canonical tag. If several apps or theme settings each output canonical signals, view the page source and confirm there is a single canonical tag naming the address you want.
What to track instead of the alternate count
The alternate count is a by-product. These are the numbers that tell you whether canonicalisation is working for your revenue pages:
- Indexed pages that matter. Filter the report by your sitemap and check that the products and collections you want found are indexed. Our Shopify SEO and CRO resource hub lists the guides for the rest of that sorting work.
- Clicks and impressions on the clean addresses. In the Performance report, filter the page list to your main product and collection addresses. If those are earning impressions, Google is serving the version you want.
- The Google-selected canonical on your top five products and top five collections. Check them once a month in URL Inspection. It is a useful early warning that a theme or app change has gone wrong.
- Revenue from organic landing pages. Whether the clean pages bring orders over time is the point of all of this.
If you want to tidy the internal links that create collection-scoped addresses, that is a theme job with trade-offs for breadcrumbs and analytics, covered in our duplicate content and canonical URLs guide. Google says linking consistently to the URL you consider canonical helps it understand your preference, so it is worth doing for a larger catalogue. It is not a reason to panic about the status.
A worked example (illustrative numbers)
These numbers are made up to show the method. Say a store has 150 products and 20 collections, and the status shows 2,400 alternates. After grouping the exported examples:
| Group | URLs | Sample result (5 each) | Decision |
|---|---|---|---|
| Collection-scoped product addresses | 450 | Canonical is the clean /products/ address and is indexed | Ignore |
| Tracking-parameter addresses | 1,300 | Canonical is the clean address and is indexed | Ignore |
| Variant addresses | 450 | Canonical is the plain product address | Ignore |
| Sort and filter addresses | 150 | Canonical is the plain collection address | Ignore |
| Everything else | 50 | 3 of 5 point at the home page | Look closer |
Out of 2,400, the 50 in “everything else” are the only group that failed the three questions. Inspecting them, the owner finds they are old addresses from a previous theme whose canonical tag points at the home page, so they bring the evidence to the theme developer. The other 2,350 need no action. If someone had said “fix 2,400 canonicals”, more than 97% of that effort would have been wasted.
Key takeaways
- Google says “Alternate page with proper canonical tag” means the page correctly points to a canonical page that is indexed, and there is nothing you need to do.
- Not indexed is not necessarily bad. Google expects only canonical pages to be indexed.
- On Shopify the count can come from several addresses for one page: collection-scoped product links (which Shopify’s own
withindocumentation warns about), tracking parameters and other URL parameters. - The Shopify pages I read do not list what the canonical returns for every address type, so test your own store instead of assuming.
- The test is short: group the list, inspect three to five per group, read the canonical and answer three questions (right page, indexed, same page).
- The problem cases are a wrong canonical target, a messy canonical, a target that is not indexed, a page you want indexed pointing at another page, and a sudden jump after a change.
- Do not block, noindex, remove or request indexing to push the count down. Track indexed key pages, clicks on clean addresses and organic revenue instead.
FAQs
Is “Alternate page with proper canonical tag” an error?
No. Google describes it as a page that correctly points to the canonical page, which is indexed, and says there is nothing you need to do. It sits in the “not indexed” table, and Google says not indexed is not necessarily bad. The status that deserves a look is the one where Google chose a different canonical than you declared.
Should I fix it on my Shopify store?
Not as a rule. Run the quick test first. If a sample from each group points at the clean address and that address is indexed, there is nothing to fix. If a group fails, collect examples and hand them to whoever manages your theme or the app that outputs the tag.
Why does my Shopify store have so many of them?
Because one page can have many addresses. Shopify’s within filter builds product URLs inside a collection, and its documentation warns they have the same content on separate URLs. Campaign links can add tracking parameters, which Google’s own guidance uses as an example of an address you would rather not have people reach a page through. Shopify also adds canonical tags automatically, so each duplicate can point back to the preferred page.
Will it hurt my rankings or my crawl budget?
Google’s guidance gives consolidating signals and saving crawling time as reasons to specify a canonical, and I could not find a penalty described on that page. Its crawl budget guide is aimed at very large sites, 1 million or more unique pages, or 10,000 or more with very rapidly changing content, which it calls a rough estimate. Count your own pages against that. Nothing here is guaranteed either way.
How do I know if the canonical is wrong?
Use URL Inspection on a sample and compare the user-declared canonical with the Google-selected canonical. Then view the page source and confirm the canonical tag names the clean address you want. It is wrong if it names a different product, a generic collection, the home page or an address carrying your tracking tags, or if the target is not indexed.
Why is the number still going up after I changed my theme?
Google finds addresses as it crawls, on its own schedule, and links elsewhere (emails, ads, other sites) can keep pointing at addresses your new theme no longer links to. I could not find Google documentation that says a theme change clears addresses already recorded, so do not expect the count to fall quickly. Judge the change by whether your key pages stay indexed, not by the count.
What if the page I care about is the one listed as an alternate?
That is the case worth acting on. Inspect it and the page it points to. If they are the same page at two addresses, the canonical is doing its job and the other address is the one you want indexed. If they are two different products with their own demand, ask your developer why the tag points there, and see our product page SEO checklist for what a product page needs to stand on its own.
Is your Search Console report hiding a real problem?
Sorting out which statuses are noise and which are costing you pages is part of the technical audit in our Shopify SEO service, which covers crawlability and indexation. We do not guarantee rankings or indexing: Google decides both.
If you would like us to look at your store, book a free 30-minute diagnostic or tell us about your store. We look at your store before we recommend anything, and we tell you honestly if SEO isn’t the right move. No pitch.
Free 30-min diagnostic
Seen enough?
Book a free diagnostic.
We'll look at your store's search pages, find what is costing you traffic and tell you what to fix first. No pitch. No email gate. 30 minutes.
More from Prism3
Afterpay vs Zip vs Shop Pay Instalments: Shopify AU
Afterpay, Zip and Shop Pay Instalments compared for Australian Shopify stores: merchant fees, payouts, approval, checkout placement and a worked margin example.
AI-Referred Orders on Shopify: What Is Real and What Is Hype
What Shopify has disclosed about AI-referred orders, why the 13x headline needs context, how to find AI traffic in GA4 and Shopify, and what to do now.
AI Visibility Tools for Shopify: What They Measure and Miss
What AI visibility tools for Shopify stores really count: mentions, share of voice and citations, where the data is sampled or unstable, and how to use them.