How to Correct a Published Post: A Policy for Small Sites

A correction policy answers four questions before the error happens: what counts as an error, which errors need a visible note, what the note says and where it goes, and what the site does so the same mistake is not made twice. Newsrooms settled those questions long ago, and their codes are public. This guide adapts them for a site with one or two people, no standards editor and an archive increasingly drafted with AI assistance, which Google's own guidance says must be checked by hand because the models predict words rather than retrieve facts.

The policy is short because the standard is short. The Society of Professional Journalists' code says to acknowledge mistakes, correct them promptly and prominently, and explain corrections clearly. The UK Editors' Code, which IPSO enforces, requires a significant inaccuracy to be corrected promptly and with due prominence. The BBC's editorial guidelines draw the line a small site needs: in online text, any mistake that alters the editorial meaning should be corrected, with an acknowledgement of what was wrong and a clear indication that the article has been amended. Everything below is an application of those three sentences.

It follows on from our note on Google's October 1 guidance about checking AI-assisted content, covered separately, which is about catching errors before publication. This page is about the ones that get through.

The reason is in Google's own guidance on using generative AI content, which is unusually direct for a Search Central document. It says that generative models "don't retrieve facts, but predict a likely sequence of words based on their training data," that outputs "may contain inaccuracies (also known as hallucinations)," and that "it is critical to manually factcheck and review all AI-generated content for accuracy and trustworthiness before publishing." It extends the same review to metadata: title elements, meta descriptions, structured data and image alt text. A site that drafts with a model has, in effect, hired a writer who is fluent, fast and occasionally wrong in ways that read as confident.

A newsroom absorbs that risk with a desk, a sub-editor and a standards process. A small site has the owner, a deadline and a publish button. The errors that get through are not usually the dramatic kind. They are a statistic attributed to the wrong report, a price that was right last year, a quotation smoothed into words its source never said, a date that is plausible and wrong. Each one is small. Each one, found by a reader, costs more than the post earned, because the reader now has a reason to doubt the rest of the archive and no sign that the site would tell them if something else were wrong.

A correction policy fixes the second half of that. It cannot stop every error, but it tells the reader what the site does when one is found, and a site that visibly corrects itself is, to most readers, more trustworthy than one that appears never to have been wrong. The failure case is the opposite instinct: fixing errors quietly so that no trace remains. That protects the post and exposes the site, because the one reader who noticed the original now knows the site edits history. The rate of model errors on factual tasks is its own subject, covered in our hallucination-rate benchmark study; this page assumes the rate is above zero and plans for it.

Classifying the error is the first step, because the class decides everything after it. Five classes cover what a small site actually publishes. A typo or formatting slip changes no meaning. A factual error states something untrue about the world. A figure error is a factual error where the untrue thing is a number, separated out because numbers get cited. An attribution error puts words, findings or a position on the wrong person or organisation. An outdated statement was true when written and is no longer, which is not an error at all in the press-code sense, but readers experience it as one.

The question that sorts them is the BBC's: did the mistake alter the editorial meaning? Section 3.4.36 of its accuracy guidelines says that in online text content any such mistake should be corrected, and that it is important to acknowledge what was wrong, correct the error and make it clear the article has been amended. A typo does not alter the meaning. A wrong figure usually does. A wrong attribution always does, because it changes who said the thing and therefore how much weight it carries. Outdated content does not need a correction note but does need an update note, which is the date question covered in our guide on when a post earns a new date.

One example per class, all illustrative: "recieve" for "receive" (typo, fix silently); a post saying a regulation took effect in March when it took effect in May (factual, label); a 12% conversion lift that should read 1.2% (figure, label, and check where it came from); a quotation attributed to a company's blog that was in fact a journalist's paraphrase (attribution, label, and re-quote from the primary); a pricing table from 2024 (outdated, update note and new modified date). The failure case is treating the figure error as a typo because the fix is one character. The size of the edit is not the test; the change in meaning is.

A small site is not bound by any press code, and that is the point of borrowing from them: they are the product of decades of arguments about exactly this, and they agree. The Society of Professional Journalists' Code of Ethics, under its "Be Accountable and Transparent" heading, says journalists should "acknowledge mistakes. Correct them promptly and prominently. Explain corrections and clarifications carefully and clearly." The same code's accuracy section asks journalists to "gather, update and correct information throughout the life of a news story" and notes that "speed, technology or medium do not excuse inaccuracy or unfairness."

The Editors' Code of Practice, the code IPSO enforces for its member UK newspapers and magazines, puts the same duty in its first clause. The press "must take care not to publish inaccurate, misleading or distorted information," and "a significant inaccuracy, misleading statement or distortion must be corrected, promptly and with due prominence," and where appropriate an apology published. Two words there carry the policy: significant, which is the threshold for a labelled correction, and prominence, which must be due to the error rather than fixed.

The BBC's Editorial Guidelines add the operational detail. Section 3.2.4 says serious factual errors "should normally be acknowledged and corrected quickly, clearly and appropriately." Section 3.4.34 says a correction should "set out what was wrong as well as putting it right," and names the BBC's public Corrections and Clarifications page as the place a mistake is acknowledged. Section 3.4.35 adds that where content is expected to be permanently available, as a blog post is, serious breaches must be corrected and acknowledged in a timely manner, content may in exceptional cases be removed, and "it should be clear what changes have been made." Those four ideas, acknowledge, correct, state what was wrong, and show that the page changed, are the whole policy.

Most of the day-to-day difficulty in corrections is deciding whether a fix needs a note, and most of that difficulty disappears once the line is written down. The policy here draws it at meaning, following the BBC's online rule, and adds a second test for the cases where meaning is arguable: would a reader who cited the old version now be embarrassed? If a reader could have repeated the error to someone else, they are owed a note. If the error was invisible in any reasonable reading, the fix is silent.

The router below applies that to the situations a small site meets most. Two of its rows deserve a comment. A correction that changes the post's conclusion is not a correction in the ordinary sense; it is a different post, and the note goes at the top, before the reader invests in an argument the site no longer stands behind. And an error in the metadata, a wrong number in the meta description or the title, is corrected silently on the page but logged, because the reader never sees the old version on the page itself, yet Google says the metadata must be checked to the same standard.

A failure case at each end. Over-labelling: a note on every typo fix, which trains readers to ignore the notes and buries the one that matters. Under-labelling: a figure changed from 12% to 1.2% with no note because "it was obviously a typo," when a reader has already quoted the 12% in a slide. The second is the worse failure and the more common one, because the fix is small and the day is busy.

A correction note has four parts and no more: the word "Correction", the date, what the earlier version said, and what is now stated. The order matters. Readers skim the note to decide whether it affects them, and "what was wrong" is the part that tells them. The BBC's guideline that a correction should set out what was wrong as well as putting it right is the reason the template below never omits the old value, even when it is embarrassing, and SPJ's "explain corrections and clarifications carefully and clearly" is the reason it never hides behind "this post has been updated for accuracy."

Placement follows prominence. A note for a figure or attribution error goes at the end of the post under a "Corrections" heading and, where the layout allows, as a short bracketed line beside the corrected sentence. A note for an error that changed the conclusion goes at the top, in the same visual weight as the opening paragraph. A clarification, where the original was accurate but readers took it the wrong way, uses the word "Clarification" and the same structure, so that the site's log distinguishes the two.

One example of a note written to the template: "Correction, 4 October 2026: an earlier version of this post said the regulation took effect in March 2026. It took effect on 12 May 2026. The paragraph has been corrected." One failure case: "Updated for accuracy," which tells the reader that something was wrong, not what, and so satisfies neither the reader nor the codes.

schema.org carries a property for exactly this. Its definition of correction reads, in full: "Indicates a correction to a CreativeWork, either via a CorrectionComment, textually or in another document." It is used on CreativeWork, so on Article and BlogPosting, and accepts a CorrectionComment, plain text or a URL. schema.org acknowledges that the term and its definition are based on the work of The Trust Project. The property is a vocabulary term, not a Google feature; Google's Article documentation does not list it among recommended properties, and no search feature depends on it.

So why add it? Because the markup is the machine-readable copy of the policy, and tools that read structured data, including the models that increasingly summarise pages, can see that a correction exists and when it was made. It also forces the discipline: a CorrectionComment has a text and a datePublished, which is the same four-part note from section 05 in a form that cannot be fudged. The example below follows the shape of schema.org's own, which marks up a news article whose correction notes a misstated count.

Two notes on the example. The dateModified moves with the correction, because a correction alters the meaning and is a substantive change under the date rule; a silent typo fix would not move it. And the text of the CorrectionComment is the visible note, word for word, so the two copies cannot drift. If the post accumulates more than one correction, the property accepts a list, and the visible "Corrections" section lists them in the same order with the newest first.

Removal is the last resort, and the codes treat it that way. The BBC's guideline for permanently available content says serious breaches must be corrected and acknowledged, and that "in exceptional cases, content may be removed," with the change made clear unless there are editorial or legal reasons not to. For a small site the exceptional cases are few: a post whose central claim was wrong and cannot be corrected without becoming a different post; a post that names a person or company in a way the site cannot stand behind; a post that was published by mistake. In every other case the post stays up, corrected, with the note.

When a post is removed, the URL should not simply vanish. Leave a short page at the same address saying the post was removed, when, and in one sentence why, and if the subject is covered elsewhere on the site, link there. A redirect to an unrelated page is a silent edit of the record, which is the practice the whole policy exists to avoid. The mechanics of removal, including what Google does with a 404, a 410 or a noindex, are their own subject and not repeated here.

The public log is the site-level counterpart to the per-post note. The BBC maintains a Corrections and Clarifications page for its output, and a small site can keep a single page listing every labelled correction with its date, the post, and the note. It rarely gets traffic. Its value is that it exists: a reader or a citing writer can see, in one place, that the site corrects itself and how often, and the site's own editors can see the pattern. Five figure corrections in one quarter, all from the same kind of source, is the finding that changes the pre-publication checks.

A correction policy without a prevention loop corrects the same class of error every month. The loop is the log, read against the checks a post passes before publication. Google's guidance already states the first check: manually fact-check all AI-generated content, including metadata, before publishing. The four checks below are the specific forms that instruction takes for the error classes a model is most likely to produce, and each is a thing a single editor can do in minutes on a draft.

Every figure is traced to a source the editor has opened, and the sentence containing the figure names that source. Every quotation is compared to the primary text and either matches it inside quotation marks or is rewritten as a paraphrase without them. Every attribution is checked against the document it points to, because a model will confidently assign a finding to the best-known organisation in the field. Every date is checked for the two failure modes a model produces: a plausible date that is wrong, and a date that is correct for a related event. The metadata is read as carefully as the body, because it is the part most often generated last and reviewed least.

The failure case is the check that exists on paper and is skipped under deadline, which is why the log matters: it turns "we should check figures" into "we published five wrong figures last quarter, all from one source type." Building that loop into a publishing workflow, so the checks run on every draft and the log fills itself, is the kind of system our content engine service sets up.