uprank
Sign inGet started

Guide

How to update old blog posts with AI without breaking facts

To update an old blog post with AI without breaking facts, decide what has expired before anything is rewritten: list the post’s checkable claims, re-check each against a current source, and give the AI only the facts you verified and a narrow job. Then compare the new version’s claims with the old list, have a person who knows the topic approve one specific version, and keep the old version so you can compare or go back. uprank automates part of this for the articles it wrote: every revision is a new version whose claims are checked again, time-sensitive claims past their window are flagged when a version is scored again, and a revision must clear all 13 hard gates before it can be approved, pushed to Strapi or recorded as a live publication request. It does not import a published post, and a revision does not gather new sources, so new facts have to come from you or from new research.

Updated

The method, step by step

Works on any old post, whichever tool rewrites it.

  1. Step 1

    Choose what to refresh by what can expire, not by age

    Start with posts whose claims go out of date: dates, prices, versions, statistics, product names, screenshots and words like “latest” and “current”. Age alone is a poor guide. A stable explanation written years ago may need nothing, while a comparison written last quarter may already be wrong.

  2. Step 2

    Save the old version and list its claims

    Keep the live text exactly as it is, then list every checkable claim in it: numbers, dates, names, quotes, comparisons and “best”, “first” or “only” statements. That list is what you will check now and what you will compare the new version against.

  3. Step 3

    Re-check each claim against a current source

    Open a current, preferably primary, source for each claim and mark it still true, changed or unconfirmed. Fix or cut what you cannot confirm. Do not ask the AI whether a claim is still true: a model without current sources answers from its training data, which is the thing that went out of date.

  4. Step 4

    Give the AI the checked facts and a narrow job

    Hand over the verified facts with their sources, the passages to change and what to leave alone, such as the structure, the promise of the title and the sections that are still right. “Update this post” invites a rewrite of everything, and every rewritten sentence is a new chance to introduce an error.

  5. Step 5

    Compare the new version with the old, claim by claim

    List the claims in the new text and set them beside your list from the old one. Every difference should be one you meant. A number that changed with no source, a claim that appeared from nowhere and a sourced claim that quietly vanished are the usual ways a refresh breaks facts.

  6. Step 6

    Have a person review and approve one specific version

    Someone who knows the topic reads the new version, checks that every link still resolves and that each citation says what the text says it does, and approves that exact version. Keep the old version so you can compare it or go back to it.

  7. Step 7

    Record the change and schedule the next check

    Write down what changed and who approved it. Show an updated date only when the content changed in substance, because a new date on an unchanged post says something that is not true. Give each time-sensitive claim a check-by date, so the next refresh starts from a date you set instead of from noticing a problem.

Checking a claim against its source is its own job: how to fact-check AI content. Who approves which version, and what sends an edit back through the checks, is the AI content approval workflow.

What uprank automates at each step

Each step of the method mapped to what the code does, including where it stops.

  • Choose what to refresh by what can expire, not by age. uprank has no import for a post written elsewhere. An article exists in uprank only because a pipeline run created it from a topic or title, so everything on this page applies to the articles uprank wrote. For those, the MCP tool refresh_list (article:read scope) lists your articles in Needs Review, Approved or Published, newest-updated first, and sets a one-line reason on those whose current version has a time-sensitive claim past its freshness window or has no current quality assessment. The reason is empty for the others, so read the reason, not the list. It reads article rows and their status, plus claims and assessments. It does not look at how old a page is or how many people read it, it does not check whether a fact has changed, and it changes nothing.
  • Save the old version and list its claims. Every revision and every saved edit is a new numbered version, and the earlier versions stay in the history, so the text you started from is not overwritten. The version list on the article page shows any two of them side by side. When uprank generates or revises a version, a model extracts its checkable claims from the whole text, each with a type, a risk level and, when the model judges it time-sensitive, a freshness window in days. They are listed on the Claims tab, which shows each claim’s text, type, risk, support and sources but not its freshness window or expiry date; those are stored and used by the stale-claim check and refresh_list only. A claim the model misses is not checked.
  • Re-check each claim against a current source. Each claim in a generated or revised version is checked against the numbered source excerpts in the article’s Evidence Pack and marked directly supported, partly supported, contradicted or unsupported. That pack was gathered when the article was first researched, and a revision does not research again, so a claim can be directly supported by an old source and still be out of date. A time-sensitive claim’s freshness window runs from the day it was checked, so a revision starts it again even though no new source was read. Starting the pipeline from a topic that already has a ready Evidence Pack reuses that pack instead of researching again; a topic without one is researched first, and researching a new topic needs a campaign.
  • Give the AI the checked facts and a narrow job. Apply selected, on the Quality tab, writes a new version from the brief stored on the version being revised, the brand profile and the Evidence Pack sources, with the recommendations you tick as revision notes. article_revise over MCP does the same from free-text instructions and the dimensions to focus on, and falls back to the latest assessment’s recommendations when you give neither. The current text is not sent to the model; only the brief, brand, sources and revision notes are, and the document title stands in as the topic when the brief has no working title. So this is a fresh draft, not an edit: nothing is kept unless the brief leads the model to write it again, hand edits are not carried over, and an instruction to keep a section as it is has nothing to refer to. A version saved in the editor keeps the brief of the version it was edited from, so a revision of a hand-edited version is written from that brief too; an edit saved before the editor kept it has none and is revised without one.
  • Compare the new version with the old, claim by claim. The new version’s claims are extracted and checked on their own, and the version list on the article page puts the two texts side by side. uprank does not compare one version’s claim list with another’s, so it will not tell you that a number changed or that a sourced claim disappeared. That comparison is yours to make.
  • Have a person review and approve one specific version. A revision is scored when it is made, and the article goes to Needs Review, an approved or published one included. The new version becomes the article’s current version straight away, whether or not it passed, and the earlier version stays in the history. Approve is available for a version only once its current assessment has cleared all 13 hard gates, and approving needs the Editor role or higher; the same gate applies before a version is pushed to Strapi or recorded as a live publication request over MCP. A revision sends nothing to your CMS, so the post on your site stays as it is until someone pushes a version. While a revision runs the article is locked: edits and approval are refused, and if the article’s current version changes in the meantime the revision is discarded instead of replacing it. A revision that never finished because the server stopped is treated as over after 30 minutes. uprank does not require a second reviewer.
  • Record the change and schedule the next check. Saving an edit, creating a version (a revision creates one), approving and changing status through the status action are each written to the audit log with the actor, and Apply selected also records the revision request with the dimensions it revised. The revision lock’s own moves between Needs Review and Generating are not separate audit entries. The Strapi push builds its fields from the version’s title, slug, body, excerpt and SEO fields and sends no last-updated date, so whether your page shows one is decided in your CMS or template. uprank does not re-check or revise a post for you: a time-sensitive claim carries a freshness window and refresh_list shows when one has lapsed, but you decide when to run a revision.

The full list of gates is on quality gates, and the product view is an AI writer that doesn’t hallucinate sources.

Ways to change an article in uprank

They differ in whether they research again, whether they check claims and whether your wording survives.

  • Apply selected (Quality tab)

    Writes a new version from the brief stored on the version being revised, the brand profile and the Evidence Pack sources, with the recommendations you tick as revision notes, and scores it. A version saved in the editor keeps the brief of the version it was edited from, so revising a hand-edited version uses that brief; an edit saved before the editor kept it has none.

    Who can use it
    An Editor, while the article is in Needs Review.
    Researches again
    No. It reuses the original sources.
    Claims
    Extracted again from the new text and checked against those sources before scoring.
    Keeps your wording
    No. Hand edits to the current version are not carried over.

  • article_revise (MCP)

    The same revision, from free-text instructions and the dimensions to focus on. With neither, it uses the latest assessment’s recommendations.

    Who can use it
    An agent with the article:write scope, on the article’s current version, in any status except Generating. It refuses while another revision is running.
    Researches again
    No. It reuses the original sources.
    Claims
    Extracted again from the new text and checked against those sources before scoring.
    Keeps your wording
    No. Hand edits to the current version are not carried over.

  • Edit by hand (editor)

    Saves your text as a new version and marks the article’s earlier quality assessments stale. An approved or published article goes back to Needs Review. The new version keeps the brief and the declared information-gain element of the version you edited; that declaration is not checked again against your edited text.

    Who can use it
    An Editor.
    Researches again
    No.
    Claims
    Not extracted or checked. The new version has no claims of its own.
    Keeps your wording
    Yes. It is your text.

  • A new article through the pipeline

    Creates a separate article: researches the topic, writes a brief and a draft, checks the claims, scores it and holds it for review. It is not a revision of the old article. While the old article is still on your site’s list (not archived or failed), a new one that ends up with the same title fails the “Unique title” check until one of the titles changes.

    Who can use it
    An Editor in the app, or an agent with the article:write and research:run scopes over MCP (pipeline_run).
    Researches again
    Yes, unless the topic already has a ready Evidence Pack, which is reused. Researching a new topic needs a campaign.
    Claims
    Extracted and checked against the Evidence Pack the run uses.
    Keeps your wording
    No. It is a new draft.

What the stale-claim check does and does not catch

It counts days since a claim was checked. It does not look at the world.

What it does

  • When a version is generated or revised, a model marks each time-sensitive claim with a freshness window in days. The window is counted from the day uprank checks the claim.
  • When that version is scored again after a window has passed, the claim counts as stale. The “Time-sensitive claims are fresh” check, one of 13 hard gates, fails, and the Freshness score drops. Freshness is 6% of the overall score and has no score gate of its own.
  • The MCP tool refresh_list lists your Needs Review, Approved and Published articles and sets a reason on those whose current version has a claim past its window or no current assessment. The reason is empty for the others.

What it cannot see

  • A fact that was already wrong when it was checked, or that changed inside its window. The check counts days since the check; it does not look at the world.
  • A time-sensitive claim the model gave no window, and any claim the model did not extract. A claim with no window is never stale.
  • How old a source is. The Freshness score and the stale check read each claim’s window, not the dates of the sources behind it.
  • A version that passed earlier. Approving, pushing to Strapi and recording a live publication request read the stored assessment, not the clock, so a lapsed window only matters once the version is scored again.
  • A re-score in the app. A version is scored again over MCP with article_score. The web app has no re-score button: the Quality tab only shows a “Stale — re-score needed” badge after an edit, and there a version is scored again only by revising it, which restarts every window. So a web-only reader should not expect the stale-claim check to fire by itself when a window lapses.
  • A revision’s fresh start. Checking a claim during a revision starts its window again from that day, against the same stored sources, so a revised version can look current without any new source being read.

What uprank will not do

  • Import or fetch a published post. Only articles that a uprank pipeline run created can be revised, and the MCP server has no import tool.
  • Research again when it revises. A revision is given only the original Evidence Pack, not new sources, so a fact those sources do not contain is not researched. If the model writes one anyway, the claim check is meant to mark it unsupported; that check is also made by a model, so a person still reads the claims. Current facts have to come from you or from new research.
  • Tell you whether a fact is still true. The stale-claim check counts days since a claim was checked, and the claim check compares claims with the sources uprank gathered.
  • Keep your wording. A revision is a fresh draft that never sees the current text (at most its title, as the topic), so your edits are not carried over and an instruction to leave a section alone has nothing to act on.
  • Check a hand edit. Claims are extracted when uprank generates or revises a version, not when you save an edit, and article_score scores the claims a version already has without extracting new ones. A version with no claims gets an Evidence score of 40, under the minimum of 85, so its Evidence gate fails.
  • Compare the claims of two versions. The version list on the article page shows two texts side by side; spotting a changed number or a lost citation is up to you.
  • Refresh anything by itself. Once an article is in review, a revision starts only when an Editor uses Apply selected or an agent calls article_revise.
  • Replace a reviewer. The gates catch what they test for, and a person still decides whether the refreshed piece is right to publish.

What Google says about AI-written content is on Does Google penalize AI content?. This page makes no claim about how any search engine will treat an updated post.

Common questions

How do you update old blog posts with AI without breaking facts?
Decide what has expired first, because age alone is a poor guide: dates, prices, versions, statistics and words like “latest” go stale, and a stable explanation may not. List the post’s checkable claims and re-check each one against a current source. Then give the AI those verified facts and a narrow job instead of asking it to “update the post”, compare the new claims with the old list, have a person approve one specific version, and keep the old version. uprank automates parts of this for the articles it wrote, but a revision does not gather new sources.
Can AI refresh outdated content on its own?
It can rewrite the text, but it cannot know what changed unless it is given current sources. A model asked to update a post from memory answers from its training data, which is what went out of date. In uprank a revision is written from the brief stored on the version being revised, the brand profile and the article’s Evidence Pack, so it reuses the original research. A version saved in the editor keeps the brief of the version it was edited from, so revising it starts from that brief; an edit saved before the editor kept it has none. Current facts have to come from you or from new research, and a person decides whether the result is right.
Can uprank refresh a post that is already live on my site?
Only if uprank wrote it. An article exists in uprank because a pipeline run created it, and there is no import for a post written elsewhere. For an article uprank wrote, Apply selected on the Quality tab and article_revise over MCP each create a new version, check its claims again against the stored sources and score it. Nothing is sent to your CMS until someone pushes a version, and the push is blocked until the version clears all 13 hard gates.
How does uprank flag stale claims in an old article?
When a version is generated or revised, a model gives each time-sensitive claim a freshness window in days, counted from the day the claim is checked. If the version is scored again after a window has passed, the claim counts as stale: the “Time-sensitive claims are fresh” check, one of 13 hard gates, fails and the Freshness score drops. The MCP tool refresh_list sets a reason on the articles with a lapsed claim. The check counts days since the check and does not look at whether the fact changed, and it never flags a claim that was given no window.

Keep reading

Create your workspace