Version control for content isn't just for developers

You're already doing versioning badly

Every time you duplicate a Google Doc with "_FINAL_v3" appended, you're acknowledging that content changes matter. Every time you wish you could see what a page looked like last month, you're feeling the absence of proper version control. Most CMS platforms offer revision history, but those logs are ephemeral, platform-locked, and vanish when you migrate or when storage limits force a purge.

Version control for content means maintaining a readable, portable record of changes independent of your publishing system. It's not about adopting developer workflows wholesale — it's about capturing decisions before they become archaeology.

What you actually need to track

Not every typo fix deserves documentation, but structural changes do. Track:

• Page structure changes: new sections, removed content blocks, reordered components
• Terminology shifts: when you stop calling something "resources" and start calling it "guides"
• Navigation or IA changes: menu restructuring, category renames, taxonomy adjustments
• Template or field changes: when you add a new content type or modify existing fields
• Significant copy revisions: not line edits, but rewrites that change meaning or emphasis

The threshold is simple: if you'd want to know why this changed six months from now, track it.

A minimal versioning system that works

You don't need Git. You need a dated log file and the discipline to use it.

Create a content-changes.md file in a shared location. For each significant change, add an entry:

## 2025-01-15 — Services page restructure
- Removed "consulting" section (moved to separate page)
- Reordered remaining services by popularity
- Updated intro paragraph to reflect new focus
- Why: Analytics showed 80% of services traffic went to two items

Date descending, most recent at top. Markdown formatting means it's readable as plain text and renders nicely in any documentation system. The "Why" line is non-negotiable — it's the only part your future self can't reconstruct from memory.

When CMS revisions aren't enough

Most content management systems track revisions, but they track everything with equal weight. You get a log that says "Updated 247 times" with no signal about what mattered. CMS revisions also:

• Disappear when you migrate platforms
• Get pruned when storage limits hit
• Don't capture cross-page changes or structural decisions
• Provide no space for rationale or context

Use CMS revisions for granular undo. Use your own version log for understanding what happened and why. They serve different purposes. Your publish schedule already documents when you ship — version control documents what you changed between ships.

Who writes the entries

Whoever makes the decision writes the log entry. Not later, not delegated — immediately after the change goes live. If three people collaborate on a restructure, one person owns the log entry, but they note all contributors.

This isn't about blame or credit. It's about creating a paper trail for the person (often you) who needs to understand a choice that's now six months cold. Treat it like consistent terminology: a small, repeated practice that compounds into clarity.

The file lives with your content source files

If you draft in plain text before CMS entry, the version log lives in that same folder structure. If you work entirely in a CMS, the log lives in your shared documentation space — same place you keep your style guide and content templates.

The location matters less than consistency. Version control only works if people know where to look and actually maintain it. One file, one format, one clear owner who enforces the practice.

You're not trying to recreate Git's branching model or commit message conventions. You're creating a simple, sustainable record of decisions that would otherwise evaporate. Start today: create the file, log your next structural change, and establish the expectation that changes get documented before they get forgotten.