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.

This one cost us a few wrong images before we understood it, so here it is in full. The problem The what's-in-the-box panel and the feature-callout shot are the two AI-generated listing images most likely to be factually wrong. Not badly composed. Wrong. Three items in the box, four in the picture. A feature label paraphrased into a claim the product never made. Why it happens When you paste your product description into an image prompt, one call is doing two jobs: extracting the facts, then rendering them. Image models are excellent at the second job and approximate at the first. Counting is the weakest part — an extra cable or a duplicated accessory costs the model nothing and looks entirely natural. The worst part is the failure mode. There is no error. You get a clean, plausible image, and plausible images get approved. The fix, in three steps 1. Extract first. Run a separate, cheap pass over the product description whose only output is strings — the exact contents list and short feature labels. Nothing else. 2. Inject verbatim. Those strings go into the image prompt untouched. Do not re-summarise them; a second summary is a second chance to drift. 3. Render last. The model now draws text it was handed rather than facts it inferred. We rebuilt this in ProductJSON Studio after our own callouts started miscounting. On the Aura lamp description the extraction pass returns the correct feature labels and exactly three box items, every run. Nothing about the image model changed. We just stopped asking it to read. A five-minute check you can run now Open your contents image and your packing list side by side and count. Then read the feature labels on your callout image and find each one in your own copy, word for word. Anything you cannot find, the model wrote. What has gone wrong in your set — miscounted items, invented features, or the wrong variant shown? Post it below and I will tell you which of the two jobs went astray. https://www.puniverse.net/products/productjson-studio?utm_source=skool&utm_medium=community&utm_campaign=productjson_studio_launch_01&utm_content=daily-2026-09-22

If you run any kind of site audit, this is the bug most of them share. Link validation is nearly always binary. Fetch the URL, read the status code, call it working or broken, score it. That logic is correct for a 404 and quietly wrong almost everywhere else, because plenty of links cannot be judged from a fetch at all. The example that forced the change here. Validating social links on a client store, Instagram returned a byte-identical response for a profile that exists and for a username invented on the spot. Same status, same shell, nothing to adjudicate. TikTok, the same class of link, was the opposite: uniqueId in the response for a real account, statusCode 10221 for one that is not there. Fully adjudicable. So the audit reports three outcomes. 1. Dead. Proven broken by an explicit not-found response. Scored. 2. Unverifiable. Cannot be judged from a fetch. Listed for a human to eyeball, never scored. 3. Ok. Proven good by a positive identifier. Scored. The rule underneath it: never score what you could not check. A score that quietly contains a guess is worse than a shorter, honest score, because the reader cannot tell which part was invented. Same reason a crawl that aborts halfway should refuse to publish a number rather than publish an optimistic one. Two sibling failures worth running on your own store this week. First, resolving is not the same as correct. On that store the Trustpilot links pointed at the www subdomain instead of the country one, in three separate places: the footer menu, a homepage section and the body of the reviews page. All three returned 200. All three landed on the wrong profile. No link checker will ever flag that, because nothing is broken. Second, verify in a browser, not a scripted fetch. A CDN edge cache produced three false findings on one launch day, and one store returned 429 to a script and 200 to curl in the same second. Same crawl rate, different client fingerprint. If your tooling and your browser disagree, the browser is the customer's view and the tooling is a hypothesis.

Quick test before you read on. Open a product page, view source, and search for the word review. On most Shopify stores you will not find it, even though the stars are clearly visible in the browser. That gap is the review app. It renders its widget in JavaScript. The shopper's browser runs the script, so they see the rating and the review text. The served HTML has neither, so anything reading the page without executing scripts finds a product with no social proof attached to it at all. Why the two obvious fixes are wrong Emitting aggregateRating on its own. It is one line of Liquid and it makes the field appear, but Google's guidance is that review markup must correspond to review content visible on the page. A rating with no readable reviews behind it risks your structured data being discounted across the site, not just ignored on that product. Filtering the feed to fours and fives. Tempting, and it reads as fake. A store with 25 reviews and not one below four stars tells a reader something you did not intend, and an assistant summarising your reviews has nothing balanced to say. What actually worked On an eight-product UK skincare store we rebuilt, the review app was already storing every review in a metafield on the product. So the theme reads that metafield, parses the real review objects out of it, and emits them inside Product schema alongside the product. Two consequences worth having: every review in the markup is one a visitor can scroll to and read, which satisfies the visible-on-page requirement by construction, and the honest one-star stayed in rather than being quietly dropped. We also filtered on content rather than rating. In that niche a review mentioning a medical condition cannot be published as a claim, so those were excluded on what they said, never on how many stars they gave. Run these three today 1. View source on a product page and search for aggregateRating. If it is there, confirm the individual reviews are also in the HTML and readable on the page.