Product pages that answer engines can quote

A product page that answer engines can quote states its facts in text, in the HTML response: what the product is, its specifications with units, its price and availability, which variant each figure applies to, and who it is and isn’t for. Most product pages hold all of that information and still give an extractor almost nothing, because the specs are an image, the comparison is a tab loaded on click, the fit guidance is a marketing line, and the reviews arrive by script after the page loads.

The questions people put to assistants about products are specific: how much does it weigh, does it work with this, which size do I need, is it good for that. A page that answers them in plain sentences and real tables has something to lift. A page that answers them in a carousel does not.

This post covers what to put where on a product page, the structured data Google documents for products and variants, the review rules that keep markup honest, and how to check one page and a whole catalog. It sits under Answer Engine Optimization: a page-level guide.

What does a product page need to answer?

A product page needs to answer the factual questions a buyer asks before purchase, each in a place an extractor can reach. Most of them fall into six types:

Question type	Example	Where the answer should live
Specification	”How much does the ARM-X9 weigh?”	A row in an HTML spec table, with the unit in the cell
Price and availability	”How much is it, and is it in stock?”	Visible text near the top, matched by `Offer` markup
Fit	”Is it good for small workshops?”	A direct sentence under a heading that asks the question
Compatibility	”Does it work with the X5 controller?”	A list of named compatible products, in text
Variant choice	”Which model has the longer reach?”	A comparison table across variants, each row named
Terms	”What’s the warranty?”	A sentence stating the term, linked to the full policy

The example product, the ARM-X9, belongs to a fictional robotics company used throughout this post; its figures are illustrative.

Put the specification table in HTML

A specification table is the most quotable thing on most product pages, and it only survives extraction as a real <table> in the HTML response. A table drawn as an image has no text. A grid of div elements styled to look like a table loses its rows and columns when flattened. A table inside a tab that is fetched when clicked was never in the response.

Three rules carry most of the value:

Units inside the cells. “12 kg,” not “12” under a column header that says “Payload (kg).” A row lifted out of the table keeps its cells, not necessarily its header.
A sentence before the table saying what it compares. “Specifications for the ARM-X9 and ARM-X9 Long, as of October 2026” gives the table a subject that travels with it.
Every variant named in its own row or column. A figure that applies to one variant only should say which.

Tables and lists that survive extraction covers the markup in detail. If the table is currently inside a tab or accordion, check whether its content is in view-source; JavaScript content and what never makes the trip explains the difference between a panel hidden by CSS and one fetched on click.

Answer “is it good for this” in a sentence

The fit question is the one product pages answer worst, because it is the one marketing copy is written to avoid. “Built for every workflow” answers nothing. An answer engine asked whether a product suits a use case needs a sentence that names the use case and the conditions.

Before:

The ARM-X9 delivers industry-leading flexibility for teams of any size.

After:

The ARM-X9 suits small workshops that need to move parts up to 12 kg within an 850 mm reach. It is not rated for food-contact environments; for those, the ARM-X9 Hygienic variant carries the relevant certification.

The second version names the product, the use case, the limits, and an alternative. The “not for” sentence matters: it is the part a careful buyer is looking for, and it is the part that makes the rest credible. Put the fit question as a heading and the answer directly under it, so the first sentence is the answer; the 40–60 word answer block covers the pattern.

Product and Offer structured data

Product markup is a machine-readable statement of the facts the page already shows. Google states there is “no special schema.org structured data” required to appear in AI Overviews or AI Mode, and that you should make sure “your structured data matches the visible text on the page” (Google Search Central). So the case for Product markup on answer surfaces is not a ranking feature; it is an unambiguous statement of name, price, and availability that agrees with the page.

Google documents two product experiences: product snippets, “for product pages where people can’t directly purchase the product,” and merchant listings, “for pages where customers can purchase products from you” (Google Search Central, last updated 2025-12-10). For product snippets, the required properties are name plus one of review, aggregateRating, or offers (Google Search Central, last updated 2026-09-08). Merchant listings support additional details such as shipping and returns; the merchant-listing documentation sets out their requirements.

A minimal, illustrative example:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "ARM-X9 Collaborative Robot Arm",
  "sku": "ARMX9-STD",
  "brand": { "@type": "Brand", "name": "Example Robotics" },
  "description": "Six-axis collaborative arm with a 12 kg payload and 850 mm reach.",
  "offers": {
    "@type": "Offer",
    "price": "18500.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/arm-x9/"
  }
}

Every value in it should be visible on the page. Google’s policies say “don’t mark up content that is not visible to readers of the page” (Google Search Central, last updated 2026-07-10). The common failure is drift: a price changes in the page template and not in the markup, or the reverse, and nothing alerts anyone.

Some assistants also accept merchant product feeds; OpenAI, for example, publishes a product feed specification. A feed is a separate channel from the page and outside the scope of this post. The page still has to stand on its own for every crawler that reads it.

Variants: say which one the figure belongs to

Variants are where product facts most often become ambiguous. A page that offers three sizes and states “weighs 2.4 kg” has stated a fact about one of them.

Google documents variant markup using ProductGroup to group variants, hasVariant to nest each variant Product, variesBy for the attributes that differ (such as size or color), and productGroupID for the parent SKU (Google Search Central, last updated 2026-09-08). It distinguishes two site designs:

Single-page: all variants are selectable on one page without reloads, and “there must be only one distinct canonical URL” for the group.
Multi-page: variants live on separate URLs of equal importance, and there is no single canonical URL for the group.

Pick one and make the canonicals agree with it. A multi-page design whose variant URLs all canonicalize to one parent tells crawlers the variant pages are duplicates; a single-page design that spawns parameter URLs with self-canonicals splits the product across many addresses. Status codes, redirects, and canonical drift covers how to check which URL is actually being treated as the page.

In the text, put variant differences in one table with each variant named, and name the variant in any sentence that states a variant-specific figure.

Reviews: what you can show and what you can mark up

Reviews are often the most specific text on a product page and the most often mishandled. Google’s review-snippet guidelines set the rules for markup (Google Search Central, last updated 2026-09-08):

Review content you mark up must be “readily available to users from the marked-up page,” and it must be “immediately obvious to users that the page has review content.”
“Don’t aggregate reviews or ratings from other websites.”
Where the entity being reviewed controls the reviews about itself, pages using LocalBusiness or any other Organization markup are ineligible for review snippets. That rule is about organizations reviewing themselves, not product reviews from customers.

For product markup, Google also requires that a reviewer’s name be “a valid name for a Person or Team” (Google Search Central).

Two practical consequences. A rating that appears only in markup, with no visible reviews, breaks the visibility rule. And reviews injected by a third-party widget after load are absent from the HTML that non-rendering crawlers receive; if the review text matters to you as content, it needs to be in the response, and the markup should describe what is visibly there.

How to check one product page by hand

Six checks, in a browser, on your best-selling product:

View source and find a spec value such as the weight. If it is not in the raw HTML, the spec table is an image or arrives by script.
Confirm the spec table is a <table> in view-source, with units in the cells.
Read the first sentence under each heading. Is there one that answers a fit question directly, with a “not for” where it applies?
Paste the URL into a structured-data validator. Confirm Product parses, and that price, priceCurrency, and availability match what the page shows.
Switch variants and check whether the URL, the canonical, and the visible figures change together.
Check whether the reviews you see are in view-source, and whether the markup claims only what is visible.

How to check a catalog

Across a catalog, the same checks become extraction rules in a crawler and columns in a spreadsheet:

count(//main//table) for whether a product template has a real table at all; zero across a template is one fix.
//script[@type='application/ld+json'] as text, then filter the spreadsheet for rows missing "Product" or "offers".
Your visible price selector as text in one column, and the JSON-LD price value in the next, with a formula comparing them. Every mismatch is drift.
//link[@rel='canonical']/@href beside the URL, to find variant URLs that canonicalize somewhere unexpected.

In GEOBee, the Schema column reports the detected type for each URL and validates required fields, including that a Product has a name and offers; pages read as None, Invalid, or Partial when markup is missing or incomplete (the three lenses). Product is one of the answer-relevant schema types the AEO lens scores.

Product pages are also where citability and entity signals carry real weight, since the brand behind the product is part of the answer; citability and entity signals covers the Organization side.

None of this makes an assistant recommend your product. It makes sure that when a page is read, the answer to the buyer’s question is on it, in words, with the right variant attached.

To find every product template with no table, missing Product markup, or Partial schema across a catalog, download GEOBee and run a crawl during the 7-day trial.