Version control for content: undoing a bad edit
How content on a modern website is versioned like code, and what that makes possible when an edit goes wrong.
The short answer
On a modern website, content lives alongside code in the repository, and that means content is versioned the way code is. Every change to every page is recorded as a commit, with who made it, when, and a message saying why, and the differences between any two versions can be shown side by side. A bad edit is undone by reverting its commit, which restores the previous content through the pipeline and is live in minutes, itself recorded. A bad batch of edits is reverted as a batch. The entire site can be returned to its state on any past day. Because every change is previewed on a private address before publishing, most bad edits never go live at all. Traditional content systems keep revision lists per page in a database, which helps with one page and is lost when the platform is left; repository versioning keeps the whole site’s history, atomically with the code, and it goes with the business wherever the site goes.
Per-page revisions versus repository versioning
| Aspect | Revision history in a traditional CMS | Content versioned in the repository |
|---|---|---|
| What is versioned | Individual pages, sometimes settings | Every page, every asset, the structure and the code, together |
| Undoing one edit | Restore a page revision | Revert the commit |
| Undoing a batch across pages | Page by page, if you can find them | Revert the batch in one step |
| Seeing what changed | Sometimes a diff, sometimes only versions | A precise diff for every change |
| Who and why | Author and time; rarely a reason | Author, time and a message |
| Returning to a past date | Not possible site-wide | Check out that date |
| Preview before publishing | Sometimes | Always, on a real preview address |
| Portability | Lost when leaving the platform | Travels with the repository |
| Relationship to code | Separate; content and code can drift apart | Atomic; a change to both goes live together |
What it looks like in practice
- An editor changes a page in the editing interface and saves; a commit is recorded.
- A preview link appears; the editor or a colleague checks the real page.
- They publish; the pipeline checks and builds; the change is live in minutes.
- A mistake is noticed an hour later: a wrong price, a deleted paragraph, a broken link.
- The commit is reverted; the previous content goes through the same pipeline and is live in minutes.
- The history shows both the mistake and the correction, with names and times.
- Nothing else was affected, because the revert touched only what the original change touched.
Content and code, together
Because content and code share a history, a change that needs both, such as a new page type with its first pages, goes live as one unit or not at all. A rollback returns both. A branch can hold a large content project, a new section or a rewrite, in previews for weeks while the live site continues to be edited, and merge when ready. These are the everyday tools of software development, applied to the words on the site, and they are why a well-built site never loses content and never fears an edit.
What this means for you
Content versioned in the repository means every edit is recorded, previewed before it is live, reversible in minutes, traceable to a person and a reason, and portable with the site. Editors do not need to learn anything; they notice previews and reversibility. It is one of the quiet reasons a modern site is safer to change than a traditional one, and it costs nothing once the site is built that way.
Frequently asked questions
What happens if someone publishes a mistake?
The change was recorded as a commit with the pages it touched. Reverting that commit restores the previous content, goes through the pipeline and is live in minutes, and the revert itself is recorded too. Nothing is lost in either direction, and there is no hunting through per-page revision lists to find which pages were affected, because the commit shows them.
Can we see who changed what and why?
Yes. Every change carries an author, a time and a message describing it, and any page's history shows the sequence of changes with the differences highlighted. When a client asks why a paragraph changed, or when a legal text needs to be shown as it was on a given date, the answer is a lookup rather than a memory.
Do editors need to learn version control?
No. Editors work in an editing interface or a content system that records changes into the repository behind the scenes, with a preview link and a publish button. The versioning is invisible in daily use and available when something needs undoing. What editors notice is that previews exist and that mistakes are reversible.