Most AEO advice for product pages stops at content: write clearer specs, structure your FAQs, answer the comparison question before the user asks it. All of that assumes the content is actually reachable. On a lot of Shopify PDPs, it isn't not because it's missing, but because of how it's delivered.
Price, variant selection, and stock status are frequently injected client-side. A theme fetches variant data through the Storefront API or a theme-specific JS bundle after the initial page load, then swaps it into the DOM once the customer picks a size or color. A browser handles this invisibly. A retrieval system fetching your PDP for an AI answer engine may not.
Where this breaks
When an LLM-facing crawler or agent requests a URL, what it gets back depends on how that request is made. Some retrieval pipelines execute JavaScript and wait for hydration, much like a browser render. Others take the raw HTML response and parse it as-is, no JS execution involved. If your theme relies on client-side rendering for anything price- or availability-related, a non-JS-executing fetch sees a page with an empty price node, a default "select options" state, or a stock indicator that hasn't resolved yet.
The content itself might be excellent the copy, the specs, the answer to "does this run small." None of that matters if the specific fact being queried, like current price or whether a size is in stock, isn't present in the payload the retrieval system actually captured.
This is a different failure mode from the one covered in the indexed-vs-cited piece. That was about whether content gets selected for citation. This is earlier in the pipeline: whether the content is even present in what gets fetched. A page can be perfectly structured for citation and still fail here.
How to check what's actually being served
View-source is a reasonable first pass it shows the initial HTML response before any JS runs. Compare that against the rendered DOM (inspect element after the page has fully loaded and hydrated). If price, variant, or availability data is present in the rendered DOM but absent or placeholder-only in view-source, that data lives entirely in the client-rendered layer.
For a more precise picture, fetch the PDP URL directly with a plain HTTP request (curl, or a simple script) and diff that raw response against the rendered DOM. The gap between the two is exactly what a non-JS-executing retrieval pass would miss.
Server-side rendering closes most of this gap by default, since the data is already in the payload on first response. Shopify's Hydrogen storefronts and server-rendered themes behave this way. Fully client-hydrated themes, or ones that lean on JS for variant switching without a server-rendered fallback, are the ones worth auditing.
Schema as a fallback source of truth
Even on a client-rendered theme, structured data can carry the load JS-dependent DOM content can't. A Product schema block with price, priceCurrency, and availability filled in and kept in sync with actual inventory, not left stale gives a retrieval system a static, parseable source for exactly the facts most likely to be missing from the raw HTML. It doesn't fix the underlying rendering gap, but it gives retrieval something reliable to fall back on regardless of how the fetch is executed.
Worth checking: does your schema block update when variant selection changes, or is it fixed to whatever the default variant was at page load? A static schema tied to one variant reintroduces the same problem for every non-default variant on the page.
Where this fits in the bigger picture
Query fan-out mapping assumes the retrieval layer can actually reach the content block being matched against a sub-query. If price or availability lives only in a post-hydration DOM state, no amount of query-mapping or content structuring upstream fixes the fact that it simply isn't in what got fetched. Rendering is the layer underneath content strategy, and it's worth auditing before assuming a citation gap is a content problem.
Top comments (0)