Citevera
Run free audit
All posts
6 min read

Product Schema and AggregateRating: The AEO Lift Most Stores Miss

Product schema with AggregateRating is the difference between AI engines summarizing your product page accurately and substituting a competitor's. Here is how to ship it correctly.

A product card with structured-data overlay showing price, brand, AggregateRating star value, and review count fields highlighted as AEO inputs.

When an AI engine answers "what is the best wireless mouse under $80", it does not crawl all of Amazon and rank products. It cites a small number of sources whose pages clearly express what the product is, what it costs, and how it has been received. Product schema with AggregateRating is the JSON-LD that makes that expression machine-readable.

Most product pages either skip Product schema entirely or ship a thin version that fails the AEO test. This post covers the full property list, the AggregateRating sub-block specifically, and the validation traps that disqualify your data.

Why Product schema is an AEO priority for ecommerce

Product schema does three things AI engines need:

1. Anchors the page to a specific product entity, not a category or brand-level claim. 2. Surfaces price, availability, and ratings in a structured form the model can extract verbatim. 3. References your Organization schema as the brand or manufacturer, reinforcing entity strength.

A product page without Product schema is still readable, but the AI engine has to infer the entity type, the price, and the trust signals from prose. Pages with clean Product schema win the citation battle on commercial queries because the model has higher confidence in the data.

The minimum-viable Product JSON-LD

Most ecommerce platforms ship something close to this:


{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Acme Wireless Mouse",
  "image": "https://acme.example/products/mouse-1200.jpg",
  "description": "Ergonomic wireless mouse with USB-C charging and 90-day battery life.",
  "brand": {
    "@type": "Brand",
    "name": "Acme"
  },
  "sku": "AM-MS-401",
  "offers": {
    "@type": "Offer",
    "url": "https://acme.example/products/wireless-mouse",
    "priceCurrency": "USD",
    "price": "59.00",
    "availability": "https://schema.org/InStock"
  }
}

This validates and surfaces price in Google rich results. It still leaves the AEO lift on the table because there is no AggregateRating, no review array, no GTIN, and no manufacturer reference back to your Organization.

The full Product schema property list worth populating

Priority-ordered for AEO:

1. name - exact product name as it appears on the page H1. 2. image - array of multiple absolute image URLs at print resolution. 3. description - 1 to 3 sentence summary, ideally matching your meta description. 4. brand - reference to your Organization or a Brand sub-entity. 5. manufacturer - if different from brand, the actual maker. 6. sku - your internal SKU string. 7. gtin8 / gtin13 / gtin14 / mpn - global product identifiers when applicable. 8. offers - Offer or AggregateOffer with price, currency, availability, validFrom. 9. aggregateRating - the AggregateRating block (full detail below). 10. review - an array of Review objects from real customers. 11. category - product category aligned with your site IA. 12. audience - intended buyer persona if defined. 13. material / color / weight / size - product-specific properties.

The first ten matter for AEO. The rest support disambiguation when you have variant pages or product families.

The AggregateRating sub-block in detail

This is the AEO unlock most stores miss. The full block looks like:


"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "4.6",
  "reviewCount": "284",
  "bestRating": "5",
  "worstRating": "1"
}

Four properties matter:

  • ratingValue - the average rating as a string, ideally to one decimal.
  • reviewCount - integer count of reviews.
  • bestRating and worstRating - establishes the scale so the model does not assume 5-star.

Stores sometimes ship ratingValue without reviewCount. AI engines strongly downweight or skip ratings without a count because they cannot judge statistical significance. A 5.0 from 2 reviewers is not a 5.0 from 280 reviewers. Always include the count.

reviewCount should reflect actual reviews displayed on the page. Inflating the count creates a contradiction the model can detect by counting visible reviews, and it can disqualify the entire AggregateRating block in some engines.

Where AggregateRating goes wrong in production

Five recurring issues:

  • Ratings without backing reviews. AggregateRating with reviewCount of 0 or with no review array trips spam filters in some engines. Either remove it or populate the review list.
  • Stale aggregate after review deletion. When customers delete reviews, the count must update. Cached schema is a common culprit.
  • Numeric vs string formatting. Google accepts both, but some validators are strict. Prefer string for safety.
  • Different rating in JSON-LD vs visible UI. A "4.8 stars" badge on the page paired with ratingValue: "4.6" in JSON-LD looks like manipulation. Engines penalize.
  • Rating across all variants vs per-variant. Decide whether a product family shares one rating or each variant carries its own. Be consistent and document the decision in your platform.

Reviews schema alongside AggregateRating

A populated review array reinforces the AggregateRating with verifiable individual entries:


"review": [
  {
    "@type": "Review",
    "author": {"@type": "Person", "name": "Jordan T."},
    "datePublished": "2026-04-15",
    "reviewBody": "Lightweight, three-week battery, palm-rest comfortable for 8 hour days.",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "5",
      "bestRating": "5"
    }
  }
]

Five to ten current reviews in the JSON-LD is plenty. The entire review corpus does not need to be embedded; the AggregateRating handles aggregate signals while the review array provides representative voice.

Connecting Product schema back to your Organization

The brand and manufacturer properties should reference your Organization schema, ideally by @id:


"brand": {
  "@id": "https://acme.example/#organization"
}

This requires that your homepage Organization schema includes "@id": "https://acme.example/#organization". With that linkage in place, the entity graph from Product to Brand to Organization is explicit, not inferred. AI engines that build internal entity graphs use these links to resolve product mentions to your company.

How Product schema interacts with collection and category pages

Three conventions worth following:

  • Product detail pages carry full Product schema as above.
  • Collection or category pages carry ItemList schema with each item as a Product reference, not full Product blocks.
  • Comparison pages that pit your product against a competitor carry Product schema only for your product, with the competitor referenced in prose.

The ItemList convention prevents schema bloat on category pages while still giving engines a structured listing. Avoid embedding 60 full Product blocks on a single collection page.

Product schema and the AEO content layer

Schema is necessary but not sufficient. The page body still has to do AEO work:

  • Open with a one-paragraph product summary including the canonical name, category, and primary differentiator.
  • Use H2s for "specifications", "what is included", "use cases", "comparison to alternatives".
  • Include a "frequently asked questions" section with FAQ schema for the top 5 to 8 buyer questions.
  • Cite real performance data with sources where claims are verifiable.

The product page AEO playbook covers the content side in detail. Schema provides the entity scaffolding; the prose carries the citable claims.

Validation and monitoring

Three checks worth running monthly:

  • Schema.org validator confirms syntactic correctness.
  • Google Rich Results Test confirms the Product and AggregateRating render as expected and shows the structured-data preview.
  • Diff against your DB - your e-commerce platform should hold ground truth for price and rating; the JSON-LD should match. A nightly diff catches CMS bugs before they damage citations.

Key takeaways

  • Product schema with AggregateRating is the AEO unlock most stores miss, costing them citations on commercial queries.
  • The AggregateRating must include reviewCount, bestRating, and worstRating, not just ratingValue.
  • Reviews displayed on the page must match the JSON-LD or engines downweight the block.
  • Link brand and manufacturer back to your Organization with @id for explicit entity resolution.
  • Use ItemList on collection pages, not 60 nested Product blocks.

What to do next

Run a free audit at scan.citevera.com to see whether your product pages ship Product and AggregateRating schema and whether the data matches what your customers see.

For ecommerce-specific AEO patterns beyond schema, ecommerce AEO and product discovery covers content structure and category architecture.

Related reading