Know what revision history can—and cannot—recover
Revision history is a record of earlier versions of a page or post. In a content management system, it may show when a version was saved, who saved it and what text changed. The details vary by platform and configuration: some systems record every save, while others keep only published versions or a limited number of revisions. Before relying on the feature, open a low-risk page and see what your site actually stores.
A revision is not necessarily a full website backup. Restoring page text may not restore a deleted image, a changed menu, a form setting or content managed by a separate plugin. It may also replace useful edits made after the version you choose. Treat revision history as a tool for examining and recovering content, alongside regular backups and a clear publishing process.
Compare changes before deciding what to keep
When a page looks wrong, start with the current published version and identify the problem as precisely as you can. Is a paragraph missing, has a heading changed, or does the page show outdated information? Then compare the current version with the most recent earlier version. If your system provides a side-by-side comparison, read both additions and deletions; a shorter page is not automatically an incomplete one.
Work backward one revision at a time until you find where the issue appeared. Check the save time and editor name if available, but do not assume the person shown caused every visible difference. An editor may have saved a draft that already contained someone else’s changes. For an important page, ask a colleague to confirm which wording is correct before you replace anything.
Keep the page’s purpose in mind during review. A restored sentence might be clearer but contain an old contact address or service description. Check calls to action, links and accessibility details such as descriptive link text. Revision history tells you what was there before; it does not tell you whether that version still serves visitors well.
Restore the smallest useful change
If only one passage needs to return, copying that passage from an earlier revision into the current draft is often safer than restoring the entire page. This preserves newer edits elsewhere. Before making the change, save or otherwise record the current version so you have a way back. If several people edit the same page, let them know you are working on it to reduce the risk of overlapping saves.
Use a full-version restore when the page has been extensively overwritten and the earlier version is clearly the right starting point. Preview the restored draft before publishing, if your system allows it. Check headings, images and their alternative text, internal links, formatting and any page-specific settings the editor exposes. After publishing, open the public page and confirm that the intended content appears. A successful restore message in the editor is not a substitute for checking the result.
Make reviews manageable for a small team
A lightweight review routine is more useful than a complicated approval process nobody follows. For pages that change regularly, assign an owner, note what needs updating and agree on who checks the draft before publication. A brief change note can explain why an edit was made, especially when the reason is not obvious from the text alone. Where your content system supports roles, give publishing access only to people who need it.
Choose review effort to match the impact of the page. A minor wording change may need a quick preview. A change to opening hours, eligibility information or a prominent sign-up page deserves a closer check of the entire visitor journey. If you discover an error after publishing, correct it promptly, then use the revisions to understand how it happened without turning the review into a search for blame.
Practice recovery before you need it
Test the process on a draft or other low-risk page: make a small edit, save it, find the earlier version and compare the two. Learn whether restoring creates a new revision, whether drafts and published changes appear in the same list, and who on your team can access the history. Write down the steps in a short internal guide, using the labels your own system displays.
Finally, decide what you would do if revision history is unavailable or does not contain the content you need. Regular site backups, retained source documents and a named person responsible for recovery can provide other paths. With those safeguards in place, revision history becomes more than an emergency undo button: it is a practical way to review changes thoughtfully and keep a small site accurate.
