HOMESKILLSBLOGGITHUB
// FACT-CHECKING

How to Fact-Check AI-Written Blog Posts: A Claim-by-Claim Workflow

A practical workflow for checking the numbers, quotes, policies, and product claims in AI-written drafts before publication.

DANIEL AGRICI////5 MIN READAI CONTENTFACT-CHECKINGSOURCE VERIFICATION
How to Fact-Check AI-Written Blog Posts: A Claim-by-Claim Workflow above evidence packets and magnifying glasses on an archive table

NARRATED SUMMARY

This audio is a summary. The full article below is authoritative.

Read the exact transcript

Fact-checking an AI-written post starts before the prose polish. First, copy every checkable assertion into a claim register. That includes numbers, dates, quotations, policy summaries, named capabilities, and comparisons. Keep the original wording, because a smoother paraphrase can quietly hide the thing you meant to verify. For each claim, find the strongest available source and compare the details that usually cause trouble: scope, date, conditions, definitions, and units. Then assign a clear verdict. A claim may be supported, partially supported, inferred, contradicted, unverified, or inaccessible. Partial support matters when a source backs only part of a broad sentence. Rewrite only after the evidence is visible. Narrow the claim, add the missing condition, remove unsupported certainty, or delete it. Then check the rewritten sentence again. Editing can create a fresh factual claim even when the original problem looked solved. AI detection answers a different question. It cannot prove a policy statement or statistic is true. The useful output is a traceable record: original claim, evidence, verdict, revised wording, and reviewer.

AI detection and factual verification answer different questions. Run them as two separate checks. A detector may classify writing patterns. It cannot prove that a number, quote, policy statement, or named capability is true. Factual verification starts with the exact claim and the evidence needed to support it.

Google says appropriate use of AI is not itself against its guidelines. It also says using automation primarily to manipulate rankings violates spam policies (Google Search Central, retrieved 2026-09-07). That is a policy point to verify, not a shortcut for deciding whether every sentence in an AI-assisted draft is accurate.

Key takeaways

  • Extract claims before you edit style or run an AI detector.
  • Preserve the original sentence, the exact evidence, and a verdict so a reviewer can retrace the decision.
  • Compare source scope, date, conditions, and units before rewriting a claim.
  • Recheck new claims after a substantive rewrite.

Build a claim register before you edit

Copy every checkable assertion into a register. Include numbers, dates, quotations, policy summaries, named products, and “best” or comparative claims. Keep the exact original wording. Paraphrasing it before checking often hides what the draft actually asserted.

Use six verdicts consistently:

  • Supported: the cited evidence supports the original claim at the stated scope and date.
  • Partially supported: the evidence supports only part of the claim, so the final wording must be narrowed to that supported scope.
  • Inferred: the original claim is a clearly labeled conclusion drawn from facts, rather than a source statement.
  • Contradicted: a credible source conflicts with the original claim.
  • Unverified: no adequate evidence was found for the claim.
  • Inaccessible: the cited evidence could not be read or checked.

Partial support is a cue to narrow the sentence. Contradicted, unverified, and inaccessible claims are not permission to retain confident copy. Remove, qualify, or escalate the claim until it has a defensible basis.

| ID | Exact draft claim | Claim type | Source and retrieval date | Evidence passage or data | Verdict | Final wording |
| --- | --- | --- | --- | --- | --- | --- |
| C-01 | [copy sentence] | policy, statistic, quote, capability | [URL, YYYY-MM-DD] | [exact support] | supported / partially supported / inferred / contradicted / unverified / inaccessible | [approved rewrite or remove] |

Extract claims, then find the strongest evidence

Work sentence by sentence through statements a reader could challenge. A source from the organisation responsible for a product, rule, or dataset is usually a better starting point than a roundup repeating it. Record a retrieval date for changeable guidance. If a source is inaccessible, write inaccessible, say why, and do not silently replace it with a search snippet.

When two credible sources conflict, do not average their wording. Record both, check whether they cover different product versions, countries, time periods, or definitions, then narrow the claim to what each actually supports. Escalate the conflict if the publication decision depends on it.

Compare scope, date, conditions, and units

Many bad rewrites begin with a real source used at the wrong scope. Before accepting a claim, compare:

  1. Scope: Does the source address this product, audience, or policy?
  2. Date: Is the source current enough for the claim being made?
  3. Conditions: Are there exclusions, eligibility rules, or methods that the sentence left out?
  4. Units: Does a percentage, currency, time period, or measurement match?

A price from one plan does not establish every plan's price. A survey result for one country does not describe every market. A result for a one-month period does not establish an annual trend. These are not cosmetic details: they decide whether the original sentence can stay.

Worked example: four original claims

This example is an editorial exercise using public Google guidance, not a review of a live article. The worked claims were checked against the named Google sources on 2026-09-07. The verdict taxonomy is an editorial classification used for this workflow.

IDExact draft claimEvidence checkedVerdict for the original claimFinal wording
C-01“Google penalizes all AI-written content.”Google’s AI-content guidance says appropriate AI use is not against its guidelines, while automation used primarily to manipulate rankings violates spam policies.Contradicted“AI use alone does not determine compliance. Google says automation used primarily to manipulate rankings violates its spam policies.”
C-02“This post is comprehensive because it has 2,000 words.”Google’s people-first guidance asks whether content is substantial and complete, but does not set a preferred word count.Contradicted“Assess whether the post gives the reader a complete, useful answer. Do not use word count as proof of comprehensiveness.”
C-03“Adding an author-method note can help readers understand how automation contributed.”Google’s people-first guidance discusses clear sourcing and author background; its AI-content guidance says disclosure can give readers context.SupportedKeep the claim with the cited qualification: use process context when it helps readers understand the work.
C-04“Google allows AI-written content.”Google’s AI-content guidance says appropriate AI use is not against its guidelines, while automation used primarily to manipulate rankings violates spam policies.Partially supported“Google says appropriate AI use is not itself against its guidelines. Automation used primarily to manipulate rankings violates its spam policies.”

The original numeric word-count claim is intentionally shown as an unsupported rule of thumb. The review does not invent a statistic to rescue it.

Rewrite, then review the rewrite

Replace only the sentence you can support. Do not turn a source about a narrow case into a broad promise. Mark a conclusion as an inference when it goes beyond the source. Once the edit is made, run the register again: a new example, headline, meta description, or transition may create a fresh claim.

Google’s people-first guidance asks whether content has original information, clear sourcing, and a substantial, complete description of its topic (Google Search Central, retrieved 2026-09-07). That supports a reviewable editorial process. It does not guarantee rankings or prove that a single fact-check produces a good page.

A concise prompt for a fact-check tool

Use this as an instruction for a tool or reviewer, then verify the returned evidence yourself:

Extract every checkable claim from this draft. For each claim, preserve the
exact wording, classify it, cite the strongest accessible source with retrieval
date, compare scope/date/conditions/units, assign one of supported, partially supported, inferred,
contradicted, unverified, or inaccessible, and propose a safe final wording.
Do not invent evidence. Flag conflicting or inaccessible sources for review.

For a deeper method, see the claim-by-claim Blog Factcheck skill. For a separate discussion of detection and scoring, see the AI content scoring guide.

PRIMARY SOURCES

  1. Creating helpful, reliable, people-first content, Google Search Central. Accessed . Originality, completeness, sourcing, people-first purpose, the absence of a preferred word count, and process context for automation.
  2. Google Search's guidance about AI-generated content, Google Search Central Blog. Accessed . Appropriate AI use is not itself against guidance, while automation used primarily to manipulate rankings violates spam policies.

QUESTIONS PEOPLE ASK

No. A detector may classify writing patterns, while fact-checking tests whether specific numbers, quotes, policy statements, and named capabilities are supported by evidence.
Use supported, partially supported, inferred, contradicted, unverified, and inaccessible consistently. Narrow partially supported claims, then remove, qualify, or escalate claims that lack a defensible basis.
Record both sources, compare their product versions, countries, time periods, and definitions, then narrow the claim or escalate the conflict when publication depends on it.

Daniel Agrici

Daniel Agrici builds open-source, terminal-first systems for research, content operations, and marketing automation.

More from Daniel

BUILD BETTER CONTENT
FROM THE TERMINAL.

VIEW ON GITHUB