Review schema for affiliate sites: the complete 2026 implementation guide
Review schema declares product evaluations to search engines and AI systems with structured author, product, rating, and verdict fields. For affiliate sites, proper Review schema is increasingly necessary — anonymous or template-attributed reviews get filtered out of AI engine citation pools, while reviews with full Person reviewer, real Product entity, and substantive review body get cited reliably. Here's the implementation guide: schema structure, the reviewer credibility requirements, common mistakes, and validation workflow.
Review schema declares product evaluations to search engines and AI systems in structured format that includes who reviewed the product, what product was reviewed, the rating given, and the substantive review content. For affiliate sites in 2026, proper Review schema implementation is increasingly necessary rather than optional — reviews with anonymous attribution or generic "Editorial Team" credits get filtered out of AI engine citation pools that increasingly handle comparison and "best of" queries. Reviews with full Person reviewer linked to a substantive bio page, proper Product or SoftwareApplication entity for what's being reviewed, real numeric rating, and detailed review body get cited reliably. Implementation is straightforward; the discipline is in the supporting infrastructure (named reviewers with credentials, accurate product entities, honest ratings).
For affiliate sites that lost traffic in recent Google quality updates, Review schema implementation is often part of the recovery work covered in our affiliate site recovery checklist and AEO for affiliate sites. The schema layer is necessary but not sufficient — it amplifies content quality but doesn't compensate for thin or inauthentic reviews.
This guide explains the Review schema structure, the implementation choices that affect citation eligibility, the reviewer credibility requirements that affiliate sites particularly need to address, common mistakes that cause schema to be silently ignored, and the validation workflow that confirms everything works.
What Review schema is and what it declares
Review schema is part of Schema.org vocabulary, designed to mark up structured product or service evaluations. The schema lives in a <script type="application/ld+json"> block in the page head, similar to other schema types.
A Review schema declares four core elements:
author — who reviewed the product. Should be Person sub-schema with linked bio page and verifiable credentials.
itemReviewed — what was reviewed. Product schema for physical products, SoftwareApplication for software, Service for services, etc.
reviewRating — the rating given. Numeric value with stated scale (e.g., 4.5 out of 5).
reviewBody — the substantive review content. Either the full review text or a substantive summary.
These four elements form the verifiable signal chain that Google and AI engines use to assess review legitimacy. Reviews missing any of the four (or with placeholder values) get filtered as low-quality or potentially manipulated content.
The complete Review schema structure
A production-quality Review schema for a software product review:
{
"@context": "https://schema.org",
"@type": "Review",
"itemReviewed": {
"@type": "SoftwareApplication",
"name": "Linear",
"applicationCategory": "Project Management Software",
"operatingSystem": "Web, macOS, Windows, iOS, Android",
"offers": {
"@type": "Offer",
"price": "10.00",
"priceCurrency": "USD",
"priceValidUntil": "2026-12-31"
}
},
"author": {
"@type": "Person",
"name": "Ed Grows",
"url": "https://yourdomain.com/about",
"image": "https://yourdomain.com/images/reviewer.jpg",
"jobTitle": "Founder, citelity",
"sameAs": [
"https://x.com/edgrows",
"https://linkedin.com/in/edgrows"
]
},
"reviewRating": {
"@type": "Rating",
"ratingValue": "4.5",
"bestRating": "5",
"worstRating": "1"
},
"datePublished": "2026-05-11",
"publisher": {
"@type": "Organization",
"name": "citelity",
"url": "https://citelity.com"
},
"reviewBody": "Linear is the best project management tool for small distributed teams that prioritize speed and keyboard-first interaction. After using it for 6 months across two teams, the strengths are clear: dramatically faster than alternatives, excellent keyboard shortcuts, clean issue tracking. The limitations: less flexibility than Notion for complex custom workflows, fewer reporting features than Asana for larger teams. For teams of 5-20 building software, Linear is the right choice. For teams over 50 with complex permissions needs, Asana or alternatives remain stronger options."
}
Each field has specific requirements that affect citation eligibility.
itemReviewed: getting the product entity right
The itemReviewed field declares what's being reviewed. The schema type depends on what you're reviewing:
Product — physical products (electronics, appliances, books, etc.) SoftwareApplication — software, apps, web tools MobileApplication — specifically mobile apps Service — professional services Book — books specifically (has more specific fields than Product) Movie / TVSeries / VideoGame — media content
For affiliate sites covering software/SaaS, SoftwareApplication is typically the right type. For physical goods, Product.
Required fields for the reviewed entity:
{
"@type": "SoftwareApplication",
"name": "Product Name",
"applicationCategory": "Category description",
"offers": {
"@type": "Offer",
"price": "10.00",
"priceCurrency": "USD"
}
}
Important: the entity must accurately describe a real product. Reviews of products that don't exist, or with materially incorrect details (wrong category, fake pricing), get flagged. The offers field with pricing should match current pricing — Google and AI engines cross-check pricing claims against product pages.
For products with multiple variants or pricing tiers, link to the most relevant variant or use the lowest entry price with a note in the review body about pricing complexity.
reviewRating: declaring the rating correctly
The reviewRating field declares the rating with explicit scale:
{
"@type": "Rating",
"ratingValue": "4.5",
"bestRating": "5",
"worstRating": "1"
}
ratingValue is the rating given. bestRating and worstRating declare the scale (default is 1-5 if omitted, but explicit declaration is better practice).
Critical: the rating must match what's visible on the page. If JSON-LD says 4.5 stars and visible content shows 5 stars (or no rating at all), the mismatch gets flagged as schema-content discrepancy. AI engines filter pages with this mismatch.
The rating should also be honest. Reviews with consistently high ratings (every product 4.5-5.0 stars) signal manipulation. Affiliate sites where everything is "highly recommended" trigger quality flags that affect citation eligibility across all reviews on the site.
author: the reviewer credibility requirements
This is where affiliate sites most frequently fail. The author Person sub-schema needs:
{
"@type": "Person",
"name": "Reviewer Name",
"url": "https://yourdomain.com/reviewers/reviewer-name",
"image": "https://yourdomain.com/images/reviewer.jpg",
"jobTitle": "Relevant role",
"description": "Brief bio describing relevant expertise.",
"sameAs": [
"https://linkedin.com/in/reviewer",
"https://x.com/reviewer"
]
}
For affiliate review sites specifically, the reviewer needs:
Real named individual. "Editorial Team" or "Staff Writer" attribution provides no credibility signal. Reviews with these attributions get filtered increasingly aggressively.
Topic-specific expertise. The reviewer should plausibly have standing to evaluate the product category. A sleep specialist reviewing mattresses has credibility; a generic reviewer reviewing mattresses has less. JobTitle in schema should reflect this expertise.
Substantive bio page. The url field points to a bio page that needs to exist and contain real content demonstrating expertise. Empty placeholder bio pages break the verification chain.
Verifiable external profiles. sameAs array should link to real profiles (LinkedIn, X, professional industry profiles). These get checked.
For broader treatment of the bio infrastructure required, see our Article schema E-E-A-T guide.
reviewBody: what makes review content cite-worthy
The reviewBody field contains the substantive review content. Length matters: too short (under 200 characters) provides minimal extractable content; too long (over 2,000 characters) may get truncated.
A strong reviewBody for AI citation:
- Opens with the direct verdict (best for X, recommended for Y, etc.)
- Includes specific use cases the reviewer evaluated
- Names both strengths and limitations honestly
- References specific testing or hands-on experience
- Concludes with clear recommendation context
The visible review content on the page should be longer and more detailed than reviewBody. ReviewBody is the structured summary; the full article expands with sections, comparisons, screenshots, and details.
A weak reviewBody pattern: pure marketing copy lifted from the product page. AI engines detect this and filter the review out of citation pools.
The 6 rules for Review schema that gets cited
The implementation choices that distinguish strong from weak:
Rule 1: Reviewer must be Person sub-schema, not a string
Same rule as Article schema. "author": "John Smith" provides minimal verification signal. Full Person sub-schema with bio page and external profiles is the strong version.
Rule 2: The reviewer must plausibly have expertise in the product category
Generic reviewers reviewing across many unrelated categories get filtered. Topic specialists with consistent coverage in a niche get cited.
Rule 3: Review body must contain actual review content, not marketing copy
The reviewBody and visible content must reflect real evaluation. Restated marketing material gets filtered.
Rule 4: Rating must match visible content
JSON-LD rating value and visible page rating must match exactly. Mismatch flagged.
Rule 5: Product entity must accurately describe the reviewed item
Wrong category, fake pricing, incorrect feature descriptions all flag the schema. The reviewed item must be a real product with accurate metadata.
Rule 6: Rating distribution across reviews must be plausible
Sites where every product gets 4.5+ stars trigger manipulation flags. Including products with mixed ratings (some 3-star reviews) or negative reviews (1-2 stars where deserved) signals authentic evaluation.
Common mistakes in Review schema implementation
-
Anonymous or generic author attribution. Filters reviews from citation eligibility almost universally.
-
Reviews of products the reviewer never used. Marketing copy or spec sheet restatement disguised as review. Detectable through content analysis.
-
Rating inflation across all reviews. Sites with consistent 4.5-5.0 ratings on every product flag as manipulated.
-
Schema rating doesn't match visible rating. Filtered as schema-content mismatch.
-
Product entity with wrong details. Wrong category, outdated pricing, incorrect features. Cross-checked against product pages.
-
Missing or generic Organization publisher schema. Weakens site-level trust signals affecting all review pages.
-
Hidden reviews. Review schema declaring reviews not visible on the page. Violates guidelines.
-
Multiple Review entities for same product on same URL. Schema confusion. One Review per URL maximum.
-
Stale dates with current content. datePublished from 2024 on what should be a current review. Signals neglect.
-
No reviewBody content. Schema technically valid but provides nothing extractable. Filtered as low-value.
Combining Review schema with other schema types
Most product review pages benefit from multiple schema types working together:
Review + Article (or BlogPosting) — for review articles. Article schema covers article-level metadata; Review schema covers the review structure. Both can coexist on one URL.
Review + Product — Review references Product as itemReviewed. Product schema can also exist independently on dedicated product pages, but doesn't need to repeat when referenced from Review.
Review + FAQPage — review pages often include FAQ sections covering common buyer questions. FAQPage schema for the FAQ; Review schema for the verdict.
AggregateRating — when a page summarizes multiple reviews (e.g., a roundup of "top 10 X"), AggregateRating schema applies. Different from individual Review — aggregates ratings across multiple reviewers/sources.
One Review per URL (or one AggregateRating for roundup pages). Don't declare multiple Reviews on the same URL.
Special case: roundup and "best of" pages
For affiliate "best 10 X for Y" pages, the schema approach differs from single-product reviews:
Option A: AggregateRating + individual Review entities
The roundup page declares an AggregateRating reflecting the average across products covered, with individual Review entities for each product:
{
"@context": "https://schema.org",
"@type": "ItemList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"item": {
"@type": "Review",
"itemReviewed": {
"@type": "SoftwareApplication",
"name": "Product A"
},
"reviewRating": {
"@type": "Rating",
"ratingValue": "4.7",
"bestRating": "5"
},
"author": {
"@type": "Person",
"name": "Reviewer Name"
}
}
}
]
}
Option B: Article schema only, with light Product mentions in body
For lighter roundups where the article isn't really a series of structured reviews, use Article schema only and let the product mentions flow naturally in body content without per-product Review schema.
The choice depends on how rigorous your roundup actually is. Genuine multi-product evaluations with real testing of each item benefit from Option A. Listicle-style "10 things we think are good" content fits Option B better.
Validation workflow
Three steps, same as for other schema types:
1. Google Rich Results Test
search.google.com/test/rich-results — paste URL or JSON-LD. Required: zero errors. Review schema typically generates warnings about "valid for some Search features" which can be ignored if rich results don't apply.
2. Schema.org Validator
validator.schema.org — catches spec-level violations. Green checkmarks required.
3. Manual cross-check
Verify the chain manually:
- Click reviewer bio URL — does it load substantive content?
- Verify external profiles in
sameAs— do they exist and match? - Confirm rating in schema matches rating shown on page
- Confirm product details match actual product
- Read the reviewBody — does it sound like actual review or marketing copy?
If the chain breaks anywhere, the schema validation passing doesn't mean the schema works for citation purposes.
What Review schema doesn't fix
Honest framing about limits:
It doesn't make weak reviews citation-eligible. Schema amplifies what's there; if the review is generic spec-sheet restatement, schema doesn't make it valuable.
It doesn't bypass affiliate disclosure requirements. FTC requires clear affiliate disclosure for commerce content. Schema implementation doesn't change disclosure obligations.
It doesn't compensate for fake reviewer identity. Schema declaring expertise that isn't visible in body content (or that the bio page can't substantiate) triggers signal mismatch.
It doesn't restore traffic lost to AI Overviews. Review schema improves citation eligibility within AI Overviews; it doesn't prevent zero-click absorption of comparison queries by AIO.
FAQ
Do I need Review schema if my page has AggregateRating?
Can I use Review schema if I haven't physically tested the product?
What rating scale should I use for Review schema?
Should I include negative reviews on my affiliate site for credibility signals?
Does Review schema still drive rich results in Google search?
Closing
Review schema for affiliate sites in 2026 is a multiplier on review quality rather than a substitute for it. Sites with substantive named-reviewer evaluations of actually-tested products benefit substantially from proper Review schema implementation. Sites with templated content under anonymous attribution don't get rescued by schema alone — the underlying review patterns get filtered regardless of structural markup.
The work is bounded: full Review schema setup is straightforward once author infrastructure exists. The author infrastructure (real named reviewers with bio pages, professional profiles, demonstrated expertise) is the larger investment and the prerequisite for schema benefits to materialize.
If you're starting today: audit your top 10 review pages for current schema implementation. Pages with bare-string authors or "Editorial Team" attribution should be either updated to real named reviewers with proper Person sub-schema, or — if updating authorship isn't feasible — assessed honestly for whether they should remain on the site at all. The quality bar for affiliate review content has risen significantly; sites continuing with pre-2024 review production patterns face increasing filtering pressure regardless of schema improvements alone.