Short answer: an analytics annotation is a dated note attached to a chart, and a change log is a simple list of everything you changed on your site and when. Together they let you explain why traffic rose or fell, because you can compare the date of a movement with the dates of your changes, your publishing, and outside events such as search engine updates. Record each meaningful change on the day it goes live, with a short description and the pages affected, and review the log whenever a graph moves.
Most blog owners have had the experience of looking at a chart, seeing a sharp change and having no idea what caused it. Was it the new template, the plugin update, the batch of articles you published, a change in the search results or a holiday? Memory fades quickly, and after a few months it is nearly impossible to reconstruct what happened. A habit of writing things down solves most of that problem, and it takes a minute or two each time.
Why traffic changes are hard to explain
Traffic is affected by many things at once: your own changes, seasonal patterns, competitors, search engine updates, outages and the news. When several happen within the same fortnight, it is difficult to tell which one mattered. Without a record, people tend to blame the most recent change they remember, which is often wrong, or the most dramatic outside event, which may be a coincidence.
A change log reduces the guessing. It does not prove cause and effect, but it narrows the field and tells you what to examine. It also protects you from repeating mistakes, because you can see what happened last time a similar change was made. For a team, it is a shared memory that does not depend on one person staying in the job.
What to record in a change log
Record anything that could plausibly affect visibility, traffic or conversions. If you are unsure, write it down, because the cost is small.
- Content: new articles, major rewrites, merged or deleted pages, title and description changes.
- Technical changes: theme or template changes, plugin updates, redirects, robots.txt edits, sitemap changes, migrations, hosting changes and domain changes.
- Structure: changes to navigation, categories, internal links and URLs.
- Performance: caching, image compression and anything that changes page speed.
- Tracking: changes to analytics tags, consent banners, events and goals, which can alter the numbers without any real change in traffic.
- Promotion: newsletters, social campaigns, paid promotion, press mentions and partnerships.
- Incidents: outages, hacked pages, broken forms and anything that went wrong.
- External events: announced search engine updates, holidays, major news and seasonal peaks.
Tracking changes deserve special attention. A new consent banner or a mistaken tag can make traffic fall in your reports while the real number of visitors stays the same, and without a note you may spend weeks looking for a problem that does not exist.
A simple format that works
You do not need special software. A shared spreadsheet is enough, as long as everyone uses the same columns and writes entries at the time of the change.
- Date and time when the change went live, not when it was planned.
- Type: content, technical, structure, tracking, promotion, incident or external.
- What changed: one clear sentence.
- Pages or sections affected: a URL, a template or “whole site”.
- Who made the change and a link to any ticket or note.
- Expected effect: what you hope will happen, so that you can judge it later.
- Result: filled in after a few weeks, with what you actually saw.
Keep the wording factual and free of opinions, because you will read it months later and need to understand it without the context in your head. “Moved 40 articles into new categories” is useful. “Fixed the messy categories” is not. The “expected effect” and “result” columns are the most valuable. They turn a diary into a learning tool, because over time you see which kinds of changes usually help and which do not.
Using annotations in your analytics tools
An annotation puts the note on the chart itself, so that anyone who looks at the graph sees the context. Many analytics and reporting tools let you add dated notes to a timeline, and some dashboards let you overlay events from a sheet. If your tool has no such feature, you can mark dates on a screenshot or keep the change log beside the report and compare dates when you review.
- Add an annotation for each major change, using the same wording as the log.
- Use consistent labels, such as “template”, “migration” or “batch of new articles”, so that you can find similar events later.
- Annotate the start and end of campaigns and outages, not only single days.
- Keep annotations short, and put the detail in the change log.
Search Console has its own history of impressions and clicks, so it is worth keeping dates there too. Keep in mind that its data is delayed by a day or two, and that it is measured differently from your analytics, so compare trends and not exact numbers. Our article on Search Console and analytics explains the differences.
How to read a movement with the log beside it
When a chart moves, work through a short routine before you decide what happened.
- Pin down the date the change started, and whether it is a step, a slow slope or a spike.
- Check the log for anything that went live shortly before that date, and for external events at the same time.
- Look at which pages, queries, countries and devices moved. A change that affects the whole site points to something technical or external, and a change in a few pages points to content or links.
- Check the tracking first. Compare analytics with Search Console, server logs or another source to confirm the change is real.
- Compare the same period in the previous year, if you have the data, to separate seasonality from change.
- Form a hypothesis, make the smallest change that tests it and record that in the log as well.
Be careful about conclusions. Two things happening on the same day does not mean one caused the other. A log gives you candidates, and checks give you evidence. Where you cannot tell, write “unknown” in the result column and keep watching. Avoid the temptation to fill the column with a confident story, because a wrong explanation can send you in the wrong direction for months.
Handling updates from search engines
Search engines announce updates to their systems from time to time, and the announcements usually include a start and an end date. Record the dates in your log as external events. If your traffic changed during an update, compare which pages and queries moved, and look for a pattern in what they have in common, such as topic, quality, age or intent. Do not make big changes in a panic during the rollout, because results often settle after it finishes. Our article on algorithm updates explains how to respond in a measured way.
Making the habit stick
The habit works only if it takes almost no effort. Put the change log where the team already works, and make writing an entry part of the process of making a change, in the same way as testing or approval.
- Add a log entry to your checklist for publishing templates, plugins and redirects.
- Assign one person to review the log weekly and chase missing entries.
- Ask contractors and agencies to send you a note of every change they make, with dates.
- Back up the log, and keep it for years, since year-over-year comparisons need old entries.
- When you find a mistake in the log, correct it and keep a note of the correction, so that the record remains honest.
If your team is small, the person who makes a change should also write the entry, and the entry should take less than a minute. If you outsource work, include the log in the brief, so that the agency or freelancer knows that dated notes are part of the job. Even a minimal log is better than none. A short line written on the day is worth far more than a detailed reconstruction made six months later.
What you gain over time
After a year, the log becomes an asset. You can see how long it usually takes for a new article to gain traffic, which updates gave a lasting increase, how much seasonal variation to expect and which changes caused trouble. New team members can learn the history of the site in an hour. When you plan a migration or a redesign, the log shows what went wrong in previous ones and what to check. And when someone asks why traffic fell last March, you can answer with evidence instead of a guess. It also makes reporting to clients or managers easier, because every notable movement comes with a dated explanation and a record of what was done about it.
How AI Blog Autopilot helps
AI Blog Autopilot publishes articles on a schedule, so the dates of your new content are already known and easy to record in a change log. A content map shows every article and every social post in one place. Add your own technical and tracking changes beside them, and you will have a complete record. Plans are on the pricing page.
Related reading
- What to Do When Traffic Drops
- Measuring Content Decay
- Algorithm Updates: What They Mean for Your Content
- How to Measure Blog ROI
The bottom line
A change log and a few annotations turn confusing graphs into explainable events. Record every meaningful change on the day it goes live, including tracking changes and outside events, use a simple shared format with expected effect and result columns, and read each movement against the log before you decide what happened. Treat the log as evidence for hypotheses, not proof, and keep it for years.
KKK
What is an analytics annotation?
A dated note attached to a chart that records something that happened, such as a redesign, a campaign or an outage, so the graph is easier to interpret later.
Do I need special software for a change log?
No. A shared spreadsheet with date, type, description, affected pages, owner, expected effect and result is enough.
Does a change log prove what caused a traffic change?
No. It shows what else happened around the time, so you can form hypotheses and test them with more data.
What should I record about search engine updates?
The announced start and end dates, and how your pages and queries moved during that time. Avoid large changes in the middle of a rollout.
How often should I review the log?
Weekly for missing entries and whenever a chart moves. A monthly review of results helps you learn which changes worked.


