This one cost an eight-product store several weeks of wrong copy, and nothing ever errored. The setup is common. A Shopify theme renders a custom metafield — a JSON blob, a page-builder block, a rich content field — instead of the native product description. The product page looks exactly as designed. Everything downstream ignores it: the cart and checkout the order confirmation email the Google Shopping feed /products.json, the public endpoint crawlers and AI assistants read Those surfaces read native fields. So a shopper can read your new copy while an AI assistant quotes your old claims to someone asking about your store. On the store I rebuilt, the metafield's image sources were theme asset filenames. The site showed the new photography; the cart, the order emails and the Google feed served the previous shots for weeks. The fix was two parts: put the curated images into Product Media properly, and generate the native description as a read-only mirror of the JSON, led by an HTML comment saying edits there do not change the site. That way a human editing the wrong box can see it is the wrong box. Three checks you can run today: 1. Open yourstore.com/products/your-handle.json and read body_html. Compare it with the page. If they disagree, that is your answer. 2. Place one test order and read the confirmation email. It reads native fields, not your theme. 3. Check which field your Google channel app is set to send — the SEO title or the product title. They are rarely the same sentence, and an SEO tweak then silently rewrites your Shopping listing. Fix the native field first. The theme is the easy part. What does your body_html say? Run check one and paste what you find — happy to tell you whether it matters. Free guide on making a Shopify store readable to answer engines: https://gumroad.puniverse.net/l/shopify-agentic-seo-guide?utm_source=skool&utm_medium=community&utm_campaign=shopify_growth_sprint_01&utm_content=daily-2026-11-02

I am new here and learning how these checks work

This one cost an eight-product store several weeks of wrong copy, and nothing ever errored. The setup is common. A Shopify theme renders a custom metafield — a JSON blob, a page-builder block, a rich content field — instead of the native product description. The product page looks exactly as designed. Everything downstream ignores it: the cart and checkout the order confirmation email the Google Shopping feed /products.json, the public endpoint crawlers and AI assistants read Those surfaces read native fields. So a shopper can read your new copy while an AI assistant quotes your old claims to someone asking about your store. On the store I rebuilt, the metafield's image sources were theme asset filenames. The site showed the new photography; the cart, the order emails and the Google feed served the previous shots for weeks. The fix was two parts: put the curated images into Product Media properly, and generate the native description as a read-only mirror of the JSON, led by an HTML comment saying edits there do not change the site. That way a human editing the wrong box can see it is the wrong box. Three checks you can run today: 1. Open yourstore.com/products/your-handle.json and read body_html. Compare it with the page. If they disagree, that is your answer. 2. Place one test order and read the confirmation email. It reads native fields, not your theme. 3. Check which field your Google channel app is set to send — the SEO title or the product title. They are rarely the same sentence, and an SEO tweak then silently rewrites your Shopping listing. Fix the native field first. The theme is the easy part. What does your body_html say? Run check one and paste what you find — happy to tell you whether it matters. Free guide on making a Shopify store readable to answer engines: https://gumroad.puniverse.net/l/shopify-agentic-seo-guide?utm_source=skool&utm_medium=community&utm_campaign=shopify_growth_sprint_01&utm_content=daily-2026-11-02

Short teaching post from opening up our own image pipeline this week. The question is simple: how big is the image the model just returned? We found the same dimensions field being produced three different ways, depending on which provider served the request. 1. The primary path resizes the bytes to the requested size before returning. The number is true because the file was made to match it. This is the only one of the three that is evidence. 2. The OpenAI fallback reads back the size string it put in the request. That model accepts a fixed set of sizes, so a request gets snapped to the nearest one, and nothing is resized afterwards. Usually right. Never verified. 3. The Gemini fallback never sends a size at all. It returns the dimensions that were requested, unchanged. That is not a measurement, it is an echo of your own input. All three return the same object shape, through the same function, into the same preview panel. From the outside they are indistinguishable. Why this bites a seller rather than just an engineer: Amazon enables zoom on a product image at 1,600 pixels on the longest side. Ask for a 3,000px master, have the request quietly fall back to a model that returns 1,024px, and your tool reports 3,000px. It uploads without complaint. The listing simply has no zoom, and there is no error message anywhere in the chain to go looking for. The blueprint, which costs nothing and takes an afternoon: 1. After every generation, read the width and height out of the returned bytes. Any image library does this from the file header in one line. Do not read them out of the response body. 2. Return the provider that actually served the image alongside the result, and show it in your UI. A silent fallback is the whole failure mode; make it loud. 3. Where the model was never told a size, treat the returned dimensions as missing rather than as confirmed. A default is a guess wearing a number. 4. Assert the minimum your channel needs before upload, not after. For Amazon that is 1,600px on the longest side for zoom.

This one is worth stealing because it fails silently, and silent failures are the expensive kind. What happened One of our price scrapers reads amazon.co.uk through a real logged-in Chrome. That is deliberate — a real browser walks through bot checks that a plain HTTP request gets stopped by. Last week it reported the Breo N5 at £56.99. Amazon's own SP-API said £74.99. Shoppers saw £74.99. Our repricer took the scraped figure and cut 21 prices to match a number that existed for nobody. Nothing errored. The page loaded, the selector matched, the parse succeeded, the write succeeded. The cause That browser holds an Amazon Business session. A business session shows ex-VAT first, surfaces business-only pricing and suppresses consumer deal prices. The page was not broken and the data was not corrupted. It was an honest answer to a different question: what does this cost a business buyer. There is a sibling fault in the same system. Block the scraper and Amazon serves a bot-check page — valid HTML, 2.5 KB, HTTP 200. Parse it naively and it reads as a legitimate empty result. A full shelf reports as no products, and about one request in three came back that way before we switched approach. The blueprint — run this on your own stack, no purchase involved 1. Write down what every scraper is signed in as. Not what you think it is signed in as. Open the browser it actually uses and check the account in the corner. 2. Move every scrape into a fresh, isolated browser context and dispose of it at the end of the run. In Chrome DevTools Protocol terms that is Target.createBrowserContext, navigate normally inside it, then dispose. Real page loads still clear bot checks; you just lose the session that was distorting the numbers. 3. Assert on the shape of the response, not the status code. A results page has results and weighs more than a few kilobytes. If the body is under about 5 KB or the result count is zero, treat it as a failure, not as data. 4. Reconcile one row before writing hundreds. Pick one product where you have a second source — an API, a manual check, a screenshot — and compare. One comparison would have stopped 21 bad writes.