Schema markup for reviews & local business: a GEO primer

Generative Engine Optimization (GEO) is often framed as a content problem — write clearer answers, get cited by AI Overviews and Perplexity. That's true, but it skips a layer. Before an AI answer engine can cite a claim, something has to extract it, and extraction is dramatically easier from a typed, unambiguous JSON object than from a paragraph of prose it has to parse and infer.

This is exactly what Schema.org vocabulary, embedded as JSON-LD, provides. A Review node with a reviewRating, an author, and a datePublished is not a guess an LLM has to make from surrounding text — it's a labeled fact. The same is true for an address in LocalBusiness, a price in an Offer, or a question-and-answer pair in FAQPage. Classic search rich results and generative answer engines are, in this sense, reading the same file for the same reason: it's the cheapest, most reliable way to know what a page is asserting.

That doesn't mean markup is a substitute for real signal. It's a translation layer. If the underlying reviews are thin, unverified, or gated, structured data just makes that clearer to the machine, faster. The rest of this guide walks through the types that matter most for a review-driven local or multi-location business, with working examples you can adapt.

Review represents a single review of a specific thing — a product, a book, a recipe, a local business. AggregateRating represents a rolled-up average across many reviews, with a count. Both need an explicit target via itemReviewed, and both need enough required fields to validate: an author, a reviewRating with a numeric ratingValue and a bestRating, and — for AggregateRating — a ratingCount or reviewCount.

A minimal, valid example for a single product review:

{
  "@context": "https://schema.org",
  "@type": "Review",
  "itemReviewed": {
    "@type": "Product",
    "name": "Acme Trail Runner v3"
  },
  "author": {
    "@type": "Person",
    "name": "Jordan Lee"
  },
  "datePublished": "2026-06-18",
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "5",
    "bestRating": "5"
  },
  "reviewBody": "Held up on a 40-mile week with zero blister issues. Runs slightly narrow."
}

Here's where the rules tighten. In 2019, Google stopped showing review-star rich results for self-serving ratings: a review of Entity A, hosted on Entity A's own site, about Entity A as a whole — whether marked up directly or pulled in through an embedded third-party widget. Practically, that means you generally cannot mark up "4.8 stars, 320 reviews" for your own LocalBusiness or Organization on your own homepage and expect it in the SERP. The restriction does not apply to Product reviews on a product page, and it does not apply on third-party sites that are actually independent of the business being reviewed — which is exactly why your Google Business Profile rating shows stars on Google's own properties, while the same number embedded on your homepage will not.

LocalBusiness (and its more specific subtypes — Restaurant, Dentist, AutoRepair, and dozens more) describes what a business is: its name, address, phone, hours, price range, and geographic coordinates. Organization is the broader, location-agnostic version for the brand itself. Neither is about opinion — that's what Review and AggregateRating are for — but LocalBusiness is the anchor most other markup on a local page nests under or references.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://www.example-dental.com/#business",
  "name": "Example Family Dental",
  "image": "https://www.example-dental.com/office.jpg",
  "telephone": "+1-925-555-0142",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1200 Main St",
    "addressLocality": "San Ramon",
    "addressRegion": "CA",
    "postalCode": "94582",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 37.7799,
    "longitude": -121.978
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
      "opens": "08:00",
      "closes": "17:00"
    }
  ]
}

Note what's absent: no aggregateRating block. For a business marking up itself, adding one here is the single most common way well-intentioned local SEO markup runs into the self-serving restriction described above. If you want your rating visible in a rich result, the reliable path is a well-optimized, complete Google Business Profile — not an aggregateRating on your own LocalBusiness node.

Three more types round out most content and location pages. FAQPage marks up literal question-and-answer pairs that are visibly present on the page — not a laundry list of every question a user might have, and not a duplicate FAQ block reused across dozens of pages with only the business name swapped, which Google has explicitly said it may treat as spam. BreadcrumbList describes the page's position in your site hierarchy, which helps both search results and an AI crawler understand how a location page relates to a parent category or brand. Site-wide Organization markup — logo, legal name, contact points, social profiles via sameAs — establishes the entity behind everything else so a reviewer or answer engine doesn't have to guess who's speaking.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do you accept walk-ins?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes, we hold same-day slots each weekday morning. Scheduled appointments are given priority."
      }
    },
    {
      "@type": "Question",
      "name": "Which insurance plans do you take?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "We're in-network with Delta Dental, Cigna, and Aetna. Call the front desk to verify your specific plan."
      }
    }
  ]
}

Vouch's own marketing pages follow this same pattern in practice: a site-wide Organization and WebSite block on every page, plus a page-specific Article, FAQPage, HowTo, or BreadcrumbList layered on top depending on the content type — the same builders referenced throughout this piece, just applied to our own site rather than yours.

Four mistakes account for most broken or rejected review markup:

• Marking up reviews that don't exist on the page. Google's guidelines require that marked-up review content be visible to users on the page it's attached to. Markup that references reviews collected elsewhere, or that inflates a count beyond what's actually shown, is a policy violation, not just a quality issue.
• Fake or incentivized reviews, marked up as if genuine. Structured data doesn't launder a review's provenance. A review solicited with a discount, written by an employee, or purchased from a third party violates the FTC Fake Review Rule (16 CFR Part 465) regardless of whether it's wrapped in valid JSON-LD — and platforms increasingly cross-reference marked-up ratings against their own review corpora to catch mismatches.
• Self-serving aggregateRating on Organization or LocalBusiness. Covered above — it will not earn a rich result and can trigger a manual action if it looks manipulative rather than accidental.
• Missing required fields. A Review without an author, a reviewRating without a bestRating, or an AggregateRating without a ratingCount will simply fail rich-result eligibility. Always validate before shipping — see the how-to below.

The throughline: structured data is a claim about what's true on the page, made in a format machines trust more than prose precisely because it's supposed to be unambiguous and verifiable. Abuse that trust and you lose the channel — for search rich results and for AI citation alike, since both increasingly treat pattern-matched, non-corroborated markup as a spam signal to discount rather than surface.

When an AI answer engine assembles a response to "is [business] good for families?" or "what's the best-rated dentist near me," it is doing retrieval under time pressure — pulling from a mix of its own index, live web results, and sometimes a direct crawl. Structured data shortens that path in three concrete ways: it disambiguates the entity being discussed (this LocalBusiness node, not a same-named business three states away, via @id and sameAs), it exposes numeric facts without requiring numeric reasoning over prose (a ratingValue versus inferring sentiment from adjectives), and it labels question-answer pairs as exactly that, which is a near-perfect match for how answer engines like to extract passage-level answers.

The practical implication for a review-driven business is that the same JSON-LD you'd add for a classic rich result is not a separate GEO investment — it's the same investment paying twice. Get the entity, the ratings, and the FAQ pairs right once, keep them accurate and current, and both channels benefit from the same underlying discipline: real reviews, complete required fields, and markup that matches what's actually on the page.