Traffic drops by a third over a fortnight. The contact form stops sending leads. A page that ranked well for years slides to the second results page. In each case the first question is the same: what changed? On most business websites, nobody can answer with confidence. A website change log fixes that. It is a short, dated record of every meaningful edit, update and experiment on your CMS, kept by the person who made it, so that cause and effect stay connected long after the details have left anyone’s memory.<\/p>\n
This guide walks through setting one up and keeping it useful, step by step. It applies to WordPress, Drupal, Joomla or any other content management system, and to teams of one as much as teams of ten.<\/p>\n
A modern CMS site moves constantly. Core updates arrive, plugins and modules release new versions, themes change, editors publish and revise pages, marketers adjust titles and meta descriptions, and developers tweak caching or redirects. Hosting providers make their own changes underneath. Each of these is small on its own. Together they create a site whose behaviour can shift for reasons nobody wrote down.<\/p>\n
Without a log, diagnosing a problem becomes guesswork: rolling back random plugins, comparing old screenshots, asking colleagues what they remember. With one, you open the file, scan the entries from the days before the problem started, and usually find two or three likely suspects within minutes. The log also makes lessons stick. When a particular kind of update caused trouble last spring, the note reminds you to test more carefully this time.<\/p>\n
Decide where the log lives before deciding what goes in it. Options include a plain text or Markdown file in the site’s repository, a shared spreadsheet, or a page in your team’s wiki. The right answer is whichever location everyone who touches the site already opens. Avoid creating a new tool just for this.<\/p>\n
Then make each person responsible for logging their own changes. A central “log keeper” sounds tidy but fails in practice, because the details only exist in the head of whoever made the change.<\/p>\n
Every entry should answer five questions in a line or two each:<\/p>\n
A sample entry: “4 Nov, 14:20, RK. Updated the forms plugin from 5.8 to 6.0. Reason: security release. Test submission arrived, but the confirmation email now lands in spam. Next: check sender settings tomorrow.”<\/em> That entry takes under a minute and could save hours.<\/p>\n Logging every comma fix creates noise that hides the important lines. Agree on a short list of changes that always get an entry:<\/p>\n Routine blog publishing can be left out if the CMS already records it, though a one-line note for important launches is still worthwhile.<\/p>\n The most common failure is planning to write entries “later.” Later rarely comes, and when it does, the details have blurred. Write the entry immediately before or after making the change, while the version numbers and reasons are still on screen. Some teams keep the log open in a browser tab whenever they are logged into the admin dashboard.<\/p>\n The “observed” part of each entry is what turns a list of edits into knowledge. If you rewrote a page title to target a different search phrase, add a follow-up line two or three weeks later noting how impressions and clicks moved. Readers working on search visibility will find that the techniques in this guide to improving how a WordPress site performs in search<\/a> become much easier to evaluate when each adjustment has a dated entry and a recorded result beside it.<\/p>\n Set a recurring slot, weekly for busy sites or monthly for quieter ones, to read recent entries. Look for three things: changes whose outcomes were never recorded, repeated problems after similar updates, and experiments that worked well enough to roll out elsewhere. Many of the issues covered in this article on frequent CMS errors and how to steer clear of them<\/a> show up first as patterns in a change log, such as plugins piling up or settings drifting over time.<\/p>\n Agencies, freelancers and in-house teams change regularly. When a new developer or marketer takes over a site, the change log is the fastest briefing available. It shows which plugins were tried and removed, which redirects exist and why, and which experiments are still running. Small businesses that commission a new build can ask for the log to be part of the handover, just as they would ask for login details and documentation. If you are planning a site of that kind, this overview of building a WordPress site for a growing small business<\/a> is a useful companion.<\/p>\n The log should describe changes, not store credentials. Never paste passwords, API keys or customer data into it. Refer to where the secret lives instead, such as “updated payment key in the vault.”<\/p>\nStep 3: Decide what counts as “meaningful”<\/h2>\n
\n
Step 4: Log at the moment of change<\/h2>\n
Step 5: Record outcomes, not just actions<\/h2>\n
Step 6: Review the log on a fixed day<\/h2>\n
Step 7: Use the log for handovers<\/h2>\n
Step 8: Keep sensitive data out<\/h2>\n
Learning from practitioners in other fields<\/h2>\n