
Element Code: RI-028
What ClaimReview schema actually is
ClaimReview is a subtype of schema.org's Review type, built specifically to structure a fact-check verdict. It wraps three ideas into one object: the claim being evaluated (itemReviewed, a Claim), the verdict (reviewRating, a Rating), and who's vouching for that verdict (author, an Organization or Person). Per the schema.org ClaimReview specification, the point is machine-readable separation between "here's what was claimed" and "here's what we found," so a search engine doesn't have to parse prose to figure out whether a fact-checker said something was true or false.
This isn't general-purpose "debunk a myth" markup. It's a fact-checking industry standard that Google, Bing, and the Fact Check Explorer tool all consume the same way. If your page isn't structured as a discrete review of a discrete claim, use Article markup instead and skip the fact-check machinery entirely.
Why it matters for visibility
When implemented correctly and the publisher is eligible, ClaimReview powers the Fact Check rich result: a small badge or panel showing the claim, the verdict, and the fact-checker's name directly in Google Search and Google News, plus inclusion in the Fact Check Explorer and the Fact Check tab that appears alongside regular results for contested topics. Per Google's Search Central documentation on Fact Check (ClaimReview) markup, this is one of the few rich result types tied directly to an editorial trust signal rather than a visual enhancement. That's also why Google locks it down harder than most schema types: misuse for spam or manipulation has consequences beyond losing a rich result, up to the whole domain becoming ineligible for the feature.
For a legitimate fact-checking org, the upside is real: differentiated SERP presence and syndication into Google's Fact Check Explorer. For everyone else, chasing this schema without the underlying eligibility is wasted engineering time.
Who's actually eligible
Per Google's guidelines, eligibility isn't "add the JSON-LD and you're in." Google requires the site to demonstrate the practices laid out in its News General Guidelines: a visible corrections policy or a clear way for readers to report errors, transparency about ownership and funding, and consistent editorial standards across the site, not just the one fact-check page. Google states plainly that eligibility is determined algorithmically based on whether the site is judged an authoritative source, and that political entities, campaigns, parties, elected officials publishing about themselves, are excluded outright regardless of how well the markup is implemented.
In practice: general blogs, brand sites, and one-off "we checked this viral claim" posts are unlikely to qualify for the rich result even with flawless markup. This schema is for outlets whose core function is fact-checking, or news publishers with a dedicated fact-check vertical following consistent methodology. If that's not your site, you can still add ClaimReview for structured-data hygiene and potential AI/LLM citation value, but don't expect the SERP badge.
Required and recommended properties
Google's documentation splits properties into required (needed for any eligibility at all) and recommended (needed for a richer, more complete result). Getting the required ones wrong is the single biggest reason implementations get rejected in the Rich Results Test.
| Property | Parent | Status | Notes |
|---|---|---|---|
| claimReviewed | ClaimReview | Required | Plain-text summary of the claim, keep under 75 characters per Google's guidance, no verdict language here |
| reviewRating | ClaimReview | Required | Nested Rating object, this is where the verdict lives |
| url | ClaimReview | Required | Canonical URL of the fact-check article itself |
| alternateName | Rating | Required | Human-readable verdict word, e.g. "False," "Mostly True," "Missing Context" |
| author | ClaimReview | Recommended (effectively required for eligibility) | Must be the fact-checking organization, needs a url property Google can crawl to verify identity |
| itemReviewed | ClaimReview | Recommended (effectively required for eligibility) | Nested Claim object describing what's being reviewed and who made it |
| datePublished | ClaimReview | Recommended | When the fact check itself went live |
| ratingValue / bestRating / worstRating | Rating | Recommended | Numeric scale, higher value must mean truer, not the reverse |
| appearance / firstAppearance | Claim | Recommended | URL or CreativeWork showing where the original claim appeared |
Two details trip people up constantly. First, claimReviewed should describe the claim, not the verdict: don't write "False: the moon landing was faked," write "The moon landing was faked" and let reviewRating carry the verdict. Second, the numeric rating scale direction isn't intuitive to everyone building the JSON-LD by hand: per Google's spec, the value closer to bestRating is more true, and the value closer to worstRating is more false. A common 1-to-5 scale runs 1 = False through 5 = True. Flip that and your rich result shows a contradictory verdict even though your on-page text is correct, which is exactly the "structured data doesn't match page content" violation Google calls out as disqualifying.
How the pieces fit together
The flow from a claim in the wild to a rich result on the SERP looks like this: something gets claimed somewhere (a tweet, a speech, a chain email), a fact-checking org reviews it and publishes an article, that article gets marked up with ClaimReview, and if the publisher clears Google's eligibility bar, the verdict can surface as a rich result.
Implementation: a working JSON-LD example
Here's a minimal but complete ClaimReview block covering both required and recommended properties, structured the way Google expects it:
{
"@context": "https://schema.org",
"@type": "ClaimReview",
"url": "https://example-factcheck.org/claim-xyz",
"claimReviewed": "A new law bans home vegetable gardens nationwide",
"itemReviewed": {
"@type": "Claim",
"author": {
"@type": "Organization",
"name": "Example Viral Post Source"
},
"datePublished": "2026-05-14",
"appearance": [
"https://example.com/social-post-123"
]
},
"author": {
"@type": "Organization",
"name": "Example Fact Check Org",
"url": "https://example-factcheck.org"
},
"datePublished": "2026-05-20",
"reviewRating": {
"@type": "Rating",
"ratingValue": "1",
"bestRating": "5",
"worstRating": "1",
"alternateName": "False"
}
}Implementation steps, in order:
- Confirm your site actually meets Google's fact-check publisher eligibility before investing time, an ineligible site with perfect markup still won't get the rich result.
- Draft the claim text for claimReviewed as a neutral, verdict-free summary under roughly 75 characters.
- Fill in itemReviewed.author with who actually made the claim, not your organization.
- Set your rating scale once, document it internally (1-5, 1-10, whatever), and reuse it consistently across every fact-check page on the site.
- Add your organization as author on the ClaimReview object with a working url so Google can verify who you are.
- Place exactly one ClaimReview object per page, if you're reviewing multiple claims, that's multiple pages, not multiple ClaimReview blocks stacked on one URL.
- Make sure the visible page text says the same verdict the schema says. If the article body hedges or later text contradicts the rating, fix the copy or fix the schema so they agree.
- Validate before publishing and periodically after, since template changes can silently break nested properties.
How to detect and validate it
Run the page through Google's Rich Results Test first: it flags missing required properties and tells you directly if the page is eligible for the Fact Check result type. Follow with Schema.org's Structured Data validator for a broader syntax check that isn't Google-result-specific, useful for catching malformed JSON-LD Google's tool might silently ignore. If you're auditing ClaimReview across many URLs at once, Screaming Frog's custom JSON-LD extraction (XPath or regex on the script tag) lets you pull claimReviewed, reviewRating.alternateName, and author.name into a spreadsheet so you can eyeball rating-scale consistency across the whole fact-check archive in one pass. Once live and indexed, Search Console's Enhancements report shows a Fact Check section with valid, invalid, and warning counts over time, your ongoing monitoring layer, not just a one-time check.
Common mistakes
The most frequent failure isn't a missing property, it's using this schema at all when the site isn't an eligible fact-check publisher. Second: putting the verdict inside claimReviewed instead of reviewRating, which muddies the claim summary and can look like editorializing. Third: missing or incomplete itemReviewed.author, Google wants to know who originated the claim, not just who's fact-checking it, and leaving that blank weakens the whole record. Fourth: inconsistent or backwards rating scales, if bestRating means 5 on one page and 5 means false on another page of the same site, that's an internal contradiction, and if the scale direction is reversed relative to Google's spec, the rich result can show the opposite of your actual verdict. Fifth: stacking more than one ClaimReview per page, which per Google's guidance disqualifies the page from the single fact check rich result entirely.
- Confirm publisher eligibility against Google's News General Guidelines before building anything
- Keep claimReviewed neutral and verdict-free
- Use one consistent rating scale across the entire site
- Include a working corrections policy or error-reporting mechanism
- Validate every page with the Rich Results Test before and after template changes
- Add ClaimReview to general blog posts or brand content that isn't a real fact-check
- Bake the verdict into the claimReviewed string
- Leave itemReviewed.author blank
- Reverse the ratingValue scale relative to bestRating/worstRating
- Stack multiple ClaimReview objects on one page
What good looks like
A well-run ClaimReview implementation reads like a court record: neutral claim statement, clear attribution of who said it and where, a documented rating scale, a named and verifiable fact-checking organization, and page copy that says exactly what the schema says. Sites that show up reliably in Google's Fact Check Explorer tend to publish fact checks as a core editorial product with a visible methodology page, not an occasional side feature. If that's not your site, skip ClaimReview and let your content speak plainly instead of dressing it up in schema it doesn't qualify to use.
FAQ
Does adding ClaimReview guarantee the Fact Check rich result?
Can a regular business or blog use ClaimReview to debunk something?
What direction should the rating scale go?
Can I mark up more than one claim on the same page?
How do I check if my ClaimReview markup is actually working?
Not sure if your fact-check pages qualify, or where your ClaimReview markup is breaking?
An advanced SEO audit checks schema validity, publisher eligibility signals, and rich result performance in one pass.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.







