Why Do AI Shopping Answers Cite Specs for Some Products and Reviews for Others?

Short answer: you cannot choose which of your page sections an assistant will quote. The question does. Ask "what is the quietest 12-cup coffee maker under 200 dollars" and the answer will lean on specifications and a ranking or roundup. Ask "is the Delonghi Magnifica actually worth it after a year" and it will lean on review themes. The same product, the same page, two different evidence blocks.

This matters because merchant teams tend to invest in one block. Some catalogues are all specification tables with four reviews. Others are review-heavy pages where the specifications live in a PDF or an image. An assistant answering the query shapes your category actually receives will reach for whichever block is richer — and if it is not yours, it will take the block from someone else's page.

## The three evidence blocks, and what each one answers

Retrieval into a shopping answer is not selecting a page. It is selecting a sentence whose shape already matches the question. Three shapes dominate product questions.

The ranking or comparison block. Answers "which one", "best for X", "what is the cheapest that still does Y". This block is comparative and sequential: it names several products and orders them. A product page alone rarely forms it. It gets assembled from comparison pages, buying guides, and structured listing data. If your catalogue has no page that names your products alongside alternatives, you are supplying none of this block and depending entirely on third parties to form it.

The specification block. Answers "does it fit", "how loud is it", "will it work with my setup". This block is factual and checkable: dimensions, materials, capacity, compatibility, power, and the units buyers actually use. It is the block a merchant can own completely, because nobody else has your parameters. It is also the block most often trapped in images, size charts, or PDFs — invisible to a text extraction pass.

The review-theme block. Answers "is it any good", "does it last", "what goes wrong". This block is experiential and hedged: patterns across many buyers, not a single opinion. Merchants do not author it directly — it is assembled from reviews on your own site and from marketplaces and forum threads about you. You influence it by what you invite in post-purchase messages and by whether the theme appears anywhere on your page in your own words.

## Which question types are actually being asked in your category

The reason teams misallocate effort is that they guess the query mix. A short procedure fixes that.

1. Collect the questions. Pull every product question from live chat, support email, and pre-sale tickets over the last two quarters. These are real, and they cluster. 2. Sort them into the three blocks. "Which one should I get" is ranking. "Will it fit a 60 cm gap" is specification. "Does it hold up after a year" is review theme. 3. Count the split. A category selling furniture usually splits heavily toward specification. A category selling skincare usually splits toward review theme. Neither is wrong; they need different blocks. 4. Audit the block you are losing on. Take the highest-volume question type and check whether a single paragraph on your site answers it, in text, in the units buyers use. 5. Check whether the other blocks are even supplied. If nobody on the open web compares your products, you have a ranking-block gap that no amount of product-page editing closes.

## What to publish for each block

• Ranking block: a comparison page that names your models side by side on the two or three axes buyers decide on. Not a table of every attribute — the deciding axes only.
• Specification block: the numbers in HTML text, with units, on the product page itself. Not in the gallery, not in a downloadable chart. State the boundary values too: the maximum load, the minimum clearance.
• Review-theme block: your own summary of what buyers consistently report, written as a paragraph the model can lift. If durability complaints recur, addressing them on the page is more useful than leaving the theme to be summarised from a marketplace listing.

Most stores already have the raw material for all three. What they lack is the material in extractable text, attached to the right question type.

## A worked example

A kitchen-equipment store had strong reviews and weak specifications. Questions arriving in support were overwhelmingly fit-and-compatibility: whether a machine clears a standard upper cabinet, whether the water tank is removable for a shallow sink. None of it was in page text — all of it in the product photography.

The fix took an afternoon. Dimensions with units, tank removal, clearance requirements below the upper cabinet line, and a short compatibility list went into the product description. No new content strategy, no new pages. The specification block simply began to exist where a retrieval pass could read it.

The reviews were already fine. They were simply not the block that category's queries were asking for.

## Measuring without assistant-side analytics

You will not get a dashboard telling you which block was cited. Useful proxies instead:

• Search your category's qualified questions in an assistant and read which sentence got lifted. If it came from a review, and your page's strength is specifications, that is a mismatch signal for that query type.
• Track which question types reach support after a buyer has already been in an assistant. If fit questions persist, your specification block is not being read.
• Watch whether competitor comparison pages are the sources named for "which one" questions in your category. That tells you who is supplying the ranking block.

## FAQ

No. Prioritise by the query mix in your category. If buyers decide on fit and compatibility, the specification block comes first. If they decide on durability and satisfaction, review themes matter more.

It changes whether your block is available at all. If no extractable paragraph exists, the assistant sources that block elsewhere. Whether it then quotes you is a separate question and depends on the query.

Only if review-themed questions dominate your category. Volume of reviews without extractable text on the page still leaves the theme to be assembled from wherever the reviews are hosted.

Structured data makes the specification block machine-obvious — ratings, availability, price, and attributes in fields the crawler reads directly. It does not create the review-theme block, which lives in prose.

For a page-by-page read on which blocks exist in extractable text on your store today, run the free scan at /audit. It reports the facts present on each URL, the buyer questions left unanswered, and the values that conflict between your page and your feed — a diagnostic, not a guarantee.