This is a repost. Originally published on the Arvio blog: https://arvio.a.xyz/blog/shopify-structured-data-errors. The canonical URL points back there.
Published September 3, 2026 by Adot Technologies Inc, the team behind Arvio: AI Store Operator. The counts below come from parsing every JSON-LD block on 84 product pages across 30 live Shopify storefronts on September 3, 2026.
The obvious way to attack a structured data problem is product by product: audit the catalogue, fix the bad ones, keep auditing.
We went to check that. Seven things that can go wrong, 84 product pages, 30 distinct storefronts. Four of the seven never happened once. Two of the three that did were store-wide: every store that published no product markup published none on every page we read, and every store with an unparsable block had one on every page. The third — a product node with no image — varied from page to page inside the same store.
So checking gets cheaper. If your markup is broken, one product page will tell you.
Key takeaways 23 of the 30 stores had none of the three failures, on every page we read — two or three pages each, from a convenience frame of stores that asked a public forum for feedback, not a random sample of Shopify. Seven pages published no product markup at all — four of them carried no JSON-LD whatsoever, three carried only a business block. All seven came from three stores. Six pages carried a JSON-LD block that will not parse. All six still had valid product markup: the broken block sits beside the product node, not on top of it. Two stores, every page. Four errors people are warned about did not occur once: no page carried competing product nodes, no price was non-numeric, no availability value was unrecognised, and every variant-group node carried its variants. The one place the page and the catalogue disagreed, the page was the pessimistic one. Prices agreed on all 77 pages that had a product node. Availability disagreed on exactly one page: the markup said out of stock for a product the catalogue said you could buy.
Structured data breaks by store, not by product Structured data comes from your theme. The fields it publishes come from your catalogue — and that half is what Arvio reads, drafts, and hands back for your approval. Install Arvio on the Shopify App Store →
Structured data is in the HTML your storefront serves anyone. Pick any product page and run this. It prints one line per JSON-LD block, says whether the block parses, and names the types inside it:
Six of the seven checks below are in that output. Whether a Product or ProductGroup type appears at all, and whether any block says DOES NOT PARSE, are the first two lines you read. Whether image is in the key list next to the product type is the third. The last line — product nodes on this page — is the competing-nodes check: anything above 1 is two product nodes fighting over the same page. And the indented offer lines are the format checks: price should be a bare number, not $24.00, and availability should be one of the schema.org values. A ProductGroup prints its hasVariant count, and a group that publishes no variants prints 0. The seventh check, whether the markup agrees with your catalogue, needs a second request — to your own /products.json.
One caveat on running it once: our sample is at most three product pages per store, and one store gave us only one. So when we say a failure was the same on every page of a store, that means the two or three pages we read, not the catalogue.
| What we checked | Pages | Stores | |---|---|---| | No product markup on the page at all | 7 of 84 | 3 | | A JSON-LD block that will not parse | 6 of 84 | 2 | | Product node with no image property | 5 of 77 | 3 | | Two or more competing product nodes | 0 of 84 | 0 | | A price that is not a number | 0 of 77 | 0 | | An availability value outside the vocabulary | 0 of 77 | 0 | | Variant group published without its variants | 0 of 27 | 0 |
Of the 84 pages, 50 published a Product node, 27 published a ProductGroup, and 7 published neither. The typical page carries two JSON-LD blocks; 44 of the 84 do.
Seven pages, three stores. One store served no JSON-LD at all on all three pages we read; a second served exactly one block on each of its three pages, describing the business rather than the product; the third had only one page in our sample, and that page carried no JSON-LD either.
Those seven pages are not all the same failure. Four of the seven served no JSON-LD at all — not a business block, not a breadcrumb, nothing. The other three served exactly one block describing the business, and nothing describing the thing for sale. Those three pages do have something a validator can approve of — an organisation block — and nothing at all describing the thing for sale. We did not run a validator against them, so what any specific tool reports is not something this survey can tell you.
This looks like a theme-level property: in all three stores it held on every page we read. We did not record which theme or app each store runs, so we cannot say which of those explains it.
What that costs, stated the only way we can state it. We have no traffic data for these stores, so we cannot tell you what those seven pages lost. What we can tell you is what Google publishes as the rule. Its product structured data documentation says: "You must include the required properties for your content to be eligible for display as a rich result." — and the required properties for a product snippet are "Product snippets require either review or aggregateRating or offers", with the page needing "You must include one of the following properties: review aggregateRating offers". A page with no product node has none of them. So the seven pages are not a style problem with an unknown cost: on the platform's own written rule they are outside the door, and the three that publish an organisation block instead are outside it in exactly the same way. What we cannot tell you — and nobody can from the outside — is how much traffic was on the other side of that door for these particular stores.
Six pages, two stores, every page we read from each. On all six, the page still carried a valid product node.
The combination matters more than either half. One store's pages carried four blocks each — a breadcrumb, a website block, the product, and one that would not parse. The other's carried three — a business block, the product, and the broken one. On all six pages exactly one block was malformed. A parser that stops at the first error reports the page as broken. A parser that reads block by block gets the product fine and discards only the block that failed. We have no Search Console for these stores, so which of those any given search engine does is outside what we measured.