DEV Community: Max

Discovered, not indexed: the Shopify crawl bug clients hit

Max — Wed, 02 Sep 2026 11:56:15 +0000

TL;DR

"Discovered - currently not indexed" means Google found the URL but hasn't fetched it yet; it says nothing about content quality (that's the neighboring "Crawled - currently not indexed" status).
On Shopify the usual cause is URL inflation: recommendation tracking parameters, collection-scoped product URLs, and app-added query strings that the default robots.txt doesn't block.
The fix lives in robots.txt.liquid and internal link markup, not in rewriting product copy or spamming "Request indexing."

A client's Shopify store shows a growing pile of URLs stuck under "Discovered - currently not indexed" in Search Console, and nothing in the site throws an error. No noindex tag, no 404, no robots block anyone remembers writing. This status shows up on stores you build and maintain, not just ones you audit after the fact, because it's produced by defaults nobody chose: Shopify's Product Recommendations API appends tracking parameters to product links, collection pages create a second URL for every product they list, and apps bolt on filters and widgets with their own query strings. None of it is flagged as an SEO risk anywhere in the app install flow. This article walks through what the status actually means, why Shopify stores generate far more crawlable URLs than products, and the exact checks (view-source, robots.txt, sitemap counts) you can run against a client's store in about five minutes.

What does "Discovered - currently not indexed" actually mean?

Google's Page indexing report documentation defines it precisely: "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."

One word apart, and the fixes are opposite. A crawled page has been fetched and read, so its title, markup and content have actually been judged. A discovered page has been seen by nothing at Google. Editing product copy on a page in that state changes nothing, because the change isn't visible to the entity that put it in the queue. The first question to ask on a client's store isn't "what's wrong with these pages," it's "what is the crawler doing instead."

Why does Google flag this as a crawl-budget signal?

Google opens its large-site crawl budget guide by narrowing who needs it: "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." Two of the three qualifying conditions it lists are about raw size (a million pages, or ten thousand changing daily). The third isn't:

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

Google is naming the status itself as a qualifying condition, independent of catalog size. A four-hundred-product store isn't a large site by any normal reading, but if its Page indexing report is dominated by this status, it's in scope. The real question isn't how many products the client sells, it's how many addresses the store hands out for them.

Why does a Shopify store have more URLs than products?

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

Where do the recommendation tracking parameters come from?

Shopify's Product Recommendations API reference documents this directly: "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 docs:

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

Those parameters exist so Shopify's reports can attribute a sale to a recommendation strategy. The side effect: the same product page gets a distinct address for every combination of referring product and strategy. A Shopify Community thread from March 2024 describes roughly 80,000 parameter URLs discovered on one store. A case study by developer Eduard Fastovski describes a 200-product store that accumulated over a million indexed URLs (plus several million more not indexed) from ?pr_prod and ?filter parameters; after blocking both patterns: "It worked! Down to just 1k pages now, from 5 million!"

What lets this persist: Shopify's default robots.txt blocks the recommendations endpoint, not the URLs it hands out. Checking the live robots.txt of two unrelated Shopify stores shows the standard Disallow: /recommendations/products rule, and no rule matching pr_prod_strat, pr_rec_id, pr_rec_pid, pr_ref_pid, or pr_seq. The Ajax endpoint is closed; every product URL carrying those params, wherever it's linked from (a theme section, an app, a third-party sitemap), stays fully crawlable.

Why do collection-scoped product URLs duplicate every product?

Shopify creates a second address whenever a product card links through its collection: /collections/summer-sale/products/linen-shirt alongside /products/linen-shirt. Shopify's own Liquid reference for the within filter warns: "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 be reached at seven addresses. The default robots.txt blocks sorted and filtered collection URLs (Disallow: /collections/*sort_by*, Disallow: /collections/*+*), but nothing blocks /collections/*/products/*. Those URLs carry a canonical tag pointing back at the clean product URL, which is correct, but a canonical is only readable after a fetch. Consolidating them still costs a crawl each.

What URLs are your client's apps adding without telling anyone?

The default file blocks named patterns, not parameters in general: oseid, preview_theme_id, preview_script_id, a specific duplicated ls= shape, sorted/filtered collections, and /search. Any parameter an app or theme introduces outside those patterns is crawlable by default: a filter app with its own query format, a "recently viewed" widget, a wishlist link, a campaign parameter that leaks into an internal link instead of staying outbound-only. No app declares its URL footprint at install time, so this is invisible until it shows up in Search Console weeks later.

How do you check a client's store in five minutes?

Read the shapes, not the count. Open Page indexing, select Discovered - currently not indexed, and bucket the sample URLs: clean /products/…, collection-scoped /collections/…/products/…, and anything with a ?. The proportions tell you which mechanism above is dominant.
Compare what Google knows against what the sitemap declares. Add the indexed and not-indexed totals, then open yourstore.com/sitemap.xml. Shopify auto-generates it with separate child sitemaps for products, collections, blogs, and pages. If Google knows an order of magnitude more URLs than the sitemap declares, the surplus arrived through internal links.
View source on a product page and search for pr_prod_strat. If the theme renders a recommendations block into the page, the parameters sit in the href attributes. Search for pr_rec_pid too.
Read yourstore.com/robots.txt properly. Check whether anything blocks the parameter shapes from step 3, and whether a past edit went further than intended. Shopify's own help page warns that "Incorrect use of the feature can result in loss of all traffic."
Inspect one clean product URL, not fifty. Run URL Inspection and note the last crawl date. Google's documentation states this "is not a live test" and that there's "a daily limit of inspection requests for each property." One URL is a diagnosis; a full catalog isn't auditable this way.

How do you fix each cause?

Parameter URLs. Two real options, with a trade-off. Strip the parameters at the theme level (loses the conversion-funnel attribution those params exist for), or block the shapes in robots.txt.liquid (keeps tracking working for real visitors, stops Google from fetching them). Google's guidance is explicit about method: "Block crawling of URLs using robots.txt," and separately, "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 worse. Edit robots.txt.liquid carefully and re-check it after theme updates, since it's theme code and a theme change can silently overwrite your edit.

Collection-scoped duplicates. Where a product card doesn't need collection context, link to the plain product URL instead of the collection-scoped one. Google's crawl guidance: "Eliminate duplicate content to focus crawling on unique content rather than unique URLs."

Products that are genuinely gone. Return a 404 or 410, per Google's guidance, rather than redirecting a deleted product's URL to something convenient, which just keeps a competing URL alive in the queue.

Server response. Google's own definition of the status mentions overloading the site as a possible cause. Efficient page loads, HTTP caching, and 304 responses all matter here; heavy third-party scripts and app-injected assets are usually the biggest levers you actually control.

What not to do: don't work down the list requesting indexing on every URL. Google states "Submitting a request does not guarantee that the page will appear in the Google Index," and the daily limits make a catalog-sized pass impossible anyway. It's a diagnostic tool, not a remedy, and it leaves the underlying crawl surface untouched.

Why does this bug keep coming back after you fix it?

Every mechanism above comes from ordinary store maintenance, not a one-time mistake. 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 gets deleted and redirected instead of allowed to 404. None of it announces itself, and the crawl surface only grows unless someone deliberately shrinks it. Worth building a recurring check into your maintenance routine (robots.txt diff after theme updates, periodic sitemap-vs-indexed count) rather than treating this as a one-time cleanup.

Has anyone found other URL shapes leaking through a Shopify store's default robots.txt, beyond the recommendation params and collection-scoped duplicates covered here?

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

The Shopify structured data bug that gets clients suspended

Max — Mon, 31 Aug 2026 11:56:45 +0000

TL;DR

Merchant Center suspends an account for "Misrepresentation" without naming a product and without a warning period; Google's own policy states accounts are "suspended upon detection and without prior warning."
The policy has a clause unrelated to business identity: it forbids offering products you can't deliver and points directly at the availability and price attributes in Google's product data specification.
On a Shopify build, those two attributes come from four separate mechanisms (theme, the structured_data Liquid filter, any app injecting its own markup, and the feed), and nothing forces them to agree.

If you build or maintain Shopify stores for clients, this is the bug report you never get. Merchant Center suspends an account for "Misrepresentation," with no product name, no line item, no warning period, just Shopping ads and free listings dropping to zero. Most of what ranks for this error points at business identity: refund policy, contact page, real business name at checkout. Worth checking, genuinely required, and not the whole story.

The same policy also forbids offering products a shopper can't actually buy, and it refers directly to two feed attributes: availability and price. On a Shopify build those values come from four different places, and nothing reconciles them automatically. This piece covers where that agreement breaks in a typical Shopify build, how to audit a client's store for it in a few minutes, and what to fix before requesting Google's re-review.

Why doesn't Merchant Center name the product that broke the rule?

Most Merchant Center issues arrive with a warning period and specific examples. Google's documentation on warnings and suspensions describes products continuing to appear "however their performance may be limited," with emails pointing at what to fix. Misrepresentation doesn't work that way. Its policy page classifies these violations as egregious and states that accounts "will be suspended upon detection and without prior warning." Shopify's own page on Google disapprovals and warnings lists this under "Unacceptable business practices" and notes that "Deadline extensions aren't granted for any violation."

So there's no missing notification setting to find. The enforcement acts first and explains later, which leaves you reading the policy text itself instead of an email with an example. A Shopify Community thread opened in February 2026 and still active months later captures it directly: Google "continues to flag my account for 'Misrepresentation' without providing specific details on what's wrong or how to fix it."

What does the misrepresentation policy actually require?

Most guides for this suspension point at business identity. Shopify's requirements page for the Google & YouTube channel spells it out: refund policy and terms of service "available in your footer menu," plus contact information "visible to customers" via "at least one contact method such as email address, phone number, mailing address, or a contact form." Check that first, it's cheap and well documented.

But the policy has a second clause with nothing to do with identity: "Offer products that you don't have or can't deliver" is listed as an unacceptable business practice, and the unavailable-offers section forbids "Promising products or promotional offers that aren't available for users" (examples: promoting unstocked products, expired deals, or a call-to-action that "isn't easily achievable from the landing page"). The policy then refers you to the product data specification's availability and price attributes for "specific guidelines to comply with this policy."

That specification asks you to "accurately submit the product's availability and match the availability from your landing page, checkout pages, and structured data," and the same for price. Four surfaces (feed, landing page, structured data, checkout) have to agree with each other and with what you can actually ship. On a Shopify store those four are produced by four different mechanisms, and nothing reconciles them.

Where does a Shopify build break that requirement?

These are mechanisms that can make the four surfaces disagree, not proof of what triggered any specific suspension. Google doesn't publish which signal caused a given account action.

Continue selling when out of stock

Shopify's docs on selling out-of-stock products describe this setting plainly: enable it in the Inventory section of a product or variant, and customers can buy at zero inventory or below. It's a legitimate setting for stock arriving soon or inventory tracked elsewhere, but with it on, every surface agrees on the wrong answer. The page offers the item, add-to-cart works, the structured data reports it available, the feed says in stock. Nothing is internally inconsistent, the store is just promising goods it doesn't hold, and the spec asks for availability that's accurate, not merely consistent.

The setting is per-variant, too. Toggle it on during a stockout, sell through, restock, and it stays on for that one variant with nobody noticing.

Duplicate or stale structured data

Shopify generates Product markup through the Liquid structured_data filter, which emits an offer object like this:

"offers": {
  "@id": "/products/crocodile-tears?variant=39888242344001#offer",
  "@type": "Offer",
  "availability": "http://schema.org/OutOfStock",
  "price": "56.00",
  "priceCurrency": "CAD",
  "url": "https://.../products/crocodile-tears?variant=39888242344001"
}

On a stock theme that availability value tracks the variant correctly. It breaks the moment a second Product block enters the page, from a review app, a rich-snippet app, or a theme section with a hardcoded InStock value, and Google reads a claim the store never intended to make. This is the account-level version of a mismatch covered in more detail at the item level, in the availability mismatch between Shopify and Google Shopping.

One offer, many prices

The structured_data filter emits a single offer, for a single variant, with a single price. A product whose variants span a wide range declares only one of those prices in its markup. A shopper landing on a different variant sees a different number than the one Google received, and the spec requires price to match the landing page, structured data, and checkout. Related failure modes: the on-page price mismatch trap and a price of zero reaching Google.

Redirects on discontinued product URLs

The unavailable-offers clause also covers the landing page itself: a call-to-action that "isn't easily achievable from the landing page." On Shopify this usually means an out-of-stock or discontinued product URL redirecting to a collection or the homepage instead of returning the product page, so a shopper who clicks through from a listing can't reach the item at all. More detail on that failure mode: when a product page redirects to your homepage.

How do you audit a client's store in five minutes?

Copy the exact issue name from the policy area of Merchant Center. An account-level misrepresentation issue reads differently from a product-level disapproval, and the fix differs too.
Pick five out-of-stock products and compare four surfaces for each: what the feed reports, what the page shows, the availability value in the page's JSON-LD, and what happens on add-to-cart.
Check the Continue selling setting on the Inventory section of each product or variant.
View source on a product with a wide variant range and read the price inside the offers object; compare it to the cheapest and most expensive variant.
Open a discontinued product's URL directly and check whether it redirects instead of returning the product page.

How do you fix each issue?

Overselling. Decide deliberately which products may oversell, and turn the setting off everywhere else. For products that genuinely ship later, use the spec's preorder or backorder availability values instead of claiming stock that isn't there.

Duplicate markup. Find the second Product block before editing the first. It's usually coming from an app, and removing the app's block is easier than trying to make the theme's output match it.

Price coverage. If variants span a wide range, the real fix is markup that declares the range instead of a single figure. Until that's built, know which products are affected before touching the theme.

Redirects. Let a product that no longer sells keep returning its own page (out of stock, priced) instead of redirecting away. The spec notes that even when a product is out of stock, "the price must still be clearly visible on the landing page," which only works if the page still exists.

Then request the review, not before. Google's docs and Shopify's both give the same figure: reviews "can take up to 7 days to complete." A re-review on a store that hasn't actually changed spends a week to land back where it started.

Why does this bug keep coming back after launch?

Every mechanism above comes from ordinary work, not a code review failure. A stockout on a Friday turns on Continue selling, and the restock doesn't turn it back off. A new reviews app adds a second markup block. A supplier drops a line and someone redirects the URL to keep things tidy. A variant gets added well above the price sitting in the markup. None of it throws an error in Shopify admin, and none of it throws one in Merchant Center either, because for this policy Google doesn't warn, it suspends.

It's worth being precise about what an automated scan can actually tell you here. The misrepresentation policy covers business identity, intent, and whether a merchant can really ship what's listed, none of which is readable from public pages. What is readable is the product-data half the policy points at: a page whose markup claims InStock while every variant shows sold out, or a page whose declared price contradicts what the page itself renders. That's one input into an account-level judgment, not the judgment itself. Treat anything sold to you as a "misrepresentation checker" with the same skepticism.

Have you shipped a Shopify feature that quietly broke a client's availability or price data without throwing an error? What caught it: an audit, a client complaint, or a Merchant Center suspension?

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

The Shopify structured data bug your JSON-LD checks miss

Max — Thu, 27 Aug 2026 11:56:07 +0000

TL;DR

Search Console's "unparsable structured data" means a syntax error made Google discard the entire markup block, not just one bad field, and Google is explicit that every item in that report is a critical error, never a warning.
On Shopify, the usual causes are three specific mistakes: a trailing comma, unescaped characters (quotes, line breaks) inside a product title or description, or two JSON-LD objects concatenated in the same <script> tag without an array wrapper.
You can tell whether the theme or an app produced the broken block by copying a text fragment from it and searching for that fragment in Online Store → Themes → Edit code.

If you build or maintain Shopify storefronts for clients, you've probably seen this line in Search Console and had no clean way to trace it: "unparsable structured data." It's one of the few reports where Google states severity plainly, every item listed is a critical failure, not a warning. The frustrating part is that nothing on the rendered page looks broken. No console error, no visual regression, no failed build. A single stray character in a Liquid snippet, or a JSON-LD block an app injects at runtime, quietly invalidates the whole document, and the client's product schema (price, availability, rating) disappears from how Google reads the page, with no trace in a normal QA pass.

This post covers the three syntax errors that actually cause this on Shopify, how to figure out whether it's your theme code or a third-party app, and how to fix and revalidate it.

What does "unparsable structured data" actually mean?

Google's own definition is unusually direct. The report lists structured data that "could not be parsed because of a serious syntax error", and "the intended type of structured data (Job, Event, and so on) could not be determined because of the parsing error." Google isn't flagging a schema mismatch here. It saw a markup block, failed to parse it as JSON, and couldn't even tell what it was supposed to describe.

The same page adds a detail worth building process around: "All items in this report are critical structured data errors; there are no warnings or valid items." There's no severity triage to do. Anything that shows up here is broken.

What does the client actually lose when a block fails to parse?

The page stays indexed and keeps ranking on its text content. What disappears is everything that specific block declared. If the failing block was the Product markup, the price, availability, and rating it carried are simply absent as far as Google is concerned, and the page loses eligibility for the rich result it used to qualify for. Where a Merchant Center feed depends on on-page data, the product can drop out of that feed too.

This is why the bug usually surfaces sideways: someone notices review stars vanished from a listing, or a client asks why a competitor's price shows up in search but theirs doesn't, and the root cause traces back to a schema block that stopped parsing weeks earlier.

Which syntax errors cause this on Shopify themes?

Two JSON documents concatenated. The theme writes one Product object into a <script type="application/ld+json"> tag, and an app appends a second object into the same tag with nothing separating them:

<script type="application/ld+json">
{"@type":"Product","name":"Wool Beanie"}{"@type":"AggregateRating","ratingValue":"4.5"}
</script>

Two valid objects placed back to back are not valid JSON. Both get discarded. The fix is either separate <script> tags or wrapping both in a @graph array.

A trailing comma.

{
  "@type": "Offer",
  "price": "24.00",
  "priceCurrency": "USD",
}

That trailing comma after "USD" invalidates the entire document, not just that line. It's the single most common hand-edit mistake in a Liquid snippet.

Unescaped characters inside a value. A product title containing a straight double quote or a line break, interpolated into JSON without escaping:

"name": "{{ product.title }}"

If product.title is Men's "Classic" Wool Beanie, that renders broken JSON. This one is the sneakiest because it only breaks on the products whose text happens to contain the offending character, so it looks intermittent until you spot the pattern. The reliable fix is Shopify's json filter instead of raw interpolation:

"name": {{ product.title | json }}

| json handles escaping for you and also gets you correct quoting (no manual ".." wrapper needed).

How do you find whether the theme or an app injected the broken block?

Once a validator has shown you the failing block, copy a distinctive text fragment from it and search for that fragment in Online Store → Themes → Edit code.

If the fragment is in the theme files, the theme is generating the block and you can fix it directly. If it appears on the rendered page but nowhere in the theme source, an app is injecting it at runtime, editing theme code won't touch it. The fix in that case is in the app's own settings (most reviews, SEO, and social apps have a toggle for structured data output) or a support ticket with the app vendor.

This distinction matters for maintenance, not just for the immediate fix. A theme fix stays fixed until someone edits the theme again. An app fix can be silently undone by the app's next update, so it's worth re-checking after any app update rather than treating it as a one-time fix.

How do you check and fix it end to end?

Paste the affected product URL into validator.schema.org and read the exact parsing error, plus which block it belongs to.
Copy a unique fragment from that block and search for it in Online Store → Themes → Edit code to determine theme vs. app.
If it's the theme: remove the trailing comma, switch raw interpolation to | json, and wrap multiple objects in an array instead of concatenating them.
If it's an app: disable its structured data injection in its settings, or send its support team the validator output.
Revalidate on validator.schema.org, cross-check with the Rich Results Test, then open the error in Search Console and click Validate Fix. Google notes validation "typically takes up to about two weeks, but in some cases can take much longer," the fix itself is live immediately, only the report is slow to catch up.

Because the symptom is invisible on the page, the useful habit isn't checking when something looks wrong, it's checking after any change that touches the theme or the app list. A theme update, a new reviews app, a bulk product import: any of those can introduce a stray character into a block that had parsed cleanly for a year.

Have you traced one of these back to a specific app before? Curious which ones are the repeat offenders in your stack.

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

The Shopify Product schema gap that breaks shippingDetails

Max — Wed, 26 Aug 2026 11:56:54 +0000

TL;DR

Shopify's built-in Liquid structured_data filter never emits shippingDetails or hasMerchantReturnPolicy inside the Offer object, on any theme, out of the box. It's a filter limitation, not a misconfiguration on a specific client site.
Both fields are "recommended," not "required." Search Console still lists the product as valid; the only thing missing is the shipping/returns annotation on the listing itself.
Google reads shipping/returns data from four sources in strict precedence (Content API for Shopping, then Merchant Center/Search Console settings, then product-level markup, then Organization markup). Pasting a snippet into a client's theme often changes nothing if a higher-priority source is already set, and only a Shopify store's "General" shipping profile syncs correctly to Merchant Center.

If you build or maintain Shopify stores for clients, you've probably run into this Search Console warning: shippingDetails and hasMerchantReturnPolicy missing from Merchant listings, across an entire catalog, on a store you just launched. It's not a content problem on the client's end. Shopify's built-in Liquid structured_data filter never emits these fields in the Offer object, on any theme, by default. The usual fix, pasting a shipping/returns block into the product template, is a real fix for a real symptom, but it often targets a layer Google isn't even reading. This piece covers why the fields are absent, why they don't actually invalidate a product, the four-source precedence order Google uses for shipping and returns data, a Shopify-specific shipping profile trap that silently desyncs rates from Merchant Center, and a five-minute audit you can run on any client account.

Why doesn't Shopify's offer markup include shipping and returns fields?

Shopify generates product JSON-LD through the Liquid structured_data filter, and its documented output is short. Inside offers it emits exactly six properties:

"offers": {
  "@id": "/products/crocodile-tears?variant=39888242344001#offer",
  "@type": "Offer",
  "availability": "http://schema.org/OutOfStock",
  "price": "56.00",
  "priceCurrency": "CAD",
  "url": "https://…/products/crocodile-tears?variant=39888242344001"
}

No shippingDetails, no hasMerchantReturnPolicy, no priceValidUntil. This isn't something you find and undo in the theme code: it's absent by construction on any theme using the built-in filter, which offers no option to add it. That's why the warning covers a client's whole catalog on day one, on a store nobody has customized yet.

Does this actually invalidate the product for search?

No. Google's merchant listing structured data docs list both fields as recommended properties of Offer, not required ones. The required set is small: name, image, offers on the product, plus a price and currency inside the offer.

Search Console's rich result reports reflect that split directly: critical issues sit in a table called "Why items are invalid," non-critical ones in "Improve item appearance." Google's own definition: "A valid item is an item that doesn't have any critical issues and can appear on Google as a rich result." A product flagged only for these two fields stays valid and eligible.

So the real cost is narrower than the warning implies: the client loses the delivery/returns annotation Google can attach to the listing, the kind sitting under a competitor's product. That's a different failure class from a block Google can't parse at all, which gets discarded outright along with everything inside it.

If I paste the markup into the theme, why does nothing change on the listing?

Because Google reads shipping and returns data from four sources, in a fixed order of precedence, per its docs for return policy and shipping policy structured data:

Content API for Shopping account-level settings
Settings in Merchant Center or Search Console
Product-level merchant listing markup (the snippet you'd paste into the theme)
Organization-level markup

Google states the consequence directly: "if you provide both return policy markup on your site and return policy settings in Search Console, Google will only use the information provided in Search Console." The shipping docs say the same about shipping.

If the store is connected to Merchant Center, which the Google & YouTube sales channel requires, level 2 is already occupied, and the theme edit only reaches level 3. It's not wasted work: it clears the Search Console warning, it helps any engine reading the page directly, and it's the only option for a store with neither Merchant Center nor Search Console settings configured. But it explains a pattern that looks like a bug and isn't one: the snippet goes in, the warning clears, and the actual listing doesn't move.

Where does Google actually want this markup, if you implement it at all?

Not where most implementations put it. Google's own recommendation, repeated for both fields on the merchant listing page: "We recommend you provide a global shipping policy for your business under Organization markup instead." A standard, business-wide policy belongs in Organization markup (ShippingService under hasShippingService, MerchantReturnPolicy for returns); per-product Offer markup exists to override that default for a product that genuinely differs, and it supports a smaller set of properties than the Organization-level version.

The common Shopify pattern, a shipping block duplicated into every product page by a Liquid loop, is the exception case implemented as the default, at the lowest-priority level.

There's also a newer path, from Google's November 2025 post "More ways to share your shipping and returns policies with Google": set the policies directly in Search Console under Settings > Shopping > Shipping and returns. Its help page states "You don't need to create a Merchant Center account to configure shipping and returns," but also that policies "created or edited in Merchant Center won't be available in Search Console, and can only be managed in Merchant Center." Once a client connects the Google & YouTube channel, that door closes behind them.

Why does the shipping rate Google shows differ from what the client charges?

This is the Shopify-specific trap underneath the fix, documented by Shopify rather than Google. From the Google & YouTube channel requirements: "Only shipping rates in your General shipping profile can sync to Google Merchant Center. If you use custom shipping profiles, then rates will sync incorrectly with Google Merchant Center and cause errors."

Custom shipping profiles are ordinary store maintenance: one for oversized items, one for a dropshipped line, one for a supplier with different delivery times. The moment a product moves into one, the rate Google receives stops matching checkout. Nothing is technically wrong in the store; the rates just aren't the ones being synced.

Worth checking before touching anything else: Merchant Center can infer a return policy without an explicit upload, shown as a "For most items" annotation. A client's listings may already display returns info while Search Console keeps flagging the field missing from theme markup, this whole article's argument compressed into one symptom.

How do you audit this on a client's store in five minutes?

Read the actual markup. View source on a product page, find the JSON-LD block, look inside offers. Six properties and nothing about shipping or returns means the store is on the stock filter output.
Check which table the warning sits in. Merchant listings report in Search Console: "Improve item appearance" means non-critical; "Why items are invalid" means something else is broken.
Find the authoritative source. Is a Merchant Center account connected via the Google & YouTube channel? Is there already a policy under Settings > Shopping > Shipping and returns in Search Console? Whichever exists outranks theme markup.
Compare the synced rate against the real one. Check Merchant Center's shipping settings against what a shopper is actually charged at checkout for the same product and destination.
Check the Shopify shipping profiles. Settings > Shipping and delivery. Any product sitting in a custom profile instead of General is a rate Google isn't receiving correctly.

What's the actual fix, and does it depend on the client's setup?

If they use the Google & YouTube channel: set shipping and returns in Merchant Center and treat it as the source of truth. Keep the rates Google needs in the General shipping profile, or enter them manually in Merchant Center instead of importing (safer once custom profiles exist). Theme markup on top of this is cosmetic, not the fix.

If there's no Merchant Center account: use Settings > Shopping > Shipping and returns in Search Console. It outranks markup and is far less fragile than theme code.

If you're implementing the markup anyway (for engines reading the page directly, or because neither of the above exists): declare the standard policy once, sitewide, in Organization markup, and reserve per-product Offer markup for genuine deviations. Whatever gets declared has to match what the client actually charges. A hardcoded "free shipping" block on a store that charges for shipping is worse than the original warning: it's a promise to the shopper that checkout then breaks.

Why does this keep coming back after you close the ticket?

Four sources, a documented precedence order between them, and no single screen that tells you which one Google used today. A theme update replaces the file holding the markup. A new supplier shows up and someone creates a custom shipping profile. Someone edits rates in Merchant Center and the store's live rates drift from them. Each change is routine, done correctly, in isolation, and none of it throws an error in Shopify admin.

Worth flagging to clients as ongoing monitoring rather than a one-time fix: a product missing shippingDetails and hasMerchantReturnPolicy is informational and still sellable, but worth a periodic recheck instead of a single pull request.

Have you run into this on a client's store, and did fixing Merchant Center settings actually change what shoppers saw, or just clear the warning? What caught it for you, a client complaint or a routine audit?

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

The Shopify Search Console statuses that mean you shipped a bug

Max — Tue, 25 Aug 2026 11:57:04 +0000

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?

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.
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/.
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.
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.
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.

The Shopify zero-price bug that breaks Merchant Center feeds

Max — Mon, 24 Aug 2026 11:56:06 +0000

TL;DR

Merchant Center's "Invalid value for category [price]" fires whenever the price attribute Google receives is exactly 0; the only documented exception is mobile devices sold under a contract promotion.
On Shopify the zero comes from one of two unrelated causes: an unfilled variant price (a data issue, no code involved) or a theme's JSON-LD snippet reading a variable that can resolve to empty (a code bug that hits every product page).
Scanning structured data across 90,000+ Shopify product pages, roughly 1 in 5 stores had at least one page emitting a zero price, usually on a small slice of the catalog, which is exactly why spot-checking a few products rarely catches it.

If a client's Shopify product silently drops out of Google Shopping, or picks up a "Invalid value for category [price]" disapproval in Merchant Center, don't start by re-checking the price field in admin. Start with the structured data the page actually serves. Google flags this error when the price attribute it receives is 0, a value it never treats as a real offer. On Shopify that zero rarely shows up where you'd expect it: it's usually buried in one variant nobody filled in, or it's a theme snippet reading a variable that can resolve to empty even when the admin price is correct. Both produce the identical Merchant Center error, and only one of them needs a code fix.

This post covers how to tell which cause you're dealing with on a client's store, and how to fix each.

What does "Invalid value for category [price]" actually mean?

Google's own documentation is blunt about it: the issue "occurs when you've entered 0 for the price [price] attribute." There's exactly one exception, for a mobile device sold as part of a contract or promotion, where a price attribute of 0 is allowed. Outside that case, a price of zero isn't a valid commercial offer, so Google rejects the item outright.

Why does this bug hide from spot-checks?

It's a loud failure with a quiet distribution. It rarely touches a whole catalog; it usually touches a handful of products inside a catalog that otherwise looks fine. Across a scan of more than 90,000 Shopify product pages, roughly one store in five had at least one page declaring a price of zero in its structured data, and in the typical case the affected pages were a small fraction of that store's catalog.

That combination, widespread across stores but nearly invisible within any single one, is why it survives. Opening a few products in admin to eyeball the price almost never lands on the broken one.

Cause 1: is the variant price actually empty?

Someone created the product as a draft with a placeholder price and never filled it in, or added a variant later and left its price blank. Admin is telling the truth here, and the markup is faithfully reporting it. This is the mundane case: no code change needed, just set the price.

The detail that catches people out is that it's usually one variant, not the product. A product whose first variant is priced correctly looks entirely normal at a glance, while a second or third variant sits at zero and drags the whole item into a disapproval.

Cause 2: is the theme reading the wrong price variable?

Here admin is correct and the markup still says zero. The theme's JSON-LD snippet is reading a field that can be empty instead of the one that always resolves to the displayed variant. In Liquid, that means checking whether the snippet uses something like:

"price": "{{ product.selected_or_first_available_variant.price | money_without_currency }}"

rather than a raw product.price, product.variants.first.price, or any field that can be nil when a variant is out of stock or unpublished. product.selected_or_first_available_variant is the one that reliably matches what's rendered on the page.

This version is the one worth flagging in a code review, because it isn't a one-off data mistake, it's a snippet that runs on every product page on the store. It also survives every correction made in admin, which is what makes it confusing to debug from the client side: they fix the price, the price is right, and Google keeps rejecting the item anyway.

How do you tell which one you're looking at?

Run the product URL through the Rich Results Test and read the price field on the detected Product. That's the number Google actually receives, not the one typed into admin.

Open the same product in Shopify Admin → Product → Pricing and check every variant, not just the first.
If a variant has no price, that's your answer: set it.
If every variant price is correct in admin and the markup still shows 0, the bug is in the theme snippet: confirm it reads product.selected_or_first_available_variant.price.

What's the actual fix, and how do you confirm it?

For the data case, filling in the missing variant price is the entire fix. For the code case, correcting the JSON-LD variable fixes every product on the store at once, so it's worth doing properly rather than patching one product's snippet.

Either way, revalidate with the Rich Results Test before telling the client it's resolved, then let the Merchant Center feed refresh (or reupload manually). Affected items show up under the Needs attention tab once Google has re-crawled the feed.

How do you check an entire client catalog, not just one product?

Merchant Center's Needs attention tab only lists products that already reached a feed. A product that never made it into a feed can carry a zero price in its structured data indefinitely without ever surfacing in that report. If you're auditing a client's store, the structured data actually served on live product pages is the source of truth, not the feed diagnostics. This is worth building into any theme handoff or Merchant Center audit checklist, since it's cheap to check and easy to miss.

It's also worth distinguishing from two related failures: a price mismatch, where the page and the markup disagree on a real price, and a stale price, where the price is valid but out of date. A zero price is neither: the page and the markup usually agree, on a number that can't be right.

Have you run into this on a client's theme before, was it a missing variant price or a bad JSON-LD variable?

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

Shopify 'crawled not indexed': triage guide for agency devs

Max — Fri, 21 Aug 2026 11:58:37 +0000

TL;DR

Most URLs in the "Crawled - currently not indexed" report on a Shopify store are expected duplicates (collection-scoped product URLs, ?variant= parameters); their absence from the index is consolidation, not a bug.

A real /products/handle URL that survives triage usually has one of three causes: a canonical tag pointing elsewhere, thin content shared across many stores, or broken Product structured data.

The fix starts with filtering the export, not reading the raw count.

When you open Search Console for a client's Shopify store and see dozens of product pages sitting under "Crawled - currently not indexed," the immediate question is: platform quirk or actual indexing failure? The distinction matters because Shopify's URL architecture generates legitimate duplicates by default, and most of what fills this report falls into that category.

Google's own reference defines this status in one sentence: "The page was crawled by Google but not indexed." Compare it with the neighboring statuses. "URL blocked by robots.txt" is an access refusal you can switch off. "URL marked 'noindex'" is an explicit directive you can remove. This one is a judgment about the page's content and signals, and there is no switch for it.

This article gives you the triage process: which URL shapes to filter out immediately, the three root causes worth investigating on surviving URLs, and a five-step inspection checklist.

Why does this report fill up with URLs that aren't the problem?

A Shopify storefront generates far more URLs than it has products. Before reading anything into the count, export the report and filter to URLs containing /products/. Everything else is a separate question.

Two shapes in particular tend to dominate this list, and both are duplicates by design:

Collection-scoped product URLs. Shopify serves the same product at /products/handle and again at /collections/name/products/handle. Shopify's own documentation for the within filter says it directly: "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 with identical content, it picks one canonical and leaves the others out. That is expected consolidation.

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

If the entire list is these two shapes plus non-product URLs, the right action is none.

What causes a real `/products/` URL to stay unindexed?

Once you have filtered the list and real product URLs remain, there are three causes to check in order.

Does the canonical point somewhere else?

This is the one that looks like a content problem but is mechanical. If the page's <link rel="canonical"> points to a URL other than itself, Google treats the page as a duplicate. Run the URL through URL Inspection in Search Console and compare the User-declared canonical with the Google-selected canonical. If they differ, that is your answer. The canonical article covers why the collection URL often wins this comparison.

Does the page have unique content?

A product page carrying a supplier description shared verbatim across hundreds of stores gives Google little reason to add another copy to the index. This rarely has a code fix; it is frequently the real answer on dropshipped or catalog-imported stores. Sizing detail, materials, genuine reviews, and shipping specifics are the content that changes the calculation.

Is the structured data parsing correctly?

Worth eliminating before concluding anything about content quality. If the Product block has a syntax error, the whole declaration is invisible to Google, usually with no visible symptom on the page itself. The unparsable structured data article shows how a single stray character silently discards an entire block.

How do you triage this in five minutes?

Open Search Console > Indexing > Pages, click Crawled - currently not indexed, and export the list.
Filter to URLs containing /products/, then remove anything containing /collections/ or ?variant=. What remains is the list that matters.
Take one surviving URL and run URL Inspection on it. Compare User-declared canonical with Google-selected canonical. If they differ, you have the cause.
If the canonicals agree, open the page and assess what content exists there that does not exist anywhere else. If the honest answer is nothing, that is the finding.
Run the same URL through the Rich Results Test to confirm the Product structured data still parses.

The pattern behind most of these silent failures: the Shopify admin shows a healthy, active, priced product, while the public URL tells Google something different. This status is a per-URL decision, and that decision usually has a mechanical cause one layer below it.

Related:

Have you hit this on a client store? What was the root cause when you dug in?

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

Shopify product removed but still live in Merchant Center

Max — Wed, 19 Aug 2026 11:57:48 +0000

TL;DR

Deleting a product in Shopify removes it from the feed but sends no explicit delete to Merchant Center; the copy stays live until it expires (30 days after the last refresh) or is removed directly.

Google's automatic product discovery re-adds items without a feed if the URL still resolves with Product structured data on the page.

A 301 redirect (correct for SEO) keeps the Merchant Center landing page accessible, which blocks the "unavailable landing page" rule from automatically disabling the listing.

Your client deleted a product in Shopify. It is gone from the catalog, the collections, and the sitemap. It is still active in Google Merchant Center, still marked in stock, still eligible for Shopping ads and free listings.

The root cause: Shopify and Merchant Center are two separate systems holding two separate copies of product data. Deleting the Shopify original stops it from being submitted on the next sync. It does not propagate a delete instruction to the Merchant Center copy. What happens to that copy is governed entirely by Merchant Center's own rules.

This affects any store using the Google & YouTube channel or a feed-based integration. The merchant reports removed products still appearing in Shopping results. This article covers the three mechanisms that keep a removed product alive in Merchant Center, a five-step diagnostic to identify which one is active, and the correct fix per cause.

Why doesn't deleting in Shopify remove it from Merchant Center?

Your Shopify catalog is the original. Merchant Center holds a copy, submitted by a data source. Deleting the original stops it from being submitted on the next sync. What happens to the copy depends entirely on Merchant Center's own rules.

Shopify's documentation on syncing products describes the 30-day refresh cycle: "Google sets a strict 30-day expiry policy on synced product data, so the Google & YouTube channel updates your products automatically within that 30-day period." That describes how live products stay alive. A product that stops being refreshed hits that same 30-day expiry clock rather than disappearing immediately.

How do you confirm which mechanism is holding the listing?

Five steps, about five minutes:

In Merchant Center, open Products and search by title or product ID. Note the status (active, expired, disapproved): it tells you which rule is holding the item.
Open Data sources and check which source the item is attributed to. An item attributed to your channel feed and an item Google found on its own need different fixes.
Open the old product URL in a private window. Confirm whether it returns a 404, redirects somewhere, or still loads a product page.
If it still loads, view source and search for "@type": "Product". Structured data on a still-reachable page is a live route back into Merchant Center, independent of the feed.
Search Google for the product name plus the store name, then check the Shopping tab specifically. An item can disappear from Search and remain active in Shopping.

What four mechanisms keep the listing alive?

1. The removal has not propagated yet. Google's guidance on managing products in Merchant Center states that when a product is removed from a data source, "it may take 24-48 hours for your product to be removed from ads and free listings." If the deletion happened yesterday, this is inside the normal window.

2. Nothing told Merchant Center to remove it. Stopping a refresh differs from sending a delete instruction. The same Google page states that "All products expire from your Merchant Center account 30 days after the last refresh." An orphaned item keeps serving until that clock runs out. This is the cause behind reports of products deleted two months ago still appearing in Merchant Center.

3. Google found the product by itself. Google's documentation on adding products automatically describes the process: "We scan your website to find product pages", then "We read the structured data on those pages." The same page states Google checks for new products at least once every 24 hours. No feed is required. If the product page still resolves and carries Product markup, Google has a route to that item that the feed does not control. This is why a manual deletion sometimes reappears.

4. The landing page is still reachable. Merchant Center can remove a product with a dead destination via the "Product page unavailable" issue. A 404 triggers it. A single 301 redirect does not: the destination resolves cleanly, and the signal that would disable the Shopping listing never fires.

Why does the standard redirect advice block the auto-cleanup?

Redirecting a dead product URL to a live collection is the correct move for search: it recovers the shopper and the link equity. On the Merchant Center side, it also keeps the stale listing active because the landing page check now passes. Two pieces of correct advice that conflict: the SEO fix prevents the Merchant Center auto-cleanup from firing.

What is the correct fix per cause?

Remove at the source, then in the interface. Deleting only the Merchant Center copy leaves the data source free to resubmit the item on the next sync. Remove it from Shopify first, then clear the Merchant Center copy.
Archive instead of pause for discontinued products. Google documents archiving as removing a product "from your main product list, diagnostics, and from serving on Google surfaces." Pause is documented as short-term: treated as expired after more than two weeks, it is the wrong instrument for a permanently discontinued product.
Check the automatic source. In Data sources, look at what Google added from its own crawl. If the item is there, removing it from Shopify will not clear it. It returns for as long as a page with Product markup stays reachable at that URL.
Be deliberate about the old URL. Point a redirect at a genuine replacement product. Where there is no replacement, leaving the URL as a 404 is what eventually triggers the landing-page rule that disables the Shopping listing.
Re-check after 48 hours. The documented propagation window is 24-48 hours. Checking immediately or waiting a month both produce misleading conclusions.

One action to avoid: uninstalling and reinstalling the Google & YouTube channel clears the Merchant Center account, but it re-mints product IDs and discards the performance history tied to them. That is a real trade-off, not a free reset.

Why does this recur after every catalog cleanup?

Every catalog cleanup regenerates this problem. A discontinued line, a seasonal range, a rebrand that renames URL handles, a bulk delete during a migration: each creates a batch of products that exist in Google's copy but no longer in Shopify. Shopify admin cannot surface that discrepancy because the products are no longer in Shopify to display.

The same structural gap appears in the availability mismatch (Shopify says in stock, Google Shopping shows sold out): two systems holding two versions of the truth, with no alert on the gap between them.

Related reading:

Have you run into a case where Google kept re-adding a removed product through its automatic crawler? What ended up clearing it?

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

Shopify product drops from Google: 11 bugs to fix for clients

Max — Thu, 13 Aug 2026 11:59:34 +0000

TL;DR

Three independent systems control product visibility on Google: Google's crawler, Google's indexer, and Merchant Center. They fail independently and Shopify admin reflects none of them.

The 11 failure modes split across crawl blocks, indexing decisions, URL resolution errors, markup problems, and Merchant Center disapprovals.

Triage starts with site:<url> in Google, then URL Inspection in Search Console, before touching any code.

When a client reports that their products have disappeared from Google, you are dealing with one of eleven distinct failure modes spread across three systems that do not communicate with each other. Google's crawler, Google's indexer, and Merchant Center each make independent decisions about every product URL, and Shopify's admin reflects none of them. The product stays green and Active while it is gone from search.

This article maps all eleven failure modes, organized by which system is responsible: the crawler never fetched the page, the indexer fetched it and excluded it, the URL resolves to the wrong thing, structured data errors stripped rich results, or Merchant Center disapproved the listing. Each section names the exact mechanism and the diagnostic tool that confirms it. The triage section at the bottom walks through a five-step sequence to identify the responsible system in about ten minutes, before you change anything.

Which three systems control whether a product appears?

Google Search builds its index by crawling product pages. Whether a product appears in organic results depends on what the crawl found and what Google decided to keep.

Google Merchant Center is a separate pipeline. Shopping surface listings come from the feed, and Google's product data specification checks that feed against the live page, including price, availability, and structured data. A product can rank in web search and be disapproved in Merchant Center on the same afternoon.

The theme and installed apps generate what both systems read: the HTML, the canonical tag, the robots directives, the JSON-LD. Neither Google system tells Shopify when it rejects something, and Shopify does not inspect what either system concluded.

Why did Google never fetch the page?

1. A rule in robots.txt.liquid is blocking the crawl. Shopify generates robots.txt from a template inside the theme, so the file is theme code, not a store setting. Publishing a different theme changes what Google is served, and any app with theme-code access can rewrite it. When a Disallow covers product paths, Google stops fetching them and pages fall out over the following weeks.

One second-order effect worth flagging: a noindex directive on a page blocked in robots.txt is never read. Google's documentation is explicit: "if the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule, and the page can still appear in search results" (Google Search Central, block indexing). A crawl block can simultaneously hide pages you wanted indexed and keep pages you wanted removed. Full mechanism in the robots.txt walkthrough.

Why did Google fetch it but not index it?

2. Something set the product to hidden. Shopify documents a supported way to remove a product from search: a seo.hidden metafield set to 1. The metafield must be created as an Integer; created as text it is accepted without complaint but behaves differently. The newer Unlisted product status goes further, hiding the product from internet search, the sitemap, collection pages, storefront search, and recommendations, while keeping its direct URL alive. Both are legitimate features and both are what an app reaches for when it wants to hide something temporarily. Neither leaves a notice in admin. The phantom noindex article covers how to audit these at catalog scale.

3. Google picked a different URL as the canonical. Every Shopify product is reachable at /products/… and again at /collections/…/products/…. When theme links point at one and the canonical tag declares the other, Google resolves the conflict itself, and Search Console records the outcome as "duplicate, Google chose different canonical". The URL you were watching was not the selected canonical; the product itself still exists under the other path. See the canonical mismatch piece.

Why did Google never discover the URL?

4. The product is not in sitemap.xml. Shopify generates the sitemap automatically, which is exactly why nobody checks it. A product can drop out of the file while remaining active, priced, and purchasable, and Google gradually stops arriving. The sitemap article covers what pulls a product out and how to confirm it in under a minute.

Why does the URL resolve to the wrong thing?

5. The product was deleted or its handle changed. Shopify does not create a redirect when you delete a product; the URL returns 404. Google can keep showing the old entry for a long time, so shoppers click a live-looking result and land on nothing. The deleted-product guide covers how to clear these rather than waiting them out.

6. An out-of-stock app is redirecting the page. A 301 from a temporarily sold-out product to the homepage looks tidy in admin and is a landing-page failure everywhere else. Merchant Center is direct: a product is disapproved when it specifies "a landing page (via the link attribute) that cannot be crawled by Google", including when "the landing page returns an HTTP error when crawled" (Merchant Center Help). See the redirect case study.

Why is the product indexed but stripped of rich results?

7. The rating markup broke and stars disappeared. Google's review snippet documentation requires aggregateRating to carry a ratingValue plus either ratingCount or reviewCount, and requires that the review content be visible on the page. A theme that paints visual stars with nothing machine-readable behind them satisfies the shopper and not the parser. The review stars article lists the five causes seen in practice.

8. The price in the result is stale or absent. For merchant listing markup, Google requires only price and priceCurrency; availability, priceValidUntil, shippingDetails, and hasMerchantReturnPolicy are recommended rather than required. The optional fields are also the ones Shopify never prompts you to emit, and their absence is what leaves a price looking expired. The priceValidUntil article covers this in detail.

Google's guideline applies to both: "Your structured data must be a true representation of the page content." Marking up content not visible to readers can draw a manual action that costs the page its rich-result eligibility (structured data general guidelines).

Why did Merchant Center drop it while organic search kept it?

9. Price mismatch. A page can carry more than one price: the theme's JSON-LD, a discount app's markup, and the visible price can disagree. Merchant Center disapproves the inconsistency. The price mismatch trap explains how three prices end up on one page.

10. Availability mismatch. Shopify's inventory and the feed update on different schedules. A restocked product can sit at "out of stock" in Shopping for hours or days. The specification requires availability to match across the landing page, checkout, and structured data; a drift in any one is a failure. Details in the availability mismatch article.

11. Missing product identifiers. A blank GTIN, MPN, or brand does not always disapprove a product. Depending on the category, it can instead limit how often the listing appears, which is harder to notice than an outright rejection. The identifiers article explains the two tracks.

How do you identify which failure you are dealing with in ten minutes?

Run these in order and stop at the first that gives you an answer. The goal is to identify the responsible system before changing anything, because a fix aimed at the wrong layer is indistinguishable from no fix at all.

Check whether the URL is indexed. Search Google for site: followed by the exact product URL. A result means the page is in the index and the problem is downstream. No result means the problem is crawling, indexing, or discovery.
Inspect the URL in Search Console. URL Inspection names the reason directly. Its rendered view is the only reliable check: a raw view-source is not proof either way, because a theme or app can inject or strip a canonical, a robots meta, or structured data after the initial HTML.
Read the page indexing report by reason, not by URL. The report groups URLs by why they are not indexed, separating a crawl block from an indexing decision from a canonical choice. Reading by reason tells you whether one product broke or a rule broke across many.
Test the page in the Rich Results Test. This shows whether the product markup parses and what it contains, which is where a missing price or absent aggregateRating becomes visible.
Check the item separately in Merchant Center. A disapproval or limited-performance warning is an entirely separate verdict from Google Search, and neither system reports the other.

Why does this recur after every theme update or app install?

Nearly every fix above is small: delete a Disallow line, change a metafield, emit one more field in the offer.

The harder part is what triggers these in the first place. Theme updates, app installs, bulk edits, feed syncs, new collections that mint fresh duplicate URLs. All are routine client operations. None announces what it broke. The gap between a product disappearing and anyone noticing is measured in whatever the client happens to look at, usually a revenue report weeks later.

The question to add to every post-launch checklist is not "which one is it today" but "what would catch this next time, on the day it happens". That can be a habit of re-inspecting a sample of URLs after every theme change, a scheduled audit, or automated catalog monitoring. It cannot be the Shopify admin, which keeps showing a green Active badge across all eleven failure modes.

Which of these 11 have you hit most in client stores? Any patterns by app category or theme?

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

Shopify canonical: fix the collection URL override for clients

Max — Mon, 10 Aug 2026 11:58:07 +0000

TL;DR

Shopify serves every product at two URLs; most themes link to the collection-scoped version via the within filter, which contradicts the canonical tag.

Google treats internal links as a canonicalization signal. When hundreds of links point to /collections/name/products/handle and the tag declares /products/handle, the tag loses.

The fix is replacing product.url | within: collection with product.url in product card snippets, then aligning the sitemap and Merchant Center feed to the same URL.

When you audit a client's Shopify store in Search Console, you may find a pile of product URLs under "Duplicate, Google chose different canonical than user." The Google-selected canonical is /collections/name/products/handle, not the clean /products/handle the canonical tag declares.

This happens because Shopify's within Liquid filter (used in most theme product cards) generates collection-scoped URLs. Every collection page and every related-products block links to the scoped version, casting hundreds of internal-link votes against the canonical declaration. Google weighs internal links as a canonicalization signal, so the declaration loses.

This article covers why Shopify produces two URLs per product, how to confirm the issue in Search Console, the Liquid change that fixes it, and the sitemap/feed alignment needed to close the loop.

What does "Duplicate, Google chose different canonical than user" actually mean?

Two statuses describe similar situations and are worth keeping distinct. Google's page indexing documentation defines "Duplicate, Google chose different canonical than user" as a page "marked as canonical for a set of pages, but Google thinks another URL makes a better canonical" and has indexed that other URL instead. "Duplicate without user-selected canonical" is the variant where no canonical was declared, so Google picked freely.

A third status, "Alternate page with proper canonical tag," is the healthy outcome: the collection-scoped copy defers to the clean product URL and Google agrees. If your client's collection URLs sit there, nothing here needs fixing.

How do you confirm the issue on a client store?

Open Search Console → Indexing → Pages, find "Duplicate, Google chose different canonical than user," and read the sample URLs. If they are /products/..., the clean URLs are the ones losing.
Run one of those URLs through URL Inspection and compare User-declared canonical with Google-selected canonical. Google states plainly there is no guarantee it will choose yours.
Search site:client-store.com inurl:/collections/ inurl:/products/ in Google. Every result is a collection-scoped product URL Google has kept in its index.
Open a collection page, click through to a product, and read the address bar. If it shows /collections/.../products/..., that is the URL the theme is linking to. View source and check the <link rel="canonical"> href: it should resolve to /products/handle with no query string.

Why does Google override the canonical tag?

Internal links are a canonicalization signal. Google's canonicalization documentation calls rel="canonical" "a strong signal," a sitemap entry only "a weak signal," and then says to "link to the canonical URL rather than a duplicate URL." A store that declares one URL and links to another from every collection page has cast a vote against its own declaration at scale.

The within filter. Shopify's Liquid reference for within shows it turning /products/handle into /collections/name/products/handle, and warns that "a standard product page and a product page in the context of a collection have the same content on separate URLs." Most themes call within: collection in the product card snippet, so every collection page and every related-products block links to the scoped version.

A canonical carrying a query parameter. If the tag resolves to /products/handle?variant=123, each variant is declaring itself the canonical version of the product, which is the opposite of consolidating them.

Two canonical tags. Apps with theme access can inject their own <link rel="canonical"> into the <head>. Two contradictory declarations give Google permission to ignore both and choose freely.

How do you fix the canonical mismatch?

The goal is to stop the site contradicting itself. All four signals need to point to the same URL.

1. Internal links (highest impact)

In the theme's product card snippet and related-products snippets, replace:

{{ product.url | within: collection }}

with:

{{ product.url }}

This is the change that moves the needle, because it removes the volume of votes against the canonical declaration.

2. The canonical tag

One tag per page, resolving to /products/handle, with no query string. Check for apps that may be injecting a second tag by viewing page source and searching for rel="canonical" (there should be exactly one).

3. The sitemap

Open /sitemap_products_1.xml and confirm the URL form listed there matches what the canonical declares.

4. The Merchant Center feed

Google's specification for the link attribute requires the product's landing page on the verified domain. Submitting the collection-scoped URL while canonicalizing to the clean one adds another contradiction for Google to resolve. Align the feed's link value with the canonical.

After making these changes, run the clean URL through Search Console's URL Inspection tool and request indexing. Canonical selection is recalculated on Google's own schedule; expect the status to change over days.

Why does this issue keep coming back after a theme update?

The Liquid edit is small; keeping it is harder. A theme update or a new theme can reintroduce within: collection without any explicit decision. Any app with theme access can add a second canonical tag to the <head>. Every new collection creates a fresh set of duplicate URLs for products that were previously clean.

The same pattern shows up in related issues: a product can look healthy in the Shopify admin while the disagreement lives between the theme output, the feed, and Google's index. Something has to read the live pages and compare what they actually emit.

Have you run into cases where a theme update silently reintroduced the within filter after a fix? How do you catch it in your deployment workflow?

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

Shopify robots.txt.liquid is blocking your clients' products

Max — Wed, 05 Aug 2026 11:58:39 +0000

TL;DR

robots.txt on Shopify is generated from robots.txt.liquid inside the theme. Any app or developer with theme access can add a Disallow rule that blocks Googlebot from product pages, with zero warning in the admin.
The only signals are in Google Search Console (Page indexing report, "Blocked by robots.txt" status) and Merchant Center diagnostics.
Adding noindex to a blocked page will not fix it. Googlebot must be unblocked first so it can read the tag.

A single line in robots.txt.liquid can silently drop every product in a client's Shopify catalogue from Google's crawl queue. The store looks healthy: pages are active, the theme is live, Shopify reports no errors. Google just stops fetching the URLs.

This happens because Shopify generates /robots.txt from a Liquid template inside the theme, not from a static file. Any app, developer, or agency with theme code access can modify it. The most common pattern: an SEO app or a previous developer adds a Disallow rule that overreaches, catching /products/ paths alongside the intended targets like /admin or /cart.

This article covers how to detect the block in Search Console, read the correct user-agent group in robots.txt.liquid, remove the offending rule, and verify that both Googlebot and Googlebot-image can reach product pages and images. It also explains why noindex on a blocked page will not work.

Is a crawl block the same as a noindex?

No, and the difference is the source of most failed fixes.

A noindex tag says: fetch this page, then keep it out of the index. A robots.txt Disallow says: do not fetch this page at all. The second sounds stricter. It is actually weaker, because a page Google never fetches is a page Google knows nothing about, including whether you wanted it indexed.

Google Search Console names two separate statuses here. "Blocked by robots.txt" means the URL was blocked; Google notes this does not guarantee the page stays out of the index. "Indexed, though blocked by robots.txt" means it appeared in results anyway, built from signals on pages that link to it.

For a product page, the second status is the worst outcome: the URL surfaces in results, but Google has no title, description, price, or structured data to build a listing from.

Why does this appear in client stores that nobody touched?

Because robots.txt on Shopify is not a file you upload once. It is generated from robots.txt.liquid, a template in the templates/ folder of the published theme. Shopify's own documentation for editing robots.txt.liquid calls this an unsupported customization, warns that Shopify Support cannot help with edits, and states that incorrect use of the feature can result in loss of all traffic.

Anything with theme code access can write to it: an SEO app installed and later forgotten, an agency hardening the file during a migration, a developer restoring a theme backup. A Shopify Community thread from March 2025 shows the typical pattern: 34 blocked product pages traced to Disallow rules added by three installed apps.

Shopify's defaults are sensible: /admin, /cart, /checkout, /search, /policies/, and filtered collection URLs are blocked out of the box and should stay that way. The damage comes from what gets added beneath them.

Why will adding noindex to a blocked page not fix it?

This catches experienced developers. If a page shows as "Indexed, though blocked by robots.txt", the instinct is to add a noindex meta tag. Google's documentation says directly that this will not work: for a noindex rule to be honored, the page must not be blocked in robots.txt, because a blocked crawler never reads the tag.

The correct order: unblock first, so Googlebot can read the instruction. This is the inverse of the phantom noindex pattern. There, Googlebot is allowed in but told to forget the page. Here, Googlebot is not allowed in at all, so it receives no instruction.

What does this cost in Merchant Center?

Google Merchant Center re-crawls the landing page behind every feed item. Its documentation lists a specific failure for pages it cannot reach: product landing pages that robots.txt forbids Googlebot to download. Those products remain disapproved and stop showing in Shopping ads and free listings until the crawler can reach the page.

Two user agents matter: Googlebot for landing pages and Googlebot-image for images. A rule that only blocks an image CDN path breaks image crawling while landing pages appear unaffected.

One parsing rule worth knowing before editing: Google's robots.txt specification resolves conflicts by longest matching path. A named User-agent: Googlebot block replaces the wildcard block entirely for that crawler, so a permissive * group gives no protection if a restrictive Googlebot group exists below it.

How do you check a client store in five minutes?

Read the live file. Open https://clientstore.com/robots.txt in a browser. It is public with no login needed. Read every Disallow line and check whether any could match a product URL.
Open Search Console, Page indexing. Look for "Blocked by robots.txt" and "Indexed, though blocked by robots.txt". Each status lists the affected URLs, which is faster than reasoning about wildcard patterns by hand.
Run URL Inspection on a real product URL. It reports directly whether crawling was allowed.
Find the template. Online Store, Themes, Edit code on the published theme, then the templates/ folder. If robots.txt.liquid is listed, the store runs a customized file worth reading in full.
Check Merchant Center diagnostics for product-page crawl issues, which name the URLs Google could not download.

How do you fix it?

Remove or narrow the overreaching Disallow rule in robots.txt.liquid on the published theme. Leave Shopify's defaults for /cart, /checkout, and /admin intact; they are there for good reasons.

Check which user-agent group actually applies to Googlebot. A named User-agent: Googlebot block replaces the wildcard block for that crawler; a clean * group gives no protection if a restrictive Googlebot group exists below it.

Do not check immediately after saving. Google generally caches robots.txt for up to 24 hours, and Merchant Center states a change may take 24 to 72 hours to reflect. Re-run URL Inspection after that window.

If the pages genuinely need to stay out of the index: unblock in robots.txt.liquid first, then add noindex, in that order.

Why does this bug come back?

robots.txt.liquid belongs to a theme, not to the store. Whichever theme is published determines what Google is served. Shopify documents that uploading a theme through the admin's Themes section will not import robots.txt.liquid, while ThemeKit or command-line deployments preserve it. Swapping the published theme can quietly replace the rules Google reads with no visible change in the admin.

Add an app with theme code access or a developer restoring a backup, and the same Disallow line can reappear months later with no symptom in the admin, only on Google's side.

Have you traced a client's lost Merchant Center traffic back to a robots.txt.liquid change? What process do you use to catch it before the client does?

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

Shopify deleted products: the 404 redirect fix for clients

Max — Mon, 03 Aug 2026 11:58:45 +0000

TL;DR

Shopify does not create a redirect when a product is deleted; the old URL starts returning 404 immediately.

Google keeps serving the old listing on its own recrawl schedule, independent of when the deletion happened.

Fix: create a 301 in Content > Menus > URL Redirects pointing to the nearest live product or collection.

When a client deletes a Shopify product, the platform removes it from the catalog and from the sitemap. That is where Shopify's involvement ends. No redirect is created, no 410 (Gone) response is served, no canonical update fires. The old URL returns 404 on the next request.

For developers managing client stores, this becomes a recurring issue after catalog cleanups, rebrands, and bulk migrations. A batch of product URLs goes dead with no redirect plan. The client sees crawl errors accumulating in Search Console. You're on cleanup duty.

This article covers why Shopify behaves this way, how to find every affected URL in a client store quickly, and the exact steps to set up redirects so the catalog stays clean after any deletion.

Why does Shopify leave deleted product URLs returning 404?

Shopify's own documentation describes URL redirects as something a merchant sets up after deleting a product. The platform does not prompt for a redirect destination at delete time and does not create one automatically. Delete a product and the URL simply starts returning 404 on the next request, whether that is a shopper with an old bookmark, a link from a collection page, or Googlebot revisiting a URL it already indexed.

This is the default outcome after any product deletion.

Why does Google keep showing the deleted product in search results?

A 404 response tells Google the page does not exist, but Google does not drop a URL from its index the moment it crawls a 404. Per Google's crawling documentation, removal happens on Google's own recrawl schedule for that specific URL. For a lower-traffic product page, that schedule can take weeks.

The sequence:

Product deleted. URL returns 404.
Google has not revisited that URL yet.
Google keeps serving the old listing with a cached snippet.
Users click through and land on a 404.

How do you find every affected URL in a client store?

In Google Search Console: Indexing > Pages, look at the "Not found (404)" entry under "Why pages aren't indexed." This lists every URL Google has crawled and found dead, including old product pages.
In Shopify admin: Content > Menus > URL Redirects. Search for the old product handles. If no redirect appears, the URL is a dead end.
For a quick check on a single URL: paste it into a browser or run it through a header-checker tool to confirm the HTTP status code.

What are the common causes across client stores?

1. Product deleted with no redirect set up. The default outcome after any deletion. Nothing in the delete flow prompts for one.

2. Product handle changed during a rename or migration. Changing the URL slug has the same effect as a deletion from Google's perspective. The old handle 404s unless a redirect was created at the same time the handle changed.

3. Bulk catalog cleanup with no redirect plan. Agencies doing larger migrations (discontinuing a product line, merging duplicates, restructuring collections) routinely end up with a batch of dead URLs because nothing in the bulk-delete flow surfaces the need for redirects first.

4. Google has not recrawled the dead URL yet. Even after a correct 404 is in place, the listing can persist in Google's index for an extended period. This compounds with the other causes: a 404 with no redirect just waits for Google to get around to it.

How do you set up the 301 redirects in Shopify admin?

Go to Content > Menus > URL Redirects > Create redirect.

Redirect from: the old product path, e.g. /products/old-handle
Redirect to: the closest live equivalent. A similar product if one exists, or the parent collection if there is no direct replacement. Avoid pointing everything at the homepage. Google treats a batch of homepage redirects from unrelated URLs as soft 404s.

For a bulk cleanup, export the full list of URLs before deleting anything, then use a CSV import to create the redirects in one pass. Rebuilding the list from Search Console error reports after the fact is slower and misses URLs Google has not crawled yet.

How do you confirm the fix and speed up Google's recrawl?

Once redirects are live:

Use the URL Inspection tool in Search Console on a few of the affected URLs. Confirm Google now sees a 301 response rather than a 404.
Resubmit the sitemap under Indexing > Sitemaps. This gives Google a signal to recrawl sooner than the passive schedule would trigger.

The inverse of this problem is covered in the Shopify product missing from sitemap article: there, a live product drops out of what Google can discover; here, a dead product stays in what Google already found.

When you hand off a store after a catalog migration, do you include a redirect audit in your checklist, or does this only come up after the client reports Search Console errors?

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

DEV Community: Max

Discovered, not indexed: the Shopify crawl bug clients hit

What does "Discovered - currently not indexed" actually mean?

Why does Google flag this as a crawl-budget signal?

Why does a Shopify store have more URLs than products?

Where do the recommendation tracking parameters come from?

Why do collection-scoped product URLs duplicate every product?

What URLs are your client's apps adding without telling anyone?

How do you check a client's store in five minutes?

How do you fix each cause?

Why does this bug keep coming back after you fix it?

The Shopify structured data bug that gets clients suspended

Why doesn't Merchant Center name the product that broke the rule?

What does the misrepresentation policy actually require?

Where does a Shopify build break that requirement?

Continue selling when out of stock

Duplicate or stale structured data

One offer, many prices

Redirects on discontinued product URLs

How do you audit a client's store in five minutes?

How do you fix each issue?

Why does this bug keep coming back after launch?

The Shopify structured data bug your JSON-LD checks miss

What does "unparsable structured data" actually mean?

What does the client actually lose when a block fails to parse?

Which syntax errors cause this on Shopify themes?

How do you find whether the theme or an app injected the broken block?

How do you check and fix it end to end?

The Shopify Product schema gap that breaks shippingDetails

Why doesn't Shopify's offer markup include shipping and returns fields?

Does this actually invalidate the product for search?

If I paste the markup into the theme, why does nothing change on the listing?

Where does Google actually want this markup, if you implement it at all?

Why does the shipping rate Google shows differ from what the client charges?

How do you audit this on a client's store in five minutes?

What's the actual fix, and does it depend on the client's setup?

Why does this keep coming back after you close the ticket?

The Shopify Search Console statuses that mean you shipped a bug

What is the Page indexing report actually counting?

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

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

What do the two "indexed anyway" warnings mean?

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

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

The Shopify zero-price bug that breaks Merchant Center feeds

What does "Invalid value for category [price]" actually mean?

Why does this bug hide from spot-checks?

Cause 1: is the variant price actually empty?

Cause 2: is the theme reading the wrong price variable?

How do you tell which one you're looking at?

What's the actual fix, and how do you confirm it?

How do you check an entire client catalog, not just one product?

Shopify 'crawled not indexed': triage guide for agency devs

Why does this report fill up with URLs that aren't the problem?

What causes a real /products/ URL to stay unindexed?

Does the canonical point somewhere else?

Does the page have unique content?

Is the structured data parsing correctly?

How do you triage this in five minutes?

Shopify product removed but still live in Merchant Center

Why doesn't deleting in Shopify remove it from Merchant Center?

How do you confirm which mechanism is holding the listing?

What four mechanisms keep the listing alive?

Why does the standard redirect advice block the auto-cleanup?

What is the correct fix per cause?

Why does this recur after every catalog cleanup?

Shopify product drops from Google: 11 bugs to fix for clients

Which three systems control whether a product appears?

Why did Google never fetch the page?

Why did Google fetch it but not index it?

Why did Google never discover the URL?

Why does the URL resolve to the wrong thing?

Why is the product indexed but stripped of rich results?

Why did Merchant Center drop it while organic search kept it?

How do you identify which failure you are dealing with in ten minutes?

Why does this recur after every theme update or app install?

Shopify canonical: fix the collection URL override for clients

What does "Duplicate, Google chose different canonical than user" actually mean?

How do you confirm the issue on a client store?

Why does Google override the canonical tag?

What causes a real `/products/` URL to stay unindexed?