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

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.