Review schema: what is allowed, what is shown, what is self-serving

Review structured data makes a page eligible for the review snippet rich result. That is the star rating, the count of ratings and sometimes a short quote.

Structured data is not a ranking factor by itself. It helps machines read your page and can add features in results. You still need a useful page.

• Google recommends JSON-LD. Microdata and RDFa are also read.
• JSON-LD can sit in the head or the body. Google renders, so script-injected markup is seen.
• The Rich Results Test shows eligibility and missing fields. The Schema Markup Validator checks schema.org syntax only.

Google supports review snippets for specific types. Mark up one of these as the thing being reviewed, not a generic web page.

• Product
• SoftwareApplication
• Book
• Course
• Event
• LocalBusiness
• Movie
• Recipe

Pick the closest real type. If you sell a SaaS, use SoftwareApplication. If you sell a physical item, use Product. For a restaurant, LocalBusiness. For a guide, no review rich result applies.

Google does not show rich results for self-serving reviews of a business on its own site. That covers LocalBusiness or Organization marked up as the itemReviewed on your domain.

Reviews of a product or a software app on your site are allowed. Your own product page can show stars if you have genuine customer reviews or an aggregate rating and you mark up Product or SoftwareApplication.

If you want business-level stars, link to third-party profiles. For example, a /reviews page can embed G2 or Google Business Profile widgets, but do not mark them up as LocalBusiness reviews on your own domain.

You can mark up either an aggregate rating or individual reviews. You can also include both on the same page.

For clarity, include bestRating and worstRating to define the scale. Keep rating values in range. 4.6 on a 1 to 5 scale is fine. 8 on a 1 to 5 scale is not.

Two graphs are common. One where the itemReviewed holds aggregateRating. One where the Review references the itemReviewed. Keep the thing being reviewed as a supported type and make fields complete and consistent with the page content.

• itemReviewed: a supported type such as Product or SoftwareApplication, with a name that matches the page
• aggregateRating: ratingValue and ratingCount or reviewCount
• Review: reviewRating.ratingValue and bestRating, author.name, datePublished in ISO 8601, reviewBody if you show a quote
• URL fields: use absolute URLs, not relative
• Only mark up content that users can see on the page

If your page is also a buy page, Product markup may include offers. For product rich results you need name and at least one of review, aggregateRating or offers. This is separate from the review snippet, but can be on the same page.

For a SaaS, use SoftwareApplication. Name and offers.price with offers.priceCurrency are required for the app rich result, plus a rating. You can provide aggregateRating or a Review there too. Free apps use price 0.

This example shows a product page with visible ratings and one quoted review. Values are typical examples, not measured. It validates for review snippets in the Rich Results Test if the same content is on the page.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Product",
      "@id": "https://yourproduct.com/product/widget-pro#product",
      "name": "Widget Pro",
      "image": [
        "https://yourproduct.com/images/widget-pro-front.jpg"
      ],
      "sku": "W-PRO",
      "brand": {
        "@type": "Brand",
        "name": "YourBrand"
      },
      "aggregateRating": {
        "@type": "AggregateRating",
        "ratingValue": 4.6,
        "bestRating": 5,
        "worstRating": 1,
        "ratingCount": 57
      }
    },
    {
      "@type": "Review",
      "@id": "https://yourproduct.com/reviews/9876",
      "itemReviewed": {
        "@id": "https://yourproduct.com/product/widget-pro#product"
      },
      "author": {
        "@type": "Person",
        "name": "Alex Taylor"
      },
      "datePublished": "2026-09-14",
      "reviewBody": "Setup took five minutes. Shipping was quick. The battery lasts longer than expected.",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": 5,
        "bestRating": 5,
        "worstRating": 1
      }
    }
  ]
}

Use absolute URLs for @id and images. Keep the product name and the quoted text exactly as shown to users. Dates use the YYYY-MM-DD format.

Google needs signals that the ratings are real and match the page. It also checks that the reviewed item is clear and supported.

• Third-party review sites: link to and embed your profiles on /reviews or the product page. Do not mark up LocalBusiness reviews on your own domain.
• In-app reviews: surface your own product’s ratings and quotes on /product/some-feature or /customers. Mark up Product or SoftwareApplication, not your company.
• Release notes and changelogs: do not mark these up as reviews. They are not reviews.
• Support tickets and NPS: do not mark these up either. They are not public product reviews.

A good product page shows the star average near the title, the count of ratings, and a set of quotes with dates and names. Your markup should match that layout one for one.

1. 1

   Choose the right type

   If this is a SaaS app page, use SoftwareApplication. If it is a physical item, use Product. Do not use Organization or LocalBusiness to rate yourself.

2. 2

   Map visible elements to fields

   Decide where ratingValue, ratingCount, author.name, datePublished and reviewBody come from. If it is not visible on the page, do not mark it up.

3. 3

   Add JSON-LD

   Place one script type="application/ld+json" in the head or body. You can inject it with JavaScript. Keep URLs absolute and dates in ISO 8601.

4. 4

   Validate syntax

   Open validator.schema.org and paste the rendered HTML or URL. Fix schema.org errors until it parses cleanly.

5. 5

   Check rich result eligibility

   Run search.google.com/test/rich-results. Pick Review snippet. Fix missing required fields, ranges and URL issues until it shows eligible.

6. 6

   Ship and monitor

   Deploy. In Search Console, watch the review snippet enhancement report. Fix errors and warnings as they appear.

The validator and the Rich Results Test both read the rendered page. If you inject JSON-LD after load, the tests still find it. AI crawlers that answer questions do not run scripts, so server-rendered markup helps them read it.

• Missing required field: add ratingValue and ratingCount to aggregateRating, or author and reviewRating to Review.
• Relative URL used where absolute is needed: change /images/x.jpg to https://yourproduct.com/images/x.jpg.
• Date not in ISO 8601: change Sep 14, 2026 to 2026-09-14.
• Price as text with a currency sign: in offers, use price: 30 and priceCurrency: USD, not "$30".
• Rating out of range: keep 1 to 5 if bestRating is 5. Do not send 6.
• Content not visible: only mark up reviews and ratings that users can read on the page.
• Broken graph: ensure itemReviewed points to the Product or SoftwareApplication node with a stable @id.

A page can carry several types in one @graph. Keep each node clean and link them with @id when needed. Do not duplicate the same facts across nodes in conflicting ways.

• Product with aggregateRating and offers on /product/widget-pro.
• SoftwareApplication with aggregateRating on /pricing if that page is about your app and shows ratings.
• BreadcrumbList for navigation. It replaces the URL line in results.
• Organization for your logo and sameAs. This is separate from reviews and helps the knowledge panel.

Avoid marking up FAQs for stars. FAQ rich results only show on government and health sites as of 2026. You can keep FAQPage markup for assistants, but it will not add features in Search for a product site now.