What a corrections log actually needs to say

Ask a small outlet whether they have a corrections policy and most will say yes. Ask to see the log itself, and the answer gets vaguer. A folder of edited posts isn't a log. A quiet fix with no trace isn't a correction. What's actually needed is a page a reader can find, showing what changed and when, in language that doesn't try to minimize the error.

The resistance to building one is understandable. It feels like publicly cataloguing your mistakes, which is uncomfortable for any team, let alone a small one without much institutional buffer. But the outlets that keep readers longest tend to be the ones willing to be visibly accountable, not the ones with the fewest visible errors.

The minimum a log needs

A workable corrections log doesn't need to be elaborate. It needs four things for each entry: the date of the correction, a link to the affected piece, a plain description of what was wrong, and what was changed to fix it. Skipping any of these tends to make the log feel like an afterthought rather than a real record.

• Correction date, separate from the original publish date
• A direct link to the corrected piece
• What was inaccurate, stated without hedging
• What the corrected version now says

Where it lives matters as much as what it says

A corrections log buried three menus deep might as well not exist. It should sit somewhere a reader can find within a click or two of the footer, ideally near the about and ownership pages, since together they answer the same underlying question: can this outlet be trusted to tell me when it gets something wrong?

Smaller teams sometimes worry a visible log will be used against them by critics. In practice the opposite tends to happen — a maintained log, even a short one, reads as evidence of care rather than a catalogue of failure. Readers already assume mistakes happen somewhere. What they're actually judging is whether you're honest about it.