DEV Community: Max

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.

Missing GTIN in Shopify throttles your clients' Shopping feed

Max — Thu, 30 Jul 2026 11:59:44 +0000

TL;DR

Missing GTIN, MPN, or brand does not disapprove a Shopify product in Merchant Center; it triggers "limited performance," cutting impressions with no warning visible in Shopify admin.

The flag lives exclusively in Merchant Center Diagnostics, invisible from the Shopify product dashboard and the Google & YouTube channel app.

Fix: add a real GTIN to the barcode field where one exists; for products with no identifier at all, submit identifier_exists: false rather than leaving fields empty.

When a Shopify product is missing its GTIN, MPN, or brand attribute in the Google feed, Merchant Center does not disapprove it. It throttles it. The listing stays approved, keeps syncing, and shows "Active" in Shopify admin, but Google quietly reduces how often it appears in Shopping ads and free listings. The flag is called "limited performance due to missing identifiers" and it lives exclusively in Merchant Center Diagnostics.

This pattern shows up on stores where products were imported from a supplier without barcodes, or where the Google & YouTube channel app was configured once and never revisited. As a developer or agency building Shopify stores for clients, this warning never surfaces in the Shopify dashboard, which is why it can persist for months unnoticed.

This article covers: where the warning appears, which Shopify fields map to which feed attributes, and the correct fix (including when identifier_exists: false is the right call).

What does "limited performance due to missing identifiers" actually mean?

Google's own page on fixing Merchant Center disapprovals is explicit that this is a separate category from a disapproval: products with missing identifiers "will continue to show on Shopping ads and free listings, but may appear with limited performance."

The outcome is not identical for every product. For categories where Google strictly requires a GTIN, a missing one can result in disapproval rather than throttling. Which path applies depends on your product category and which identifier is missing. In the common case (missing brand or MPN, or a GTIN-optional category), the listing survives but stops competing on equal footing.

Where do GTIN, MPN, and brand live in the Shopify data model?

The GTIN maps from the barcode field, a field many merchants never fill in. Shopify's documentation for the Google & YouTube channel is direct: "add a barcode (GTIN): in your Shopify admin, go to Products, open the product, and add the barcode in the Inventory section." Nothing in the standard product-creation flow requires it, so a product built by hand, imported from a supplier feed, or duplicated from a template can go live and sell for months without one.

Brand and MPN are not native Shopify product fields. Brand is usually inferred from the Vendor field when the Google & YouTube app builds the feed. MPN has no Shopify-side home and typically requires an override inside the channel app itself, or a supplemental feed. On stores that installed the app once and never revisited the settings, MPN is simply absent from every product.

How does this slip through into production undetected?

A common scenario: a store imports its catalog from a supplier CSV that never populated the barcode field, because the supplier did not provide GTINs for private-label or custom items. The products publish fine, the channel app syncs fine, and Merchant Center approves the listings. A missing identifier alone does not block approval. It shows up only as a "Needs attention" warning in Diagnostics, quietly capping impressions against competitors with complete identifiers.

How do you find which products are affected?

In Shopify admin, open a sample of products under Products and check the Inventory section. Is the barcode field blank?
Open the Google & YouTube sales channel app and look for a "Needs attention" or diagnostics count, not just an overall "connected" status.
In Google Merchant Center, go to the Diagnostics tab (or Needs attention under Products) and filter for identifier-related issues. Google's guide to fixing a missing or incorrect GTIN walks through this view and a bulk-CSV fix for stores with many affected products.
Spot-check whether the Vendor field is populated for every product. An empty Vendor field typically means an empty brand attribute in the feed.

When is `identifier_exists: false` the right fix?

If the product has a real-world GTIN (most branded, mass-produced goods do), add it to the barcode field and let it flow through the feed.

For products with no identifier (handmade goods, custom items, private-label products with no assigned barcode), submit identifier_exists as false alongside an MPN and brand where you have them. Google's documentation for the identifier_exists attribute is specific on this point: setting it to false on a product Google can find evidence has a real identifier "will receive a warning" of its own. It is an honest declaration, not a workaround.

This issue sits in the same family as price and landing-page mismatches. Merchant Center compares what your feed claims against what it can verify, then adjusts how much it trusts the listing. For the pricing version of the same pattern, see the price mismatch trap.

Have you run into a client store where this "Needs attention" flag had been sitting in Diagnostics for months before anyone caught it? What triggered the audit?

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

Shopify out-of-stock redirect breaks Merchant Center feed

Max — Wed, 29 Jul 2026 11:58:23 +0000

TL;DR

A product URL that 301-redirects to the homepage triggers a Merchant Center "landing page mismatch" disapproval; the feed URL no longer resolves to the product it advertises.

The redirect almost always comes from an out-of-stock app with a redirect toggle enabled by default. A manual rule added in Shopify Admin is rarely the source.

Fix: keep the page live, set offers.availability to OutOfStock in JSON-LD and out_of_stock in the feed. Reserve 301s for discontinued products, pointed at a specific replacement.

Here is the failure chain: a client's product goes out of stock, an app redirects the product URL to the homepage, and within the next Merchant Center crawl cycle, the listing is disapproved for a "landing page mismatch." No error appears in Shopify admin. The product is still active, still priced, still in the feed. The only symptom is a disapproval accumulating in the Diagnostics tab.

This is a common side effect when out-of-stock apps are installed with default settings. The redirect toggle is often on by default, intended to stop shoppers from hitting a "sold out" page with no path forward. The unintended consequence: Google's feed crawler follows the same product URL and finds a homepage instead of a product, which fails Merchant Center's link attribute requirement.

This article covers the failure mechanism, where to locate the redirect rule in a client's store, the correct schema pattern, and an audit checklist.

What does the redirect actually break?

Three things break simultaneously.

The product's SEO equity. A product page that has been live for months carries indexed history, internal links, and sometimes external backlinks. A 301 to the homepage transfers none of that value to anything useful; it tells Google the product no longer exists at that URL, which is usually false.

The Merchant Center listing. The link attribute in the feed still points at the original product URL. Once that URL redirects to a non-product page, Google's crawler flags a mismatch and disapproves the listing.

The paid and organic click. A shopper who clicked a Shopping ad or an organic result for that specific product lands on a homepage with no context. Most will not search again for the item; the click is lost.

Where does the redirect rule come from?

The source is almost always an out-of-stock app. Most out-of-stock, back-in-stock, or "sold out" apps include a setting to redirect unavailable product URLs elsewhere. The default destination is usually / or a collection page. When that toggle is on, every product that hits zero inventory across all variants gets a redirect applied to its URL automatically.

Check the app's settings first. The redirect rule may not appear in Shopify Admin's URL Redirects list at all if the app manages it internally.

Why does Merchant Center flag this as a landing page issue?

Google's product data specification requires the link attribute to point directly to the page for that specific product. The link attribute specification and the product data specification overview both state the destination must let the shopper view and purchase the exact item advertised.

A redirect to the homepage fails that requirement regardless of the reason for the redirect. Google's crawler does not distinguish between "product gone forever" and "temporarily out of stock." It follows the URL, finds a non-product page, and disapproves.

The error label in Diagnostics is typically "landing page does not match" or "destination mismatch," and it lists the exact affected URLs.

This pattern is a close cousin of the price-mismatch disapproval covered in Products disapproved in Google Merchant Center: the price mismatch trap. Both failures come from a gap between what the feed claims and what the live page actually delivers.

What is the correct implementation for out-of-stock products?

Keep the page live. Signal unavailability through data, not through the URL.

In the theme's JSON-LD, set offers.availability to OutOfStock:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Product Name",
  "offers": {
    "@type": "Offer",
    "availability": "https://schema.org/OutOfStock",
    "price": "49.00",
    "priceCurrency": "EUR"
  }
}

In the product feed, set availability to out_of_stock.

Add a restock notification form on the product page. This keeps the page converting intent rather than abandoning the visitor.

Reserve 301 redirects for genuinely discontinued products, and point them at a specific replacement product. A redirect to a real substitute preserves the shopper's intent and most of the page's SEO value; a redirect to / preserves neither.

This is the same discipline as in The phantom noindex: how Shopify apps silently hide your products from Google: a product can appear completely fine inside Shopify admin while the public-facing URL tells Google something entirely different.

How do you audit a client's store for this issue?

Open Shopify Admin > Online Store > Navigation > URL Redirects and search for rules pointing product handles at / or a collection URL.
Open the settings of every out-of-stock, back-in-stock, or sold-out app installed. Look for a redirect toggle (often labeled "redirect to another page" or "redirect when sold out") and disable it or change the behavior to keep the product page live.
In Merchant Center, open the Diagnostics tab and filter for "landing page" or "destination" errors. These list the exact affected URLs.
Spot-check a sample of currently out-of-stock products: visit each URL in an incognito window and confirm it loads the product page rather than the homepage.

None of this produces an error inside Shopify admin. The product stays active, the feed submits without a validation warning at first glance, and the only symptom is a slow accumulation of Merchant Center disapprovals.

Have you run into this redirect default on a client's store? Did you catch it through Merchant Center, or through something else?

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

Shopify sitemap drops live products: detect and fix it

Max — Tue, 28 Jul 2026 11:57:35 +0000

TL;DR

A Shopify product can be active, priced, and purchasable while completely absent from sitemap.xml, with no warning anywhere in admin.
Common triggers: out-of-stock filters in SEO apps, handle renames, tag/collection-scoped sitemap logic, bulk-import sync gaps.
Detection requires cross-referencing the live catalog against the sitemap file, or using Search Console's URL Inspection tool.

This is a bug that affects Shopify stores you build for clients: a product can be active, correctly priced, and fully purchasable while completely absent from sitemap.xml. No error in Shopify admin. No broken page. Nothing flags the mismatch.

The product is orphaned from Google's crawl signal. It still sells. Your client sees no problem. But over weeks, rankings erode and the product can end up in "crawled - currently not indexed" in Search Console.

This happens because Shopify generates sitemap.xml and child files like sitemap_products_1.xml as a downstream artifact, separate from catalog status. Several routine operations can break the connection: an SEO app filtering out-of-stock items, a handle rename that takes a sync cycle to propagate, or a bulk catalog import that doesn't cleanly trigger sitemap regeneration.

This article covers the mechanism, the common triggers, and the steps to diagnose and fix it in a client's store.

Why does a live product fall out of the Shopify sitemap?

Shopify auto-generates sitemap.xml from the published catalog, but several ordinary changes can pull one specific product out of it without touching its "Active" status:

A sold-out filter in a sitemap or SEO app. Several popular apps let you exclude out-of-stock products from the generated sitemap. A product that goes briefly out of stock and comes back can stay excluded if the app's cache or rule doesn't re-add it promptly.
A handle change. Renaming a product's URL handle removes the old handle from the sitemap. If the new handle takes a sync cycle to appear, or the internal link update lags, the product is temporarily invisible via sitemap from either URL.
A tag, collection, or metafield rule. Custom sitemap logic keyed off tags or collections can silently drop a product the moment it's untagged or moved out of scope, even if it still sells on its own product page.
A bulk edit or CSV re-import. Large catalog updates sometimes unpublish and republish products in the same batch; if the publish event doesn't cleanly propagate to the sitemap generator, the product is left out until the next full regeneration.

In every case, the product URL loads fine. The page renders, the price is correct, checkout works. The only missing piece is the sitemap entry.

Why doesn't Shopify admin surface this problem?

Shopify admin reports on your catalog, not on the sitemap's contents. There's no screen listing "products missing from sitemap.xml," because from Shopify's perspective the product is fine: active, priced, in stock. The sitemap is generated separately, and its accuracy relative to the live catalog isn't something the admin dashboard audits.

That gap is why this failure can run for months. Catching it requires manually diffing your published catalog against the sitemap file, which nobody does by hand at scale.

Does a missing sitemap entry actually affect rankings?

A sitemap isn't required for indexing. Google can still discover a page through internal links, and per Google's documentation on sitemaps, a sitemap is a hint about which URLs to crawl. But it's one of the strongest recrawl signals you control, particularly for pages with weak internal linking.

Products fit that profile precisely. Many stores link to a product from only one or two collection pages. If that collection link also drops (the product went briefly out of stock and got auto-removed from its collection) at the same time the sitemap entry disappears, the product loses both discovery paths at once.

Google doesn't deindex it immediately, but without a recrawl signal the result over time is stale index snippets (old price, wrong stock status), a slow ranking decline, or the page settling into "crawled - currently not indexed" in Search Console.

This is related to the redirect failure covered in Your Shopify product page redirects to the homepage: different mechanism (missing discovery signal vs. broken destination), same eventual outcome.

How do you diagnose this in a client's store?

Open yourdomain.com/sitemap.xml, follow the link to sitemap_products_N.xml, and use browser find-in-page to search for the product's handle or canonical URL.
Target high-risk products first: recently out-of-stock items that came back in stock, recently renamed products, and anything touched by a bulk edit or CSV import.
In Google Search Console, run URL Inspection on the product URL and check the "Sitemaps" field. If it's blank, Google has no sitemap pointing to that URL.
In the Search Console Sitemaps report, watch the "Discovered URLs" count over time. An unexplained drop that doesn't match a real catalog reduction is the signal to dig in.
Open the settings of any sitemap-filtering or SEO app and look for a "hide out-of-stock products from sitemap" toggle. This is the most common cause.

What's the fix once you've confirmed the gap?

Identify the exclusion rule in whichever app or theme customization controls the sitemap, and adjust it so active products are never filtered based on a temporary stock dip.
Force a regeneration. Resaving the product (even with no real change) typically triggers Shopify to re-include it in the next sitemap cycle.
Request indexing directly for the affected URL via Search Console's URL Inspection tool, rather than waiting for the next natural crawl.
Reinforce internal linking so the product isn't solely dependent on the sitemap for discovery. Keep it linked from at least one collection or "related products" block at all times, including while temporarily out of stock.

Shopify admin accurately reflects catalog state, but not how Google currently sees the store. Those two views can drift apart quietly, and a sitemap gap is one of the quieter ways it happens.

Have you run into this in client stores? What's your current approach to monitoring sitemap coverage across a portfolio of Shopify sites?

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

Shopify noindex bug: detect and fix the seo.hidden metafield

Max — Mon, 27 Jul 2026 11:57:44 +0000

TL;DR

Shopify's seo.hidden metafield (value 1) emits a noindex directive with no admin warning anywhere in the store.
Three common sources: CSV imports carrying the field over, SEO app bulk rules with loose conditions, theme edits left in by mistake.
Detection takes under 5 minutes via Search Console URL Inspection; the fix is one metafield deletion.

You're auditing a client's Shopify store and a product that used to rank has vanished from Google entirely. No penalty notice, no manual action, nothing in the admin flags it. The product is published, the page loads, checkout works. The issue is a single noindex directive in the HTTP response or HTML head that Google is honoring silently.

This is one of the most common technical SEO bugs in Shopify builds, and it almost never comes from a deliberate decision. It surfaces after CSV imports, SEO app bulk rules, or a theme edit that didn't get reverted. The symptoms are invisible to every human visitor. Only what Google reads when it crawls the store is different.

This article covers where the directive originates (three specific causes), how to confirm it in under 5 minutes, and the steps to remove it without breaking legitimate noindex cases.

What is actually happening?

Somewhere in the page response, a meta robots tag contains noindex, or the HTTP response carries an X-Robots-Tag: noindex header. Either instruction is taken literally by Google: stop indexing this page. On Shopify, this is almost always triggered by something other than a deliberate decision.

Where does the noindex come from on Shopify?

The seo.hidden metafield. This is the most common source. It gets set to 1 (or true) via three typical paths: a bulk CSV import that carried the field from a previous platform, a migration tool that defaults new products to hidden until marked ready, or a developer toggling it on a handful of products without reverting. It sits on the product record, invisible unless you scroll to the Metafields section in the product editor.

An SEO app with a misconfigured indexing rule. Several Shopify SEO apps offer bulk rules like "noindex all products under $X" or "noindex out-of-stock products." If the rule's condition is broader than intended, or if it keeps running after a cleanup campaign is done, it continues noindexing products that match the too-loose condition.

A CSV import carrying hidden/draft flags. Bulk product imports from a supplier feed, a platform migration, or a spreadsheet update can write a hidden flag into seo.hidden without the person running the import ever seeing that field in the sheet.

Theme edits. Someone editing theme.liquid or a product template while debugging something else leaves a stray {% if %} block that outputs a noindex tag under unintended conditions, or hardcodes it during testing and forgets to remove it.

How to confirm a noindex in under 5 minutes?

site: search. In Google, search site:yourstore.com/products/the-handle. Zero results on an established product almost certainly indicates a noindex directive in effect.
Search Console URL Inspection. Paste the exact product URL. Look for "Excluded by 'noindex' tag." This is the definitive confirmation: Google saw the tag and honored it, as opposed to simply not having crawled the page yet.
View source. Open the page, search (Ctrl+F) for noindex in the HTML <head>. Also check response headers via browser dev tools (Network tab, document request, Response Headers) for X-Robots-Tag. That header won't appear in view-source since it's server-level.
Check the metafield directly. In Shopify admin, open the product, scroll to Metafields, and look for seo.hidden. If it's set to 1, that's your answer.

Run this across the full catalog. CSV imports and app rules typically hit dozens of products at once, silently, which is why the problem usually surfaces by accident months after it happened.

Is the noindex always a bug?

No. Free-sample products, internal test SKUs, gift-with-purchase items, and wholesale-only listings are often deliberately noindexed. Before removing a tag, confirm this is a public-facing, sellable product that should rank. Removing noindex from an internal SKU or a page the client genuinely wants hidden just creates a different problem.

How to fix each cause?

Metafield: Shopify Admin, open the product, go to Metafields, find seo.hidden, then delete it or set it to 0/false.
SEO app rule: Open the app's indexing/visibility rules, identify the condition matching the affected products, then narrow or disable it.
Theme edit: Search theme.liquid and the relevant product template/snippets for noindex, then remove or correct the condition.
Header-level noindex: If the signal comes from an X-Robots-Tag response header rather than the HTML, it is usually set by an app or a custom Shopify Function/edge rule. Check installed apps that touch page headers before looking at the theme.

The fix typically takes 5 to 15 minutes once you have found the source. The hard part is discovering it exists at all: a noindexed page renders and behaves normally for every visitor; only what Google reads is different.

Have you run into a noindex source not on this list (a specific app, a Shopify Function, a webhook gone wrong)? Drop it in the comments.

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

Shopify availability mismatch breaking your clients' feeds

Max — Fri, 24 Jul 2026 11:57:51 +0000

TL;DR

Shopify inventory updates instantly; the Merchant Center feed does not. Drift between them silently suppresses products in Shopping with no alert in Shopify admin.

Three main triggers: scheduled feed fetches (not push-on-change), duplicate submissions from two competing apps, and theme JSON-LD that doesn't update when a variant sells out.

Fix: one feed source, push-on-change sync, and verified offers.availability updates in page schema after any theme or app change.

This is a bug your clients won't notice until it costs them revenue. Shopify's inventory count updates the instant a sale, restock, or manual edit happens. Google Merchant Center reads availability from a separate feed pipeline with its own update cadence. When the two drift, products either vanish from Shopping results (shown as out of stock when they're not) or keep appearing after selling out, burning impressions on a page that can't convert.

Neither system alerts you to the gap. Shopify admin shows inventory as healthy; Merchant Center shows a suppressed or disapproved listing that Shopify cannot see. This article covers the four mechanisms that cause the drift, how to detect it across a client's store, and the structural fix.

Why does Shopify availability diverge from the Merchant Center feed?

Shopify's inventory count is authoritative and updates instantly. Merchant Center reads from a separate feed pipeline with its own cadence. Four mechanisms cause the drift:

Scheduled fetches instead of push-on-change. Some feed setups pull a fresh file every 12 or 24 hours rather than pushing changes the moment inventory shifts. Between fetches, Google works from a snapshot that is already stale.
Two feed sources submitting the same product. Stores running both Shopify's native Google & YouTube channel app and a legacy or third-party feed app can submit the same product twice, with each app reporting different availability for the same GTIN.
Page JSON-LD contradicting the feed. Google cross-checks the feed's availability value against the offers.availability field in the live page's JSON-LD. If a theme caches that value, or a variant-level app updates the visible "Sold out" badge without touching the schema, the page and the feed tell Google conflicting things.
Variant-level stock not reflected at product level. A product where nine of ten variants are sold out can report availability inconsistently depending on which variant the feed treats as canonical, especially after a variant is deleted or reordered.

Why is this invisible in Shopify admin?

Shopify admin shows Shopify's own view only: current inventory, current variant status, current "Active" listing state. It has no visibility into what Merchant Center currently believes about that same product, because that belief lives on Google's side, driven by a feed pipeline Shopify doesn't monitor after handoff. A product can look perfectly healthy in Shopify admin while its Merchant Center listing is quietly suppressed or showing the wrong stock state. You only find out from Merchant Center's own diagnostics, if you check them.

What does the mismatch actually cost?

In-stock product showing as out of stock: Google's Shopping algorithm deprioritizes unavailable listings. The product effectively disappears from Shopping results even though it's fully sellable, with no error raised anywhere.

Out-of-stock product still showing as in stock: worse. You're spending impressions (and often ad budget) sending shoppers to a product they can't buy. A pattern of "available" listings that turn out unsellable is exactly what Google's misrepresentation policy targets. Repeated mismatches can escalate from a warning to an account-level suspension.

How do you check a client's store for this?

In Google Merchant Center, open Products > Diagnostics and filter for availability-related warnings. This shows exactly which items Google currently considers mismatched.
Pick five currently out-of-stock products and view each page source. Search for "availability" inside the JSON-LD block and confirm it reads OutOfStock, not InStock.
If the store runs more than one sales-channel or feed app connected to Google, check Merchant Center's Apps and Products tabs for duplicate submissions of the same item under different feed sources.
Check the feed's update frequency. Shopify's native Google & YouTube app pushes on inventory change, but a secondary feed app may be on a manual or scheduled sync. Confirm it isn't running on a 24-hour-or-longer delay for fast-moving SKUs.

This is the same category of failure as the redirect-to-homepage mismatch and the price mismatch trap: Merchant Center compares feed claims against the live page, and any gap in price, landing page, or availability gets treated as misrepresentation.

What is the structural fix?

Use a single feed source. If the store runs Shopify's native Google & YouTube channel alongside a separate feed app, pick one and disconnect the other. Duplicate submissions are the most common cause of contradictory availability for the same product.
Push on inventory change, not on a fixed schedule, especially for products that sell out quickly.
Confirm theme JSON-LD updates offers.availability on variant sellout, not just the visible "Sold out" label. The schema and the badge can drift independently.
Re-check after any theme or app update. A theme update or new inventory app is the single most common moment this breaks, because it touches the code that writes the schema.

Have you run into a case where a feed app and Shopify's native channel were both pushing to Merchant Center at the same time? What did the conflict look like in diagnostics?

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

Shopify Product schema bugs killing clients' Google review stars

Max — Thu, 23 Jul 2026 11:57:52 +0000

TL;DR

Duplicate Product schema (theme + review app both active) causes Google to drop or randomly pick a version, removing review stars.

A malformed JSON-LD block fails silently: the storefront renders normally but Google ignores the entire structured data payload.

A noindex tag from a metafield, app rule, or theme edit removes the product page from Google entirely, stars included.

When a client reports their Google review stars disappeared, the storefront is usually working fine. The bug lives in the structured data layer, invisible to shoppers and often invisible to the developer who introduced it. No error from Google, no console warning: just a star rating that vanished and a click-through rate in quiet decline.

The five causes below cover most cases on Shopify. Three are fixable in under an hour. All five can be diagnosed with free tools before touching a single line of code.

This article is aimed at developers and agencies maintaining Shopify stores: you will find the diagnostic steps, the specific theme variables and app settings involved, and the correct fix for each case.

How do you verify the schema state before touching anything?

Two tools, two minutes:

Open Google's Rich Results Test and paste the product page URL.
- "No items detected" → markup is missing or was never present (causes 1, 2, 3).
- Items detected, with errors → markup exists but is broken (causes 2, 4).
- Everything green → markup is valid; the problem is indexability or eligibility (cause 5).
In Search Console, go to Enhancements > "Products". The valid-items chart shows exactly when the drop happened; it is almost always the day of a theme update or an app change.

Why does a review app create duplicate Product schema?

This is the most common cause. Review apps (Judge.me, Loox, Yotpo, and similar) inject their own Product schema. Two failure modes:

The duplicate: the theme already outputs a Product block; the app adds a second one with a different price or rating aggregate. Google receives two contradictory descriptions of the same listing and either picks one arbitrarily or shows nothing. Classic symptom: stars appear some days and not others.
JavaScript injection: the app writes nothing into server-rendered HTML and instead injects schema after page load via JavaScript. Google processes it late and unreliably. If that script is blocked, updated, or fails silently, the structured data disappears with no visible sign on the storefront.

Fix: one source of truth. If your review app has a "structured data" or "SEO markup" toggle, disable either the app's output or the theme's native product schema block. Never leave both active at the same time.

What breaks when a JSON-LD block becomes unparseable?

Schema lives inside <script type="application/ld+json"> blocks. One app concatenating two JSON documents, or a stray control character, makes the entire block invalid. Google silently ignores the whole payload. The store functions normally; shoppers see nothing wrong; the stars switch off.

Diagnose: paste the URL into validator.schema.org and look for parsing errors.

Fix: find which app or theme snippet generates the broken block (search for a recognizable string from the broken JSON in the theme code editor), then fix or disable it.

How does a theme update silently drop structured data?

OS 2.0 themes (Dawn and derivatives) generate product schema natively. A theme redesign, a purchased theme switch, or a developer cleaning up theme.liquid can strip the snippet without anyone noticing. It produces nothing visible, so nobody catches it until stars vanish weeks later.

Fix: compare the current theme against a backup, or reintroduce a structured-data.liquid snippet that pulls price, currency, availability, and image from the live product object:

"price": "{{ product.selected_or_first_available_variant.price | money_without_currency }}",
"priceCurrency": "{{ cart.currency.iso_code }}",
"availability": "{% if product.selected_or_first_available_variant.available %}InStock{% else %}OutOfStock{% endif %}"

Never hardcode values. The schema must reflect the current product state on every render.

When does a price mismatch invalidate the schema?

A sale applied mid-day, a currency-conversion app, a hardcoded price left in a theme edit: if the price in the structured data diverges from what shoppers see, Google loses trust in the listing. On Google Shopping, Merchant Center can disapprove the product for an "inconsistent value."

Diagnose: compare the price the Rich Results Test detects against the price displayed on the page.

Fix: in the theme, pull the schema price from the exact same Liquid variable as the displayed price:

product.selected_or_first_available_variant.price

Never duplicate the variable or hardcode a fallback.

How does a noindex tag remove review stars entirely?

A noindex meta tag applied by mistake removes the page from Google entirely. Stars disappear because there is no listing left to attach them to. Common sources: a seo.hidden metafield inherited from a CSV import, an SEO app exclusion rule, or a stray theme edit.

Diagnose: run site:yourstore.com/products/your-product in Google. Zero results means the page is deindexed.

Fix: find and remove the noindex directive. Check the product's metafields in the Shopify admin, your SEO app's exclusion rules, and any conditional logic around the robots meta tag in theme.liquid.

None of these failures produce a visible symptom on the storefront. They surface weeks later in a Search Console chart while click-through rate drifts to competitors who still have their stars.

When you debug structured data issues for clients, which of these five causes do you run into most often?

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

Fix Shopify price mismatch killing clients' Merchant Center feed

Max — Wed, 22 Jul 2026 11:58:21 +0000

TL;DR

Google's "automatic item updates" cross-checks your feed price against two extra on-page signals: the Product JSON-LD block and the og:price:amount Open Graph tag.

The most common Shopify culprits: discount apps that update the visible price but leave JSON-LD stale, and multi-currency apps that rewrite the displayed price without touching cart.currency.iso_code.

Fix: route offers.price, priceCurrency, and the displayed price through the same Liquid variable — no hardcoded values, no divergent app outputs.

If you build or maintain Shopify stores for clients running Google Shopping campaigns, this is the kind of silent failure that generates support tickets weeks after launch: a wall of Merchant Center disapprovals citing "inconsistent value" or "price mismatch," on products whose Shopify prices look perfectly correct.

The cause isn't the feed. It's a three-way signal conflict on the live page — and Merchant Center is comparing all three.

This article covers how Google's automatic item updates work, which Shopify-specific patterns cause the three signals to diverge, and the single Liquid pattern that eliminates the root cause.

Why does Google reject prices it can already read from the feed?

Merchant Center doesn't only trust the price you submit in your product feed. Google's crawlers also perform automatic item updates — they visit the live page, read the price from the structured data (Product JSON-LD) and the Open Graph tags (og:price:amount), and compare that against your feed. If any of those three sources disagree, Google either overrides the feed price silently or disapproves the listing outright for "inconsistent value."

A store can have a perfectly correct Shopify product price and still get disapproved because one of the other two signals is out of sync.

Where does the divergence come from in Shopify?

A half-applied sale. A discount app updates the displayed price but never touches the JSON-LD block, which keeps rendering the pre-sale figure. Shoppers see the sale price; Google's structured-data reader sees the old one.

A multi-currency or currency-conversion app. This is the single biggest source of this bug. These apps rewrite the price a visitor sees based on geolocation or a currency switcher, but frequently don't touch cart.currency.iso_code or the JSON-LD price/currency fields — those keep reporting the shop's base currency. Google reads two different currencies or amounts for the same offer, triggering the currency_mismatch / price_mismatch pattern.

A hardcoded price in a theme edit. Someone typed a price directly into a Liquid template instead of pulling it from the product object. It looks fine at launch and quietly goes stale the next time the price changes in Shopify admin.

Duplicate schema from an app. If a review app or SEO app injects its own Product block alongside the theme's native one, you end up with two different prices on the same page. Google picks one arbitrarily — if it picks the stale one, that's what gets compared to your feed.

What does the fix look like in Liquid?

Every price on the page — the visible price, the Open Graph tag, and the JSON-LD offers.price — must come from the same Liquid variable, live, at render time:

"offers": {
  "@type": "Offer",
  "price": "{{ product.selected_or_first_available_variant.price | divided_by: 100.0 }}",
  "priceCurrency": "{{ cart.currency.iso_code }}",
  "availability": "{% if product.available %}https://schema.org/InStock{% else %}https://schema.org/OutOfStock{% endif %}"
}

No hardcoded numbers, no values from a separate app config, no currency assumed from the shop's default market. If the client runs Shopify Markets or a currency-conversion app, cart.currency.iso_code must reflect the converted currency the shopper is actually seeing — verify the app writes to that value rather than only restyling numbers client-side.

Availability deserves the same treatment: drive it from product.available, not a hardcoded value, or it becomes its own disapproval vector.

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

Open the disapproved product on the storefront. View source or open DevTools → find the <script type="application/ld+json"> block. Note the price and priceCurrency.
Search the same page source for og:price:amount and og:price:currency — these must match exactly.
Compare both against what the shopper actually sees and against the price in the Merchant Center feed.
If the client runs a multi-currency or localization app, repeat from a session simulating a different country/currency — the visible price often switches while schema and OG tags stay in the base currency.
If any two of those four numbers disagree, you've found the mismatch. Trace which app or template owns the wrong value and route it through the Liquid variable above.

This failure produces zero visible symptoms for weeks — the storefront looks normal, sales keep coming in, and the only signal is a slow bleed of disapproved SKUs in a Merchant Center tab the merchant rarely checks.

Related reading

Have you run into a currency or discount app that handles the schema side correctly out of the box — or have you always had to patch it manually?

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

Google is showing the wrong price for my product — Shopify

Max — Tue, 21 Jul 2026 15:44:24 +0000

You search your own product on Google, or check a Shopping result, and the price shown doesn't match what's actually on your Shopify store — sometimes an old price from before your last change, sometimes no price rich result at all. Nothing is wrong in Shopify admin: the product is active, the price field is correct, checkout charges the right amount. The mismatch only exists on Google's side.

This is a real, recurring complaint in the Shopify Community — merchants report Google holding onto a stale price for sold-out or repriced products for days or weeks, with generic advice ("wait for Google to recrawl," "hit Fetch Now") that treats the symptom but not the underlying cause. In our scans, the underlying cause is almost always structural: the product's JSON-LD is missing the one field that tells Google how long a price stays valid.

How to confirm it yourself in 5 minutes

Run a site: search for the affected product URL and compare the price shown in the snippet against your live storefront price.
Paste the same URL into Google's Rich Results Test and open the detected Product markup — check the offers object for a priceValidUntil field and whether its date is in the future.
In Google Search Console, open Enhancements → Merchant listings and check for any warnings logged against the affected URL — this report tracks Product structured data issues separately from an actual price-mismatch error.
If you also run Merchant Center for Shopping ads, check its Diagnostics tab for "mismatched value (price)" — that's a related but distinct feed-level issue, not the same as this Search-side symptom.

Causes, ranked by how often we actually see them

1. priceValidUntil is missing from the product's structured data entirely. This is by far the most common cause: in our aggregated scans across 822 Shopify stores, 514 (62%) have no price_valid_until value at all. That's not a merchant mistake — Shopify's own structured_data Liquid filter, the built-in filter Dawn and most modern themes use to generate Product JSON-LD, outputs an offers object with availability, price, priceCurrency, and url — no priceValidUntil. It has to be added manually via a theme edit or an app. Without it, Google's Offer object has no explicit signal for how long the current price should be trusted, and per Google's own merchant listing documentation, it's a recommended property of the Offer type — it isn't required for basic eligibility, but its absence removes one of the freshness signals Google uses to decide whether to trust and (re)display a price.

2. priceValidUntil was set for a past promotion and never updated. A sale or discount app writes a priceValidUntil matching the promo's end date, the sale ends, and nothing goes back to refresh or remove that date. Google's documentation is explicit here: "Your listing may not display if the priceValidUntil property indicates a past date." Google separately recommends pairing a start date with the end date specifically for sale pricing, so both ends of the window stay accurate. A leftover expired date is worse than having none.

3. Google simply hasn't recrawled since your last price change. Indexing lag alone can produce a stale price for days to weeks — this is the explanation Shopify Community threads on this exact symptom usually land on, and it's genuine. But it compounds with cause 1: a page with no freshness signal in its Offer data gives Google less reason to treat the price as time-sensitive and prioritize a recheck.

4. Malformed price or currency fields. Less common, but worth a quick check: price must be a bare number string with no currency symbol, and priceCurrency must be a valid ISO 4217 code. A stray symbol or the wrong code can make Google discard the price signal from your structured data entirely and fall back to whatever it last crawled from the visible page.

The fix

Add priceValidUntil to your theme's Product JSON-LD if it isn't there, computed live rather than hardcoded — most implementations set it to a rolling window (commonly 30 days to a year out) from the current date, recalculated on every render, so it never quietly goes stale on its own:
```
"priceValidUntil": "{{ 'now' | date: '%s' | plus: 2592000 | date: '%Y-%m-%d' }}"
```
(the example above adds 30 days; a sale-price app should instead set this to the actual promo end date, and clear or extend it the moment the sale is edited.)
Audit any sale/discount app for a leftover expired date — check its settings for a hardcoded promo end date that outlived the promo itself.
Request reprocessing in Search Console's URL Inspection tool for the affected URL once the fix is live, rather than only waiting for the next organic crawl.
Validate price and priceCurrency formatting with the Rich Results Test while you're in there.

None of this shows up as an error anywhere in Shopify admin — the product looks completely correct on your side. The only visible symptom is a shopper-facing price on Google that quietly drifted out of sync with your store, which is exactly the kind of gap that costs a sale before the shopper ever reaches checkout.

Next in this cluster

Originally published on the StoreCanary blog.

DEV Community: Max

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?

How do you fix the canonical mismatch?

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

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

Is a crawl block the same as a noindex?

Why does this appear in client stores that nobody touched?

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

What does this cost in Merchant Center?

How do you check a client store in five minutes?

How do you fix it?

Why does this bug come back?

Shopify deleted products: the 404 redirect fix for clients

Why does Shopify leave deleted product URLs returning 404?

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

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

What are the common causes across client stores?

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

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

Missing GTIN in Shopify throttles your clients' Shopping feed

What does "limited performance due to missing identifiers" actually mean?

Where do GTIN, MPN, and brand live in the Shopify data model?

How does this slip through into production undetected?

How do you find which products are affected?

When is identifier_exists: false the right fix?

Shopify out-of-stock redirect breaks Merchant Center feed

What does the redirect actually break?

Where does the redirect rule come from?

Why does Merchant Center flag this as a landing page issue?

What is the correct implementation for out-of-stock products?

How do you audit a client's store for this issue?

Shopify sitemap drops live products: detect and fix it

Why does a live product fall out of the Shopify sitemap?

Why doesn't Shopify admin surface this problem?

Does a missing sitemap entry actually affect rankings?

How do you diagnose this in a client's store?

What's the fix once you've confirmed the gap?

Shopify noindex bug: detect and fix the seo.hidden metafield

What is actually happening?

Where does the noindex come from on Shopify?

How to confirm a noindex in under 5 minutes?

Is the noindex always a bug?

How to fix each cause?

Shopify availability mismatch breaking your clients' feeds

Why does Shopify availability diverge from the Merchant Center feed?

Why is this invisible in Shopify admin?

What does the mismatch actually cost?

How do you check a client's store for this?

What is the structural fix?

Shopify Product schema bugs killing clients' Google review stars

How do you verify the schema state before touching anything?

Why does a review app create duplicate Product schema?

What breaks when a JSON-LD block becomes unparseable?

How does a theme update silently drop structured data?

When does a price mismatch invalidate the schema?

How does a noindex tag remove review stars entirely?

Fix Shopify price mismatch killing clients' Merchant Center feed

Why does Google reject prices it can already read from the feed?

Where does the divergence come from in Shopify?

What does the fix look like in Liquid?

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

Google is showing the wrong price for my product — Shopify

How to confirm it yourself in 5 minutes

Causes, ranked by how often we actually see them

The fix

Next in this cluster

When is `identifier_exists: false` the right fix?