Valid schema does not mean each price points to the right variant
Summary
A green validator result confirms that markup is well formed. It does not confirm that a price, an availability value or a review set resolves to the variant a shopper is looking at.
Audits of nested @graph markup should follow every @id reference to the node it names, and treat an offer no outside reader can place as a defect worth fixing.
A post in r/TechSEO describes a product page whose structured data came back valid while the facts a shopper cares about sat deep inside a nested @graph. The data existed, the thread says, and passing validation still did not mean every consumer would read the relationships between those facts as intended.
The thread lists four things a green result leaves open on an ecommerce page:
- The page has to make clear which price belongs to which variant.
- A displayed price has to say whether it recurs or is charged once.
- Availability has to sit on the right SKU.
- Reviews have to describe the product rather than the whole category.
Each of those is a question about pointers rather than syntax. Nodes in an @graph carry an @id, and the relationship between two nodes is a reference to that identifier, so a product, an offer, a SKU and a set of reviews can all be valid nodes while the reference joining two of them is missing, duplicated, or aimed at the parent group instead of the variant on screen. A validator confirms that the JSON parses and that the types and properties are real ones. It cannot know which of a page’s sizes the single price belongs to.
What an audit can check is that every reference lands somewhere specific. On a variant URL, the offer reference should name the node for that variant and nothing broader, as in this sketch:
{
"@id": "https://example.com/shirt#blue-m",
"@type": "Product",
"sku": "SHIRT-BLUE-M",
"offers": { "@id": "https://example.com/shirt#offer-blue-m" }
}
Every @id referenced anywhere in the markup should resolve to a node defined on the same page. A reference to a node that is not there validates fine and tells a consumer nothing.
No one in the thread reports a lost rich result or a misreading by a named search engine, so the cost of the problem is unproven. The likelier risk is that an offer a human cannot place is an offer a parser may place wrongly too, and product-page markup has gone wrong unnoticed before: a Shopify review app was found adding duplicate FAQ schema to product pages. Checking tools that approve markup real consumers never honor is a familiar gap, and hreflang tools do the same thing when they clear tags that AI crawlers never see.
What to do
One commenter in the thread suggests keeping a small set of real product-page test cases, checking Google’s rendered interpretation of them, and tracing each price, offer, availability value and review back to the exact SKU or entity it describes. The same comment adds a cheap test for tangled markup: ask someone who has not seen it to say what each offer belongs to. If that person cannot answer, the better bet is to treat the markup as a defect rather than a style preference, and to give each variant its own node with its own sku, its own offer and its own availability. Reviews get the same treatment, with the rating pointing at the product node and not at a collection or brand node above it.