"Crawled - currently not indexed" on Shopify products: what Google is actually telling you

Short answer. Google documents this status as "The page was crawled by Google but not indexed." Nothing is blocking it: Googlebot read the page and chose not to index it. On a Shopify store, most of the URLs listed are duplicate surfaces of pages you already have, and their absence from the index is consolidation rather than loss. Triage the list by URL shape first, then treat a live product page that survives that filter as a real signal.

This status frightens merchants more than any other line in the Page indexing report, and the reason is that it sounds like a verdict on the whole store. It is narrower than that, and it is also less actionable than the statuses around it, which is precisely what makes it confusing.

Google's own reference for the report defines it in one sentence: "The page was crawled by Google but not indexed." Compare that with its neighbours in the same report. "URL blocked by robots.txt" means you refused access. "URL marked 'noindex'" means you gave an explicit instruction. Those are settings, and a setting can be switched. This one is a judgement, and there is no switch.

Most of the list is not about your products

The report shows every URL Googlebot reached, and a Shopify storefront generates far more URLs than it has products. Before reading anything into the count, split the export by URL shape. Only the URLs containing /products/ are candidates for the question you actually care about, which is whether a page you expect to sell from is missing from the index.

Two shapes in particular tend to fill this list, and both are duplicates by design rather than failures.

Collection-scoped product URLs. Shopify can serve the same product at /products/handle and again at /collections/name/products/handle. This is not an accident of configuration; it is a documented behaviour of the platform. Shopify's own reference for the within filter states it plainly: "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." When Google finds several URLs carrying identical content, it picks one and leaves the others out. That is consolidation working correctly.

Variant parameters. A ?variant= URL is the same product page with a different option preselected. There is nothing separate to index.

If the entire list is made of these two shapes plus non-product URLs, you are looking at normal behaviour, and the right action is none.

Want to know which of your product pages Google can actually index? We read your live catalog and flag the pages whose canonical, indexability or structured data would keep them out — read-only, no app to install, about 2 minutes. → free scan

When a real product URL survives the filter

Now the question is worth asking. A live, in-stock product page, at its clean /products/ URL, that Google has crawled and declined to index, is telling you something about that page. There are three causes worth checking, in this order.

The canonical points somewhere else

This is the one that masquerades as a content problem. If the page declares a canonical URL that is not itself, Google is being told the page is a duplicate, and it will act on that. Run the URL through URL Inspection and compare the user-declared canonical with the Google-selected canonical. We cover the full mechanics, and why the collection URL so often wins, in the canonical article. In our own scans, canonical tags pointing at a different product, at a non-product page, or at a variant URL are among the failures we see often enough that each has its own dedicated check.

The page has nothing only it can say

A product page carrying a supplier description shared verbatim with hundreds of other stores gives Google very little reason to add another copy to the index. This is uncomfortable advice because it is not a bug to fix, but it is frequently the real answer on dropshipped and catalog-imported stores. Sizing detail, materials, your own photography, genuine reviews, shipping specifics — anything that exists only on your page — is what changes the calculation.

The structured data is broken

Worth eliminating before concluding anything about quality. If the page's Product block does not parse, everything it declared is invisible, usually with no symptom on the page itself. See the unparsable structured data article for how a single stray character silently discards an entire block.

How to check your own store in five minutes

1. Open Search Console → Indexing → Pages, click Crawled - currently not indexed, and export the list.
2. Filter to URLs containing /products/, then remove anything containing /collections/ or ?variant=. What remains is the list that matters.
3. Take one surviving URL and run URL Inspection on it. Compare User-declared canonical with Google-selected canonical; if they differ, you have your answer and it is not about content.
4. If the canonicals agree, open the page and ask what is on it that exists nowhere else. If the honest answer is nothing, that is the finding.
5. Run the same URL through the Rich Results Test to confirm the product's structured data still parses.

The pattern behind all of this is the one that runs through most silent visibility failures on Shopify: the admin shows a healthy, active, priced product, while the public URL tells Google something different. The report is not accusing your store of being low quality. It is reporting a decision, and the decision usually has a mechanical cause sitting one layer below it.