Free Fact Check Schema Generator

Fill in the facts visible on your page, copy the Fact Check JSON-LD, and validate it before you publish. The guide, examples, and FAQs are below the tool. Generate this schema with AI

Type to filter 121 supported schema types.

Schema workflow

Use only facts a visitor can verify on the page, then validate the JSON-LD before publishing.

Required

  • Visible Fact Check content
  • Canonical page URL
  • Clear page owner/publisher
  • Fields that match the visible page

Recommended

  • A representative image when the schema supports it
  • SameAs or related links when visible
  • Validation before publishing

Avoid

  • Adding properties that are not visible
  • Copying example URLs into production
  • Skipping Google and Schema.org validation
Next step

Validate, repair, and publish clean structured data.

Check the generated JSON-LD against the visible page, then run both SwiftSchema and external validators before publishing.

Fact Check Schema Generator — Publish Clear Claim Reviews

Generate valid ClaimReview JSON‑LD with the claim, verdict text, author, and publish date so search engines can understand your fact checks.

Try the Fact Check Generator

Why many fact checks underperform

  • Claims are vague or not explicitly captured in `claimReviewed`.
  • Verdict text (`reviewRating.alternateName`) is missing or inconsistent.
  • Authors and dates aren’t represented, reducing credibility.
  • Manual JSON‑LD drifts out of sync with the review article.

How SwiftSchema helps

The generator guides the essentials: a clear `claimReviewed` sentence, a concise verdict in `reviewRating.alternateName` (e.g., True, False, Mixed), and accurate `author` and `datePublished` fields.

It outputs copy‑ready ClaimReview JSON‑LD that pairs well with Article/NewsArticle for the supporting write‑up.

How it works

  1. 01

    Choose FactCheck (ClaimReview) in the generator below.

  2. 02

    Write a clear claim sentence for `claimReviewed` and select a verdict for `reviewRating.alternateName`.

  3. 03

    Add `author` (organization or person), `datePublished`, and the canonical page `url`.

  4. 04

    Copy JSON or Script, paste on your fact check page, and validate in the Schema Markup Validator.

Ready to build the markup?

Paste once per fact check. Validate. Ship.

Generate ClaimReview JSON‑LD

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 in the Schema Markup Validator; fix warnings (missing claimReviewed, author, or reviewRating).
  6. Submit to Fact Check Explorer: Google phased ClaimReview out of Search results, but Google's Fact Check Explorer still uses it.
  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 in the Schema Markup Validator 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.

Required properties

  • @type=ClaimReview
  • claimReviewed
  • reviewRating.alternateName
  • author.name
  • datePublished

Recommended properties

  • url
  • itemReviewed.name
  • itemReviewed.url
  • reviewRating.ratingValue
  • reviewRating.bestRating
  • reviewRating.worstRating
  • image
  • headline
  • dateModified
  • inLanguage
Minimal ClaimReview JSON-LD
Validate
{
  "@context": "https://schema.org",
  "@type": "ClaimReview",
  "headline": "Fact check: Product schema always boosts rankings",
  "datePublished": "2025-06-10",
  "author": {
    "@type": "Organization",
    "name": "SwiftSchema Fact Lab"
  },
  "claimReviewed": "Adding Product structured data guarantees higher rankings.",
  "reviewRating": {
    "@type": "Rating",
    "alternateName": "False"
  },
  "url": "https://example.com/fact-checks/product-schema-rankings"
}
ClaimReview with numeric scale and itemReviewed source
Validate
{
  "@context": "https://schema.org",
  "@type": "ClaimReview",
  "headline": "Fact check: Product schema always boosts rankings",
  "datePublished": "2025-06-10",
  "dateModified": "2025-06-15",
  "author": {
    "@type": "Organization",
    "name": "SwiftSchema Fact Lab"
  },
  "claimReviewed": "Adding Product structured data guarantees higher rankings.",
  "reviewRating": {
    "@type": "Rating",
    "alternateName": "False",
    "ratingValue": "1",
    "bestRating": "5",
    "worstRating": "1"
  },
  "itemReviewed": {
    "@type": "CreativeWork",
    "name": "Blog post claiming product schema guarantees rankings",
    "url": "https://another-site.example/blog/product-schema-boosts-rankings"
  },
  "url": "https://example.com/fact-checks/product-schema-rankings"
}

FAQs

What schema type is used for fact checks?Show

Use `ClaimReview` to publish fact checks. Include the claim text (`claimReviewed`) and a `reviewRating` with a textual verdict in `alternateName` (e.g., True, False, Mixed).

Who should be the author?Show

Use the fact‑checking organization or person that published the review as `author`.

Do I need a numeric rating?Show

Not required. Many fact checks use a named verdict via `reviewRating.alternateName`. If you use numeric scales, include best/worst rating.

Related types

Browse all schema types

References