Why every website change should be versioned (and how to demand it)

No engineering team would accept a codebase where changes appear with no record of what changed, who changed it, or how to get back. Version control exists precisely so you can recall specific versions later and see who changed what, and when, and it has been free for decades. Yet most companies run their most public production surface without it. Your website is production software. Content changes are deploys, and deploys deserve history, authorship, a diff, and a rollback. That the change was a headline instead of a function doesn’t alter any of that.

The operations world learned this the hard way. Google’s Site Reliability Engineering book reports that roughly 70% of outages are due to changes in a live system, and lists rolling back safely as one of the three practices that contain the damage. DORA, the research program behind the most widely used software delivery metrics, tracks change fail rate and failed deployment recovery time for the same reason: changes are where things break, and recovery speed is what you control.

Three familiar failures, one root cause

• The Tuesday edit. Someone touched the homepage on Tuesday afternoon. On Thursday, a customer mentions the mobile hero has been broken for two days. There is no record of what changed, so the “fix” is archaeology: poking at the page builder until it looks approximately right again, with no way to know what else the poking changed.
• The compliance question. Legal, a customer dispute, or a regulator needs to know exactly what the pricing page said on March 12. Your best evidence is a third-party crawler’s snapshot from sometime that month, if you’re lucky. Your own systems have nothing.
• The rebuild from memory. The agency “fixed” a broken page by reconstructing it from a screenshot and recollection. It looks close. The disclaimers, the tracking parameters on two links, and a paragraph added for a partner deal are quietly gone, and nobody notices for a quarter.

These look like an operations gap, a records gap, and a vendor-quality gap. They are one problem: the site has no history, so every question about the past is unanswerable and every mistake is permanent.

What history actually buys you

• Fearless editing. This is the underrated one. When revert is one click, an edit stops being a risk and becomes a 30-second experiment, and edit volume goes up. The pricing page that runs a quarter behind actual pricing is rarely a laziness problem. More often it’s a fear problem, and removing the fear keeps the site true.
• Instant rollback. Something breaks at 4:50 on a Friday: revert now, diagnose on Monday. Without versioning, that same incident is an emergency call to whoever might remember what the page used to look like.
• An audit trail. “What did this page say on this date” and “who changed this and when” become queries with answers, which matters for compliance, for disputes, and for plain accountability.
• Safe automation. If you want an AI agent drafting your routine edits, versioning is the precondition. A draft you can read as a diff and revert in one click is reviewable; an agent editing an unversioned page is a liability with typing speed.

The honest caveat about WordPress and page builders

WordPress has shipped revisions since version 2.6 in July 2008, and for the body of a post or page they genuinely work: history, compare, restore. The current release goes further, with a revisions screen that highlights added, removed, and modified blocks. So the demand here is not “versioning must exist.” It half-exists everywhere. The gaps are coverage and granularity.

Coverage: by default, WordPress revisions track the title, author, content, and excerpt, and a site owner or host can cap or disable them with a single setting. Much of a modern marketing site lives elsewhere. Theme options, widgets, and many page-builder layouts are stored outside the post content, so depending on the plugin stack they are versioned by the plugin’s own history feature, poorly, or not at all. The hero that broke on Tuesday is usually in exactly the part with the least history.

Granularity: a revision that stores the page as one blob can tell you the page changed without telling you what changed. Two walls of builder markup in a compare view is technically a diff and practically unreadable. What you want is field-level: hero headline, was this, now this; CTA link, unchanged. That requires the content itself to be structured as named fields in typed sections, which is a data-model decision you can’t bolt on later with a plugin.

And the boundary in the other direction: if your site is five pages of prose that one person edits quarterly, built-in revisions plus a careful habit is genuinely enough. This infrastructure earns its keep when edits are frequent, when multiple hands (or agents) touch the site, or when what the site said on a given date carries legal or financial weight.

The demand list

Whether you’re evaluating a platform, an agency, or us, the checklist is four items:

1. Full history: every change to every page recorded, including layout-bearing sections, not just article text.
2. Field-level diff: a readable old-versus-new for each changed field instead of a blob comparison.
3. One-click revert: to any prior version, performed by you, without filing a ticket.
4. Author on every change: human or agent, with a timestamp. No anonymous edits, ever.

Then make the vendor demo it live: ask them to revert a layout change, not a paragraph, from three versions back while you watch. The ones who can will enjoy showing you. The ones who can’t will start explaining their process instead, and that answer is also information.

On the platform our managed sites run on, every save is an immutable revision with an author and a field-level diff, the property that makes both fearless human editing and agent-drafted edits safe to run. If you’re not sure what your current site can roll back, try the three-versions-back test on it this week; we’re happy to walk through the results with you.

Sources

• Site Reliability Engineering, Chapter 1: Introduction, Google
• DORA's software delivery performance metrics, DORA (Google Cloud)
• About Version Control (Pro Git), git-scm.com
• Version 2.6, WordPress.org Documentation
• Revisions, WordPress.org Documentation