The short answer
Log every change that could affect how people or search engines see the site, including templates, redirects, tracking and plugins, not just copy. For each one, record the date and time, the URLs, what changed, why, who approved it, the metric you expect to move and how to roll it back. Use Search Console and Google Analytics annotations as markers on the charts, but keep the full record in the log itself.
Why a change log matters
When a key metric moves, the first question is always "what changed?". Without a log, the answer depends on someone's memory, and on a site edited by marketers, developers, agencies and plugin updates, nobody remembers everything.
- Attribution. You cannot measure the effect of a change if you do not know exactly when it went live. A before-and-after comparison that starts on the wrong day mixes the two periods.
- Diagnosis. Google's guide to debugging drops in search traffic lists site moves and migrations among the main causes: "If you change the URLs of existing pages on your site, you may experience ranking fluctuations"1. The same guide lists algorithm updates, technical issues and seasonality. A log tells you which of those you can rule out.
- Rollback. If a change hurts, the log tells you what the page looked like before and how to put it back.
- Learning. A year of entries with outcomes shows which kinds of change tend to help on your site, and which do not.
- Accountability. When several people and an agency can publish, the log shows who changed what and who approved it. Our guide to human-in-the-loop website changes covers approval in more detail.
What counts as a change
Log anything that could change what visitors see, what search engines crawl, or what your analytics records:
- Content: headlines, body copy, calls to action, images, proof such as case studies and logos.
- Search appearance: page titles, meta descriptions, headings, structured data.
- Structure: navigation, internal links, new or deleted pages, URL changes and redirects.
- Templates and design: any change to a shared template, which can affect hundreds of pages at once.
- Forms: fields added or removed, new form tools, changes to what happens after submission.
- Technical: CMS and plugin updates, hosting or CDN changes, caching,
robots.txt, sitemaps, canonical tags. - Measurement: new or changed analytics tags, key event definitions, consent banner changes. These change the numbers without changing visitor behaviour, so they are easy to mistake for a real effect.
Log outside events too
Your changes are only half the story. Keep a second list, or a "type" column, for things that happened to the site rather than on it:
- campaigns, launches, webinars and trade shows;
- price changes and sales team changes;
- public holidays and the end of your customers' financial year;
- Google ranking updates, which Google reports under Ranking on its Search Status Dashboard2;
- outages, tracking gaps and known data problems.
What to record for each change
| Field | Why it matters |
|---|---|
| Date and time live (with time zone) | Sets the start of the "after" period. Use the time it went live, not when the work was done. |
| Pages or templates affected | Lists exact URLs, or the template and how many pages use it. |
| Type | Content, search appearance, structure, technical, measurement or outside event. Lets you filter. |
| What changed | Before and after, in a sentence each, with a link to a screenshot or diff. |
| Why | The evidence behind it: a Search Console query, a sales objection, a usability finding. |
| Expected effect and metric | Which metric should move, in which direction. Written before the change, not after. |
| Measurement window | The baseline and the "after" period, fixed in advance. |
| Who made it, who approved it | Names or roles. Avoid personal details beyond that. |
| Rollback | How to undo it, and whether the previous version is saved. |
| Outcome | Filled in at the end of the window: improved, worse, inconclusive or insufficient traffic, with the numbers. |
A template to copy
A spreadsheet with these columns is enough. Here are three example rows, invented for illustration:
| Live | Pages | Type | Change | Why | Metric and window | Outcome |
|---|---|---|---|---|---|---|
| 2026-10-06 10:15 | /services/data-audit/ | Search appearance | Title rewritten to lead with the buyer's problem | High impressions, low CTR in Search Console | Organic CTR, 28 days before vs 28 days after | Pending |
| 2026-10-13 09:00 | Services template (12 pages) | Forms | Contact form cut from 9 fields to 5 | Sales say 4 fields are never used | Form submissions, 8 weeks each side | Pending |
| 2026-10-20 | Whole site | Outside event | Two-week paid campaign starts | n/a | n/a | n/a |
The third row matters as much as the first two: anyone reading the form change's results later will see that a campaign overlapped its window.
Where to keep it
The best place is the one your team will actually update. Options, from simplest to most robust:
- A shared spreadsheet. Easy, filterable, and anyone can add a row. Protect the header row and use dropdowns for the type and outcome columns.
- Your project tracker. If every change already has a ticket, add the fields above to the ticket and record the live date when it ships.
- Version control. If the site is built from a code repository, commits record exactly what changed and when. Add a plain-English summary, because commit messages rarely say why or what to measure.
- CMS revision history. Useful for recovering an old version, but it records every save, not just what went live, and usually not why.
Whatever you choose, it should be one place, not a mix of all four.
Search Console and Google Analytics annotations
Both of Google's main tools now let you put notes on their charts, which makes changes visible where people look at the data.
Search Console
Google introduced custom annotations in Search Console's Performance report on 17 November 2025, suggesting uses such as template updates, site migrations, content changes and external events like holidays3. According to Search Console Help4:
- you add one by right-clicking the chart on a date; notes are limited to 120 characters;
- each property can hold 200 annotations, and annotations older than 500 days are deleted automatically;
- owners and full users can add and delete them, and restricted users can view them;
- they do not show in comparison mode or in 24-hour views;
- they are shared with everyone on the property, so Google advises against including personal information such as names, phone numbers or addresses.
Google Analytics
Google Analytics annotations appear on all reports and report cards with line graphs. Titles are limited to 60 characters and descriptions to 150; each property can hold 1,000; creating them needs the Analyst role or above, and viewing them the Viewer role5. Analytics may also add its own system annotations about data issues, which cannot be edited or deleted5.
Why annotations are not enough on their own
- They hold a short note, not the reason, the expected effect, the approval or the rollback.
- Search Console deletes them after 500 days, so they cannot hold a year-on-year history for long.
- They live separately in each tool and each property, so nothing joins them up.
The practical approach: write the full entry in the log, then add a short annotation in both tools with the same wording, such as "Services contact form cut to 5 fields (log #14)".
Using the log to attribute results
A log does not prove a change caused a result, but it makes an honest judgement possible:
- Find every entry in the window. If two of your changes and a campaign overlap, say so; you cannot separate them afterwards.
- Compare like with like. Use the same length of period before and after, aligned by weekday, and compare with similar pages you did not change.
- Check outside events. Google updates, holidays and tracking changes from the second list.
- Record the verdict in the log. Improved, worse, inconclusive or insufficient traffic, with the numbers.
Our guides to measuring the impact of a website change and before-and-after SEO testing show the method in detail. Spacing changes to the same pages apart, rather than shipping several at once, makes each entry easier to read. When an entry shows a change did harm, our website rollback plan guide covers how to undo it safely.
Habits that keep the log useful
- Add the entry on the day the change goes live, by the person who published it.
- Write the expected effect before the change, so the outcome cannot be rationalised later.
- Review the log weekly: fill in outcomes whose window has closed.
- Record inconclusive and negative outcomes as faithfully as wins.
- Make the log part of the process for agencies and developers, not only the marketing team.
Where Artiweave fits
For the changes Artiweave publishes, the approval and the outcome are recorded with each change, which covers part of this log. Changes made outside it, and outside events, still belong in your own log. For the wider approach, see our guide to AI website optimisation.
Frequently asked questions
What is a website change log?
A dated record of every change to your website: what changed, on which pages, when it went live, who approved it, why, and what happened afterwards. It is used to explain movements in traffic, rankings and leads, and to roll back changes that did harm.
What should a website change log include?
For each change: the date and time it went live, the pages affected, the type of change, before and after, the reason, the expected effect and metric, the measurement window, who made and approved it, how to roll it back, and the outcome.
Can I use Search Console annotations as my change log?
Use them alongside a log, not instead of one. Search Console annotations are limited to 120 characters, 200 per property, and are deleted after 500 days. They work well as markers that point to a fuller log entry.
Should I log plugin updates and tracking changes?
Yes. CMS and plugin updates can change page speed, markup or forms, and tracking changes alter the numbers without changing visitor behaviour. Both are easy to mistake for the effect of a content change.
How detailed should each entry be?
Enough that someone a year from now can understand what changed and why without asking. One sentence each for before, after and the reason, plus a link to a screenshot or diff, is usually enough.
Sources
- Google Search Central: Debugging drops in Google Search traffic (accessed November 2026)
- Google Search Status Dashboard (accessed November 2026)
- Google Search Central Blog: Adding context to your Search Console data with custom annotations (17 November 2025)
- Search Console Help: Search Console annotations (accessed November 2026)
- Analytics Help: About annotations (accessed November 2026)
Every change approved, logged and measured.
Artiweave publishes only the website changes your team approves, with automatic rollback, and reports each outcome honestly. It is in private beta.