The Shopify Search Console statuses that mean you shipped a bug

TL;DR

• Search Console's Page indexing report has 18 documented statuses: 15 reasons a page wasn't indexed, 2 warnings on pages indexed anyway, and 1 clean pass.
• On a Shopify build, most of that list (redirects, alternate canonicals, robots.txt blocks on /cart or /checkout) is normal duplicate-URL handling, not a bug.
• A handful of statuses (noindex, wrong robots.txt rule, wrong canonical, soft 404) mean your theme, app, or migration broke indexing on a live product page, and nothing in Shopify admin will tell you.

If you build or maintain Shopify stores for clients, you've probably had this conversation: the client says "we're not showing up on Google anymore," you open Search Console, and the Page indexing report shows hundreds of "Not indexed" URLs. Before you panic and start debugging, you need to know that most of that number is Shopify behaving exactly as designed: variant URLs, collection-scoped duplicate product URLs, tracking parameters. The report treats all 18 statuses with the same visual weight, so a completely benign one sits right above the one that means you or an app you installed accidentally deindexed a product the client is actively selling.

This is a reference for telling those apart during a build, a migration, or a routine client audit: what each status means per Google's own documentation, what produces it specifically on Shopify, and which ones are worth an incident, not just a shrug.

What is the Page indexing report actually counting?

Every status below is quoted from Google's documentation for the Page indexing report, read on August 15, 2026. Google updates this list over time, so treat these as current as of that date, not permanent. Three things about the report trip up devs who are new to it.

It's URL-level, not product-level. One product can appear under several reasons at once: as /products/handle, as /collections/summer/products/handle, as /products/handle?variant=123. Counting rows and comparing that number to the product count in the catalog tells you nothing.

It's an aggregate that lags. The report groups URLs by the state Google last recorded, which can be stale. A page can be fixed, recrawled, and reindexed while the report still shows the old grouping. A merchant on the Shopify Community ran into exactly this: they inspected a URL listed under "Crawled - currently not indexed" and the inspection said the page was indexed, prompting a confused thread in August 2024. Both tools were right about different points in time.

URL Inspection isn't live either, unless you ask it to be. Google states plainly that an inspection result is "from most recently indexed version of a page, not the live version on the web," and that pressing Test live URL is what makes it "a live test: the tool fetches and examines the URL in real time" (URL Inspection tool docs). When the report, the inspection, and the live test disagree, treat that as three timestamps, not three opinions, and trust the live test.

Which statuses are normal on a Shopify build (and when they're not)?

These five account for most of a typical store's "Not indexed" count. Each still has an exception worth checking during QA.

Alternate page with proper canonical tag. Google: "This page is marked as an alternate of another page… This page correctly points to the canonical page, which is indexed." On Shopify, this is mostly ?variant= URLs and collection-scoped product URLs pointing back at the clean /products/handle. The duplicate-URL system working as intended. Flag it if the canonical target listed is a different product, or the store's .myshopify.com domain instead of the storefront domain, since that means the canonical tag itself is wrong.

Page with redirect. Google: "This is a non-canonical URL that redirects to another page." Expected after handle renames, seasonal URL cleanups, and merges. Worth inspecting if a product URL redirects to the homepage or a collection instead of a replacement product; that pattern also silently drops the linked Merchant Center listing.

Duplicate without user-selected canonical. Google: "This page is a duplicate of another page, although it doesn't indicate a preferred canonical page. Google has chosen the other page as the canonical for this page, and so will not serve this page in Search." Usually parameter URLs from apps and recommendation widgets. Ilana Davis's writeup on when to ignore Search Console indexing issues on Shopify calls out URLs containing wpm or web-pixel-shopify-custom-pixel, plus ?pr_prod_strat= parameters, as safe to ignore. Filter those out before you look at anything else.

URL blocked by robots.txt. Google: "This page was blocked by your site's robots.txt file." Shopify's default robots.txt.liquid already blocks /admin, /cart, /checkout, /search, /policies/, and filtered collection URLs matching /collections/*+*, per Shopify's robots.txt documentation. Those entries are correct. The exception that matters most: a /products/ URL showing up under this status means someone added a rule that shouldn't be there. Shopify itself warns that "incorrect use of the feature can result in loss of all traffic," and since the file lives in the theme, a theme update or a careless edit can reintroduce a bad Disallow line without anyone noticing. Full mechanism here.

Discovered - currently not indexed. Google: "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." Common on a new store or right after a bulk catalog import; it's a queue, not a verdict. Worth a second look if product URLs sit here for weeks while the rest of the catalog crawls normally, since that usually means Googlebot's crawl budget is being burned on parameter URLs instead.

Which statuses mean you shipped a bug that's hiding a live product?

Anything below, on a URL for a product the client is actively selling, deserves a same-day fix.

URL marked 'noindex'. Google: "When Google tried to index the page it encountered a 'noindex' directive and therefore did not index it." This is the most consequential status for a Shopify build, because nothing in Shopify admin surfaces it: the product stays active, priced, and purchasable while being invisible to Google. Two known ways it gets applied: a theme conditional wrapping

<meta name="robots" content="noindex">

and a seo.hidden custom metafield, which Shopify documents as applying to "products, pages, or blog posts." Both survive a CSV import, and both can be set by an app without a visible admin toggle. Across full-catalog scans of more than 90,000 Shopify product pages, a stray noindex on live products is one of the most common critical findings. Full breakdown here.

Not found (404). Google: "This page returned a 404 error when requested." Correct and expected for a genuinely discontinued product. Worth checking in two cases: a handle that was renamed rather than retired (Shopify doesn't auto-redirect on a handle change), and a product deleted while it still had rankings and inbound links, since Shopify creates no redirect on deletion. More on that here.

Soft 404. Google: "The page request returns what we think is a soft 404 response. This means that it returns a user-friendly 'not found' message but not a 404 HTTP response code." Usually a theme or app rendering an "unavailable" or empty state on a URL that still returns HTTP 200. Worth grepping your theme's product template for conditionals that swap in an empty state without changing the status code.

Server error (5xx). Google: "Your server returned a 500-level error when the page was requested." Rare on Shopify's own infrastructure; at volume, this usually traces to an app proxy or a third-party endpoint the theme calls during server-side rendering. Check whether the errors cluster around an app's install date.

Redirect error. Covers "a redirect chain that was too long, a redirect loop, a redirect URL that eventually exceeded the max URL length, a bad or empty URL in the redirect chain." On a storefront, loops are usually two systems each trying to own the same redirect: a URL redirect rule set in Shopify admin pointing one way, and an app or locale rule pointing back.

Blocked due to unauthorized request (401). Google: "The page was blocked to Googlebot by a request for authorization." Usually points at a staging or preview environment, or an app proxy path sitting behind auth, rather than the live storefront. Note that a password-protected store is a separate mechanism: while the password page is active, Shopify states "search engines find and display only the password page," and other pages "are hidden and aren't displayed in search results" (Shopify docs). Worth double-checking a client didn't leave store password protection on after launch.

Blocked due to access forbidden (403). Google: "HTTP 403 means that the user agent provided credentials, but was not granted access." On a storefront, this usually means a bot-management or firewall layer applied at the domain level is filtering Googlebot's requests, not a Shopify setting.

URL blocked due to other 4xx issue. Google's catch-all for "a 4xx error not covered by any other issue type." Rare enough that it's worth inspecting the specific URL individually rather than pattern-matching.

Crawled - currently not indexed. Google's full description: "The page was crawled by Google but not indexed." Nothing blocked it; Googlebot read the page and declined to index it. This one alarms clients more than any other status, and it's mostly noise on Shopify since the URLs listed are usually duplicate surfaces. The work is in filtering: see the full breakdown of this status on Shopify products for how to tell a duplicate from a real failure.

Duplicate, Google chose different canonical than user. Google: "This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical." On Shopify this is structural: Shopify's own Liquid docs warn that "a standard product page and a product page in the context of a collection have the same content on separate URLs," and tell theme developers to consider the SEO implications of the within filter. If most of the theme's internal links point at the collection-scoped URL, Google follows that internal linking pattern over your canonical tag. More detail here.

What do the two "indexed anyway" warnings mean?

Indexed, though blocked by robots.txt. Google: "The page was indexed despite being blocked by your website's robots.txt file. Google always respects robots.txt, but this doesn't necessarily prevent indexing if someone else links to your page." The practical result is a search result Google can't describe, since it never read the page. If the blocked URL is a product, unblock it; don't add a noindex tag, since Googlebot is never allowed to fetch the page to see it.

Page indexed without content. Google: "This page appears in the Google index, but for some reason Google could not read the content. Possible reasons are that the page might be cloaked to Google or the page might be in a format that Google can't index." Rare, and serious on a product page: the URL sits in the index carrying nothing to rank with. Run a live test to see what Googlebot actually receives.

Page is indexed. The clean pass, and worth saying plainly: it says nothing about ranking, price display, review stars, or whether the matching Merchant Center listing is approved. Those are decided elsewhere.

How do you audit a client's Page indexing report step by step?

1. Read the reason, not the total. Open Indexing → Pages and ignore the headline count. The reasons listed underneath are where noise and real failures diverge.
2. Filter each reason down to product URLs. Look only for URLs containing /products/. Discard anything carrying wpm, web-pixel-shopify-custom-pixel, ?variant=, or ?pr_prod_strat=, and discard /cart, /checkout, /search, and /policies/.
3. Check the survivors against the live catalog. For every product URL still standing, confirm in Shopify admin whether it's active and for sale. A discontinued product under 404 is fine. A product the client sold this morning is not.
4. Inspect one affected URL, then test it live. Run URL Inspection for the indexed state and Google-selected canonical, then press Test live URL. If they disagree, your fix already landed and the report just hasn't caught up.
5. Match the status to its cause, fix the mechanism, then validate. Use the entries above to trace the label back to what produced it (a noindex directive, a Disallow rule, a dead handle, a collection-scoped duplicate), fix that, then use Validate fix so Google rechecks the group instead of waiting on a natural recrawl.

Why does this need to be a recurring check, not a one-time audit?

Every status above describes a state Google recorded in the past, on URLs it happened to look at. Nothing in this report fires on the event that caused the change. A theme update that reintroduces a Disallow line, an app that writes a seo.hidden metafield across a collection during a bulk edit, a handle rename during a catalog migration: each of these is routine work, invisible in Shopify admin, and shows up here days or weeks later as one row among thousands.

Running through this checklist once after launch is worth doing. But the report looks different next month for reasons nobody logged in a changelog, and the stores that get hurt aren't the ones that never checked; they're the ones that checked in March and had no reason to check again in July. Across full-catalog scans of more than 90,000 Shopify product pages, roughly 46% of stores carry at least one critical Google visibility issue, and roughly 73% carry at least one critical or warning-level issue. Worth baking this into whatever QA or handoff checklist you run for clients.

How do you currently catch this kind of regression on client stores: manual Search Console checks, a cron job, something else? Curious what other devs and agencies have wired up.

The full version of this article — with screenshots and ongoing updates — lives on the StoreCanary blog.