"Discovered - currently not indexed": why Google found your Shopify products and never fetched them

Short answer. Discovered - currently not indexed means Google knows the URL exists and has not fetched it yet. It is not a verdict on your content — that is the neighbouring status, Crawled - currently not indexed. On a Shopify store the usual cause is arithmetic: the store publishes far more crawlable URLs than it has products, and the crawler spends its visits on the copies.

The report is what makes this one maddening. You open Page indexing in Search Console expecting an error, and there is no error. No noindex, no block, no crawl failure — just a large number next to a status that reads like a shrug. Products you added six weeks ago are in there. Products that sold well last year are in there. And every guide you find tells you to improve your content, which would be excellent advice if anything at Google had read it.

What the status actually says

Google's Page indexing report documentation defines it precisely, and the second sentence is the one that matters: "The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl."

Compare that with the status directly beneath it in the same report: "The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling."

Two statuses, one word apart, and opposite instructions. A crawled page has been fetched, read and set aside — its title, its markup and its content have all been seen and judged insufficiently worth keeping, which is a real signal about the page. That is a different problem with different fixes, and we cover it in "Crawled - currently not indexed" on Shopify products. A discovered page has been seen by nothing. Google learned the address from a link or a sitemap and put it in a queue. Rewriting the product description of a page in that queue changes nothing, because the change is not visible to the entity that put it there.

So the honest first question is not "what is wrong with these pages". It is "what is the crawler doing instead".

Google names this status as a crawl-budget signal

There is a temptation to reach for "crawl budget" the moment indexing goes wrong, and Google spends the opening of its large-site crawl budget guide pushing back on exactly that: "If your site doesn't have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don't need to read this guide."

Then it lists who the guide is for. Two of the three entries are about size — a million pages, or ten thousand pages changing daily. The third is not about size at all:

• "Sites with a large portion of their total URLs classified by Search Console as Discovered - currently not indexed"

That is Google naming the status itself as a qualifying condition, independently of how many products you sell. A four-hundred-product store is not a large site by any ordinary reading — but if its Page indexing report is dominated by this status, Google's own documentation puts it in scope. Which reframes the problem usefully: the question is not how many products you have, it is how many addresses your store hands out.

Want to know whether your product pages are fit to index when the crawler does arrive? We read every product URL in your sitemap and check each page for the things that would make Google decline it — noindex directives, blocked paths, canonicals pointing elsewhere, broken markup. Read-only, no admin access, about 2 minutes. → free scan

Why a Shopify store has far more URLs than products

A Shopify store does not present one URL per product. It presents one canonical product URL plus every alternative address the platform, the theme and the installed apps are willing to link to. Three mechanisms account for most of the inflation, and none of them is visible anywhere in the admin.

1. Recommendation tracking parameters

Shopify's Product Recommendations API reference documents this openly: "the url property for each product in the products response contains URL parameters that lets you build a conversion funnel." The example URL in Shopify's own documentation looks like this:

/products/gorgeous-wooden-computer?pr_choice=default&pr_prod_strat=description&pr_rec_pid=13&pr_ref_pid=17&pr_seq=alternating

The parameters are there for a reason — they let Shopify's reports tell you which recommendation strategy produced a sale. The side effect is that the same product page acquires a distinct address for every combination of referring product and recommendation strategy. What drives the total is therefore not how many products you sell, but how densely they recommend one another.

The scale merchants report is not subtle. A Shopify Community thread opened in March 2024 describes roughly 80,000 parameter URLs discovered by Google on one store, with the poster quoting the exact shape: ?pr_prod_strat=use_description&pr_rec_id=…&pr_rec_pid=…&pr_ref_pid=…&pr_seq=uniform. A separate case study by the developer Eduard Fastovski, published in March 2023, describes a store of about 200 products that had accumulated over a million indexed URLs and several million more not indexed, attributed to ?pr_prod and ?filter parameters, and reports the merchant's result after blocking both patterns: "It worked! Down to just 1k pages now, from 5 million!"

Two independent stores, two years apart, same mechanism. What lets it persist is a gap in the platform's own defences: Shopify's default robots.txt blocks the recommendations endpoint, not the URLs it hands out. Reading the live robots.txt of two unrelated Shopify stores on 26 August 2026, both carry the same platform-generated default rules, Disallow: /recommendations/products among them — and neither contains any rule matching pr_prod_strat, pr_rec_id, pr_rec_pid, pr_ref_pid or pr_seq. You can check the same thing on your own store in about ten seconds, and step 4 below says how. The Ajax endpoint is closed. Every product URL carrying those parameters, wherever it ends up linked from — a theme section that renders recommendations into the page, an app, an external site, a sitemap generated by a third-party SEO tool — is fully crawlable.

2. Collection-scoped product URLs

The second address for every product is the one Shopify creates when a product card links through the collection it sits in: /collections/summer-sale/products/linen-shirt alongside /products/linen-shirt. Shopify documents the consequence itself, in the Liquid reference for the within filter: "Because a standard product page and a product page in the context of a collection have the same content on separate URLs, you should consider the SEO implications of using the within filter."

A product sitting in six collections can therefore be reached at seven addresses. The default robots.txt observed on both stores blocks sorted and filtered collection URLs — Disallow: /collections/*sort_by*, Disallow: /collections/*+* and their locale-prefixed twins — but nothing blocks /collections/*/products/*. Those URLs carry a canonical tag pointing back at the clean product URL, which is the correct handling for duplication, but a canonical is only readable after a fetch. Consolidating them still costs a crawl each. When Google picks the wrong one, that is a related but distinct failure, covered in user-declared canonical vs Google-selected on Shopify.

3. Whatever your apps invented

The default file blocks named patterns, not parameters in general. It blocks oseid, preview_theme_id, preview_script_id, a specific duplicated ls= shape, sorted and filtered collections, and /search. Any parameter an app or a theme introduces that does not match one of those patterns is crawlable by default: a filter app using its own query-string format, a "recently viewed" widget, a wishlist link, an affiliate or campaign parameter that ends up in an internal link rather than only in an outbound one.

This is the part with no admin screen. No app declares its URL footprint at install time, and nothing in Shopify tells you the store publishes more addresses this month than last. The first place it becomes visible is the report you are reading, and by then the crawler has been busy elsewhere for weeks.

How to check your own store in 5 minutes

1. Read the shapes, not the number. Open Page indexing, select Discovered - currently not indexed, and sort the sample URLs by their shape rather than scrolling them. Three buckets: clean /products/…, collection-scoped /collections/…/products/…, and anything with a ? in it. The proportions tell you which of the three mechanisms above you have.
2. Compare what Google knows against what you declared. Add the indexed and not-indexed totals in the report, then open yourstore.com/sitemap.xml. Shopify generates it automatically and, in its own words, it "contains links to all your products, primary product image, pages, collections, and blog posts", split into separate child sitemaps for products, collections, blogs and webpages. If Google knows an order of magnitude more URLs than you declared, the surplus arrived through links, and links are something you control.
3. View source on a product page and search for pr_prod_strat. If your theme renders a recommendations block into the page HTML, the parameters will be sitting in the href attributes. Search for pr_rec_pid too — themes vary in which subset they emit.
4. Open yourstore.com/robots.txt and read it properly. You are looking for two things: whether anything blocks the parameter shapes you found in step 3, and whether anyone has added a rule that goes further than intended. Shopify's help page on editing robots.txt.liquid warns in its own words that "Incorrect use of the feature can result in loss of all traffic", which is a failure mode we have written up separately as a stray Disallow blocking your products.
5. Inspect one clean product URL, not fifty. Run URL Inspection on a single product stuck at Discovered and note the last crawl date. Google's documentation is explicit that "This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web", and that "There is a daily limit of inspection requests for each property that you own". One URL is a diagnosis; a catalogue is not auditable this way.

Fixing each cause

Parameter URLs. Two documented routes, and the choice is a real trade-off rather than a best practice. You can strip the parameters where the theme renders the recommendation link, which costs you the conversion funnel those parameters exist to build — Shopify's reports will no longer attribute sales to a recommendation strategy. Or you can block the shapes in robots.txt.liquid, which keeps the tracking working for real visitors while telling Google not to spend fetches on them. Google's guidance for this situation is unambiguous about the method: "Block crawling of URLs using robots.txt", and, in the same breath, "Don't use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time." A noindex on a parameter URL is the intuitive fix and it makes the crawl problem slightly worse.

Edit robots.txt.liquid carefully and re-read the file afterwards. It is theme code, which means a theme change can take your edit with it, and Shopify's help page treats editing it as an unsupported customisation its support team does not assist with. That combination is the recurrence built into this fix: the block you add today is only as durable as the theme it lives in.

Collection-scoped duplicates. Where a product card does not need collection context, linking to the plain product URL removes the second address at source rather than asking Google to reconcile it afterwards. Google's crawl guidance puts the goal plainly: "Eliminate duplicate content to focus crawling on unique content rather than unique URLs."

Products that are genuinely gone. The same guidance says to "Return a 404 or 410 status code for permanently removed pages." On Shopify a deleted product's handle stops resolving, but the old URL can sit in Google's queue for a long time afterwards — and if it was redirected somewhere convenient instead, it is now a live URL competing for a fetch. That case has its own article: a deleted Shopify product still showing on Google.

Server response. Worth naming because Google's own definition of the status mentions overloading the site. The guide asks you to "Make your pages efficient to load" and to support "HTTP caching" and "304 (Not Modified) HTTP status codes". On Shopify's hosting you control less of this than on your own server, but heavy third-party scripts and app-injected assets are yours.

What not to do. Do not work down the list requesting indexing. Google states that "Submitting a request does not guarantee that the page will appear in the Google Index", and the daily limits in step 5 make a catalogue-sized pass impossible anyway. It is a diagnostic instrument being used as a remedy, and it leaves the crawl surface exactly as it was.

Why this one comes back

Every mechanism above is produced by ordinary shop-keeping. A merchandiser adds three collections and every product in them gains three addresses. A theme update ships a new recommendations section. An app adds a filter with a query format nobody reviewed. A seasonal range is deleted and the URLs are redirected somewhere tidy instead of being allowed to die. None of it is a mistake, none of it announces itself, and the effect is cumulative: the crawl surface only ever grows unless someone deliberately shrinks it.

And the feedback loop is slow enough to be useless as a warning. You will not notice the surface growing. You will notice, a quarter later, that the products you launched in spring never picked up traffic — at which point the report tells you they are discovered, which tells you almost nothing about why.

We should be exact about our own part in this, because it is easy to overclaim. StoreCanary does not report Google's crawl or index status. That data comes from Search Console, and we do not connect to it — so nothing we can show you will tell you which of your URLs Google has fetched. What we do read is your product sitemap, and every product page in it, checking whether each one is actually fit to be indexed when the crawler does arrive: whether it carries a noindex, whether robots.txt blocks its path, whether its canonical points at a different product or another domain, whether its markup parses. Those are the reasons a fetch gets wasted once it finally happens — and unlike the crawl schedule, they are things you can fix today.