The problem: results without context
A site owner looks at a chart and sees visits fell by a fifth in the second week of March. What happened? Without notes, the answers are guesses: a redesign, a plugin update, a search engine change, a holiday, a competitor, a hosting problem, a deleted page or nothing at all. Six months later, nobody remembers what was done that week, and the chart cannot be explained.
A change log solves the problem by recording what you did and when. Annotations carry that information into the charts and reports, so a reader sees the event next to the movement.
What a change log is
A change log is a dated list of things that could plausibly affect how the site works, looks or performs. It does not need special software. A spreadsheet, a shared document or a text file works if it is easy to update and the whole team knows where it is.
Each entry needs only a few fields:
- Date (and time, for anything that went live at a specific moment).
- What changed, in plain words and with page addresses where relevant.
- Why, meaning the reason or the problem you were trying to solve.
- Who made the change.
- Expected effect, written before you see the result, which helps you judge honestly afterward.
- Notes or follow-up, such as “check in four weeks.”
What to record
Record anything that could reasonably alter visitor behavior, technical health or how search engines see the site:
- Edits to page titles, headings, descriptions and main content, particularly on key pages.
- New pages, removed pages and merged pages, including any updates to old content.
- Changes to site structure, menus, categories or URLs, and any redirects that you set up.
- Design and template changes, including new fonts, images, pop-ups or layout updates.
- Software, theme and plugin updates, and hosting or server changes.
- Tracking changes, such as new goals or changes to the analytics code, since these change the numbers without changing the site.
- Settings that control crawling and indexing, such as edits to the robots file or sitemap.
- Marketing activity that could drive visits: an email campaign, a mention elsewhere, a seasonal promotion.
- Outages, errors and security incidents.
You do not need to log a corrected typo. A useful rule is: if it would be worth mentioning when you later try to explain a change in the numbers, write it down.
Annotate the reports
Many reporting tools let you add notes to the timeline of a chart. If yours does, mark the dates of significant changes there. If not, add a column to your monthly summary or a short section called “What changed this period.” In either case, the aim is the same: anyone reading the numbers should see the events beside them.
Keep annotations brief and factual: “Replaced home page image and rewrote product intro” is better than “major improvements.”
Reading results carefully
Annotating is not the same as explaining. A dated change next to a movement is a lead, not proof. Some precautions:
- Allow time. Search engines may take days or weeks to recrawl and reassess a page, so a result that appears the next morning is less likely to be linked to a change made that morning.
- Expect noise. Traffic fluctuates naturally, and small sites vary more. Compare against typical variation, not against a single prior day.
- Watch for seasonality. Compare with the same period a year earlier, if you have that history.
- Look for other causes. If several things changed in the same week, you cannot separate their effects. That is a reason to space out significant edits where practical.
- Check the measurement. Some drops are tracking faults, not real declines. A change in analytics setup shows up in the log for exactly this reason.
- Do not claim credit too quickly. A rise after a content update may be coincidence. Say “traffic rose after the update; we cannot be sure of the cause.”
Make changes easier to learn from
A few habits turn a change log into a learning tool.
- Change fewer things at once. When you edit titles on twenty pages, edit them on a defined group and note which pages. Then you can compare that group with similar pages left alone.
- Write the expectation first. “We expect fewer errors in the report” or “We hope more people complete the form.” Revisit it later and note what actually happened.
- Set a review date. Four to eight weeks after a notable change, look back at the relevant pages and log what you saw.
- Take before-and-after captures of important pages, such as a screenshot or a saved copy of the text, so later you know exactly what was different.
- Keep backups before major changes, since a log can tell you what happened but cannot undo it.
Store it where it will be found
The log is only valuable if people use it. Keep it in one agreed place, assign someone to maintain it, and add a minute to your monthly routine to check it is current. If outside help works on the site, ask them to add their changes to the same record. When you eventually bring in a specialist or investigate a problem, this record will often be the first thing asked for.
A starter template
Columns for a spreadsheet: date, page or area, what changed, reason, person, expected effect, review date, outcome notes.
Ten well-kept entries over a year tell you more than a perfect system started and dropped. Begin small, stay honest about what the results do and do not show, and let the record build up over time.