A content change log is a short, human-written record of every meaningful change to published content: the date, the post, what changed, why, and who made the change. Your CMS may already save revisions that show what the text looked like before, but revisions rarely say why a change was made or who asked for it. Keep the log in one shared place, add a line whenever a published post is edited for substance, and review it when something looks wrong. It takes seconds per entry and saves hours of guessing later.
The situation it prevents is familiar. A post that ranked well now reads differently. A figure has changed. A paragraph that a client asked for has vanished. Someone edited it, and nobody knows who, when or why. The revision history, if your platform has one, might show the before and after, but not the reasoning. So the team argues about whether to put it back.
This guide covers what a content change log is, how it differs from what your CMS records automatically, what to put in each entry, and how to keep the habit going. It works on any platform. Documentation mentioned below was checked on September 25, 2026.
What your CMS already records, and what it does not
Most platforms keep some history, but it answers different questions from a change log.
| Record | Answers | Usually does not answer |
|---|---|---|
| Revision history | What did the text look like before? | Why was it changed? Who asked? |
| Activity or audit log | Who touched which item, and when? | What the change meant, or why |
| Content change log | What changed, why, who decided | The exact before-and-after text |
Revision history varies a lot between platforms, and it has limits. WordPress’s Revisions documentation (last updated May 1, 2026, read September 25, 2026) says that by default it tracks changes to the title, author, content and excerpt, and that a site can be set to store only a fixed number of revisions per post, with older ones deleted automatically when the post is updated again. Other systems keep more or less, some keep history only on certain plans, and some static or Git-based setups store history in the repository rather than in an editing screen.
The point is not that revision history is bad. It is that none of it records intent. A revision shows that a sentence was removed; it cannot tell you it was removed because a source was withdrawn, a client objected, or a writer made a mistake. That is the gap a change log fills.
There is one more reason to keep the log outside your CMS. Revision and activity data does not always come with you when you change platforms, so a log in a separate document survives things the built-in history may not. Our CMS migration guide covers what tends to travel in a move and what does not.
What to put in each entry
Keep entries short enough that people will actually write them. Six fields cover almost everything:
| Field | Example |
|---|---|
| Date | 2026-10-29 |
| Post | Title and URL |
| Type of change | Correction, update, removal, rewrite, metadata |
| What changed | “Replaced the pricing paragraph with a link to the vendor’s page” |
| Why | “Vendor changed plans; our figure was out of date” |
| Who | The person who made it, and who approved it if different |
The “why” field is the one that matters most and the one people most want to skip. Make it required. “Updated” is not a reason; “source updated its guidance in September” is.
The “type” field borrows an idea from software. The open-source convention Keep a Changelog (version 1.1.0, read September 25, 2026) defines a changelog as “a curated, chronologically ordered list of notable changes for each version of a project” and groups changes into types such as Added, Changed, Removed and Fixed. Content does not have versions in the same way, but two ideas carry over well: record notable changes, not every keystroke, and label each one so the log can be scanned.
What counts as a change worth logging
If every typo fix goes into the log, people stop reading it and then stop writing it. A workable line:
Log it:
- Any correction of a fact, figure, name or claim
- Adding, removing or replacing a section
- Changing a title, URL, category or publish date
- Removing or replacing a source or quote
- Unpublishing, archiving or restoring a post
- Any change made at someone else’s request, such as a client, a legal reviewer or a person named in the piece
Skip it:
- Typo and punctuation fixes that do not change meaning
- Formatting and spacing
- Swapping an image for a better version of the same thing
When in doubt, log it. A one-line entry costs almost nothing.
Where to keep a content change log
The best location is the one your team already opens every day. Options that work:
- A shared spreadsheet, one row per change. Easy to sort by post or date, and easy to filter by type.
- A running document, newest entries first. Simple, but harder to filter as it grows.
- A field or note on the content item itself, if your CMS supports custom fields. Keeps context next to the post, but is harder to review across the whole site.
- Commit messages, if your content lives in a Git repository. The “why” can go in the commit message, as long as the team writes real messages rather than “update.”
Whichever you pick, use one place. A log split across three tools is a log nobody trusts.
Making the habit stick
A change log fails for one reason: people forget, or decide this particular edit is too small. A few habits help.
Tie it to approval. If published changes need sign-off, the approver can check the log line before approving. This works best when one person has the final say on live changes, as described in our piece on why one final approver fixes most broken workflows.
Put it in the checklist. Add “log entry written” as the last step of any edit to a published post, next to checking the preview.
Review it monthly. Skim the last month of entries. Patterns show up quickly: the same kind of correction on many posts, or one section of the site being edited again and again. Recurring corrections often point to a missing rule, which belongs in your one-page editorial style guide so the fix happens before publishing next time.
Do not use it for blame. If people fear the log, they stop writing honest entries. It is a record of decisions, not a list of mistakes.
Using the log when something goes wrong
The log earns its keep on a bad day. When a post suddenly looks wrong, or a client asks why a paragraph is gone:
- Search the log for the post.
- Read the most recent entries and their reasons.
- If the reason still holds, explain it; if not, use the revision history, where your platform has one, to see the exact earlier text.
- Make the change, and log that too, including why you reversed the earlier one.
This turns an argument into a two-minute lookup. It also protects against quiet reversals, where someone undoes a deliberate correction because they did not know it was deliberate.
A starter template
Copy this into a spreadsheet and start with the next edit you make:
| Date | Post | Type | What changed | Why | Who |
|---|---|---|---|---|---|
You do not need to log past changes before starting. Begin from today, and the log becomes useful within a few weeks.
FAQ
What is a content change log?
It is a written record of meaningful edits to published content, listing the date, the post, what changed, why and who made the change. It adds the reasoning that automatic revision history usually does not capture.
Isn’t revision history enough?
Revision history shows what the text looked like before, and some platforms limit how many revisions are kept. It rarely records why a change was made or who requested it, which is often the question you actually need answered.
Which changes should go in a content change log?
Log corrections, added or removed sections, title, URL or category changes, removed sources, unpublishing or restoring posts, and anything changed at someone else’s request. Skip typo and formatting fixes.
Where should a small team keep its change log?
In one shared place the team already uses, usually a spreadsheet with one row per change. If your content lives in Git, well-written commit messages can do the same job.
How long does it take to maintain?
A single entry takes a moment to write. The larger cost is the habit, which is easiest to keep when the log is part of the approval step for published edits.
