Why many fact checks underperform

How SwiftSchema helps

How it works

What is ClaimReview structured data?

Fact checks are published using ClaimReview, which includes the reviewed claim, a verdict text, and author/publish details. This helps search engines understand your assessments.

Essential properties

1. claimReviewed
   — concise sentence stating the claim being evaluated.
2. reviewRating.alternateName
   — textual verdict (“True,” “False,” “Needs Context”).
3. author
   — Person or Organization publishing the fact check.
4. datePublished
   /
   dateModified
   — ISO dates.
5. url
   — canonical fact-check page URL.
6. itemReviewed
   — optional; use Claim or CreativeWork referencing the original source (article, video, post).
7. image
   /
   headline
   — optional but helpful for display.
8. reviewRating.ratingValue
   — include if you use numeric scales; accompany with best/worst rating.
9. inLanguage
   — set locale when publishing in multiple languages.

Content prep checklist

• Extract a clear claim statement in one sentence. Avoid summarizing multiple claims in one ClaimReview.
• Decide on the verdict taxonomy (True, False, Partially True, etc.) and keep it consistent across the site.
• Provide context explaining why the claim is rated as such; include sources and citations.
• Ensure the fact-check article includes the same claim and verdict text users see in search.
• Link to the original source of the claim (article, social post, video) and cite supporting evidence.
• If you use a rating scale (1–5 or meters), document the scale in the article so readers understand the verdict mapping.

Implementation workflow

1. Write the fact-check article and highlight the claim and verdict clearly.
2. Generate ClaimReview JSON‑LD with claimReviewed, verdict, author, datePublished, and url.
3. Reference the original claim source via
   itemReviewed
   or within the article content.
4. Embed the schema once per fact-check page.
5. Validate via Rich Results Test; fix warnings (missing claimReviewed, author, or reviewRating).
6. Monitor Search Console for Fact Check enhancements and adjust if issues arise.
7. Localize: add
   inLanguage
   and localized URLs/headlines for translated pages; align with hreflang/canonicals.
8. Update
   dateModified
   and schema when verdicts are revised; note the change in the article.

Handling multiple claims per article

• Use one ClaimReview per claim. If a fact-check article covers multiple statements, embed multiple ClaimReview objects, each with its own claimReviewed and verdict.
• Structure the page with clear headings for each claim to keep the content aligned with schema.
• If you summarize many claims in a table, still provide separate ClaimReview objects; avoid compressing multiple claims into one JSON-LD block.

Troubleshooting checklist

• Missing verdict text: always include
  reviewRating.alternateName
  .
• Wrong author: use the actual publisher or journalist; ensure it matches the visible byline.
• Ambiguous claim: rewrite
  claimReviewed
  to be specific (“The city built 10 new parks in 2024”).
• No canonical link: include
  url
  and ensure it matches the page the user sees.
• Outdated date: update
  dateModified
  when you revise a fact check and note the change in the article.
• Hidden or paywalled content: ensure the fact check content is accessible to crawlers; avoid hiding the claim or verdict.
• Scale confusion: if using numeric ratings or meters, define
  bestRating
  /
  worstRating
  and explain the scale on-page.
• Weak sourcing: add citations and link to primary sources; avoid self-referential claims without evidence.
• Multiple claims per block: split each claim into its own ClaimReview object.

Common Errors & Fixes

• Missing verdict text: include
  reviewRating.alternateName
  even if you use numeric ratings.
• Wrong author: use the organization/person actually publishing the fact check.
• Ambiguous claims: write a clear, single claim sentence in
  claimReviewed
  .

On-page parity checklist

• The claim text on-page matches
  claimReviewed
  exactly.
• The verdict shown on-page matches
  reviewRating.alternateName
  (and
  ratingValue
  /scale if used).
• Author/byline and publish/update dates on-page match
  author
  ,
  datePublished
  ,
  dateModified
  .
• The canonical page URL matches
  url
  ; headlines/images in schema match on-page assets.
• Sources cited on-page align with
  itemReviewed
  /links referenced in schema.
• Only include schema when ratings/verdicts are visible; avoid hidden fact checks.
• Multi-language pages set
  inLanguage
  and hreflang; claim/verdict are translated consistently.

Validation and maintenance

• Validate via Rich Results Test after publishing or editing fact checks.
• Keep
  dateModified
  current when updating verdicts or adding evidence; annotate the change on-page.
• Review
  sameAs
  /source links periodically to ensure they resolve and remain accurate.
• Maintain a verdict taxonomy list (True/False/Misleading/etc.) and use it consistently across ClaimReview entries.
• Maintain a changelog of fact-check updates (verdict changes, new evidence) and sync schema with each update.