Review schema for web extraction

The Review schema turns a single product or business review page into typed JSON that matches the structure your code already expects. Instead of writing brittle CSS selectors that break the next time a marketplace ships a layout change, you describe the fields you want (author, rating, reviewBody, datePublished, verifiedPurchase) and Extracto renders the page in a real headless browser, reads the visible content, and returns each field with the type you declared. A rating comes back as a number you can average, a date comes back as an ISO string you can sort, and a boolean stays a boolean. This shape maps cleanly onto schema.org's Review type (author, reviewRating, reviewBody, itemReviewed, datePublished), so the output drops straight into review aggregation, sentiment pipelines, competitor monitoring, or seller-feedback dashboards. Because reviews carry a person's name and opinion, treat the author field as personal data: store only what you need, honor the source site's Terms of Service and robots.txt, and keep your request volume modest. The key reliability guarantee is that any field Extracto cannot find on the page is returned as null rather than a plausible-looking guess, so an unverified review never silently becomes verifiedPurchase: true and a missing helpful count never becomes a fabricated zero. Every request runs through a managed anti-bot bypass layer, so review pages behind Cloudflare, DataDome or PerimeterX render without proxy setup on your side, and one call extracts one review URL (Extracto reads a page, it is not a crawler that walks a whole review list on its own).

Fields in a Review schema

The fields teams most often extract for a review, what type each one is, and whether it is usually present.

Field	Type	Required	Notes
author	string	yes	The display name or handle of the reviewer, as shown on the page. Returned as a clean string so you can group reviews per author or de-duplicate. Treat this as personal data: it identifies a real person, so store only what your use case needs and respect the source's Terms of Service.
rating	number	yes	The star or score the reviewer gave, returned as a real number (4, not the string '4 out of 5 stars'). Typing it as a number means you can average, filter and sort ratings without parsing text, and a page with no visible score yields null instead of a fabricated value.
reviewBody	string	yes	The full written text of the review. Returned as a single string with the visible prose, so it feeds directly into sentiment analysis, keyword extraction or summarization. If a review is rating-only with no text, this comes back null rather than an invented sentence.
datePublished	string	optional	The date the review was posted, normalized toward an ISO 8601 string so you can sort chronologically and detect recent feedback. Declaring it as a typed date field beats scraping a relative label like 'Reviewed 3 days ago' with a selector that shifts position.
itemReviewed	string	optional	The name of the product, business or service the review is about (schema.org itemReviewed / productName). Useful when one page mixes reviews across variants, letting you attribute each review to the right item without guessing from context.
title	string	optional	The reviewer's headline or summary line, often a short sentiment cue like 'Stopped working after a month'. Kept separate from reviewBody so you can use it as a label or display snippet; null when the page shows no distinct headline.
verifiedPurchase	boolean	optional	Whether the platform marks this as a confirmed purchase. Returned as a true boolean, so you can trust-weight reviews in code. Crucially, when the page shows no verification badge this is null, never a guessed false, so you never misclassify an unlabeled review.
helpfulCount	number	optional	How many readers marked the review helpful, returned as an integer for ranking the most useful feedback. If the page omits this counter the field is null rather than a fabricated 0, keeping your 'no data' and 'zero votes' cases distinct.

The schema

Copy this and send it with any URL.

{
  "author": "string",
  "rating": "number",
  "reviewBody": "string",
  "datePublished": "string",
  "itemReviewed": "string",
  "title": "string",
  "verifiedPurchase": "boolean",
  "helpfulCount": "number"
}

Example output

Validated JSON back, matching the schema.

{
  "author": "J. Okonkwo",
  "rating": 4,
  "reviewBody": "Battery easily lasts two days and the screen is bright outdoors. Docked a star because the included charger runs hot, but overall I would buy it again.",
  "datePublished": "2026-03-18",
  "itemReviewed": "Aurora 7 Wireless Earbuds (Graphite)",
  "title": "Great battery, mediocre charger",
  "verifiedPurchase": true,
  "helpfulCount": 27
}

Try this review schema against a real page in the live demo, or read the docs to use it via the API.

Review schema: FAQ

Can Extracto read review pages that sit behind Cloudflare or DataDome?

Yes. Every request runs through a managed anti-bot bypass layer that handles protected sites such as Cloudflare, DataDome and PerimeterX, with proxies managed for you and no setup on your end. The page renders in a real headless browser, so JavaScript-loaded review widgets are read from the fully rendered DOM. The one thing this does not cover is login-gated content that needs your session cookies, such as private reviews only visible to a signed-in account; that is available on the Enterprise plan.

Why use a schema instead of CSS selectors for reviews?

Review markup changes constantly across marketplaces and themes, so selectors like div.review > span.stars break without warning. With Extracto you describe the fields you want by name and type, and the engine maps the rendered page onto that shape. You get the same typed JSON whether the site restructures its HTML or not, which means far less maintenance than a selector-based scraper that you have to repair every time a layout ships.

What happens when a review is missing a field like verifiedPurchase or helpfulCount?

Extracto returns that field as null rather than guessing a value. If a review has no verification badge, verifiedPurchase comes back null instead of a fabricated false, and a missing helpful counter stays null instead of becoming 0. This keeps your data honest: you can tell the difference between 'the page did not show this' and a real false or a real zero, which matters when you trust-weight or rank reviews downstream.

Is it okay to extract a reviewer's name?

The author field is personal data because it identifies a real person and their stated opinion, so handle it accordingly. Store only what your use case genuinely needs, avoid building profiles you cannot justify, and follow the source site's Terms of Service and robots.txt along with any applicable privacy law. Keep your request volume modest and prefer aggregate analysis over retaining identifiable individual records longer than necessary.

Does one call pull every review on a product page?

Extracto reads one URL per call and returns the review content present on that page, so it is best pointed at a single review or a review page rather than asked to crawl an entire catalog. It is not a crawler that walks pagination on its own. If you need many reviews, enumerate the review-page URLs yourself and call the API once per URL, which keeps your volume deliberate and easy to rate-limit responsibly.