Website change log: how to record site changes and trace what moved your traffic

What is a website change log, and how is it different from a developer changelog?

A website change log is a marketing-facing record of everything that changed on your site, written so that anyone looking at a traffic or conversion chart can match a date to a cause. It is not the same as a Git history or a product changelog.

A developer changelog lists commits and version numbers. It rarely says that the release also changed the H1 on 40 category pages, removed a form field or moved the consent banner. Those are the details that explain a shift in organic clicks or lead volume, and they are the details a website change log keeps.

Think of it as one part of a wider marketing change log: the website lane, next to your ad accounts, tracking and CRM. The site is often the shared cause behind changes that show up in several channels at once, because paid, organic and email traffic all land on the same pages.

What should a website change log record?

Record any change that can alter how pages are crawled, how they rank, how fast they load or how visitors convert. If you are unsure, log it: an entry costs a minute, a missing one can cost days of analysis.

Also log changes you did not make but that affect the site: a plugin auto-update, a hosting outage, or a Google ranking update. They belong on the same timeline because they compete with your own edits as explanations.

How do I set up a website change log?

Use a fixed set of fields, one entry per change, and make logging part of the release process rather than a memory exercise afterwards.

1. Date and time of go-live. Not the date the ticket was closed. Note the time zone, because analytics reports and servers often use different ones.
2. Scope. Which URLs, templates, sections or markets were affected (for example, "all /blog/ pages" or "checkout, mobile only").
3. What changed, before → after. "Title pattern: Product | Brand → Buy Product online | Brand" is useful. "SEO tweaks" is not.
4. Type tag. Release, content, redirect, technical, tracking, offer. Tags let you filter later.
5. Owner. The person or agency who made the change, so you know whom to ask.
6. Reason and expected effect. One line: what you expected to happen and to which metric.
7. Link. Ticket, pull request, GTM version or screenshot.

A shared spreadsheet works to start; our marketing change log template has the columns ready. The rule that matters more than the tool: whoever deploys, logs. Add a "logged?" checkbox to your release checklist so entries are written on the day, not reconstructed a month later.

Can I log website changes in GA4 or Search Console instead?

Both tools now let you mark dates on their charts, which helps people who live in those reports. Neither is a full change log, because of size limits and retention.

Search Console annotations cannot be edited after you add them, and Google advises against putting personal data such as names in them. GA4 also adds system annotations of its own when a data-impacting event happens. Use these markers as pointers ("Checkout template v3 live, see log") and keep the detail, owner and before/after in your own log. Our GA4 annotations guide covers the setup in more depth.

How do I use the log to find what caused a traffic or conversion change?

Start from the date the metric moved and list every change from the days before it, from all sources, on one timeline. Then rule out tracking, check external causes, and test one hypothesis at a time.

1. Pin the date. Find the first day the metric left its normal range, and check whether the shift is site-wide or limited to some pages, devices, countries or channels.
2. Pull every change from the prior 7–14 days. Website entries, tag and GTM publishes, ad account edits, CRM or form changes. A site release and a bid strategy change in the same week are both suspects until one is ruled out.
3. Rule out tracking first. If reported conversions fell but orders or CRM leads did not, the cause is in measurement, often a tag, form or consent change. See our post on GTM version history for dating tag changes.
4. Check external causes. Google's guide to debugging Search traffic drops lists algorithmic updates, technical issues, security issues, spam issues, changes in search interest and site moves. Compare with the last 16 months in the Performance report to spot seasonal patterns.
5. Match scope to scope. A drop limited to /blog/ pages points at a change that touched /blog/. A change to the checkout cannot explain lower organic impressions.
6. Test one hypothesis. Revert or adjust one change, or compare affected and unaffected page groups, and watch the metric over a fair window.

Allow for delay: Google notes that after a site move with URL changes, a medium-sized site can take a few weeks for most pages to move, and visibility can fluctuate meanwhile. So look further back than yesterday when the suspect is a migration. For organic-specific diagnosis, see why did my organic traffic drop.

With site releases, GTM publishes and ad account edits on one timeline, a drop that only hits product pages lines up straight away with the template release that touched those pages. Start a free change log in Changeline and keep website and ad changes in one place.

Example: tracing a drop to a template release

This is an illustrative example, not a real client. An online store sees organic sessions to product pages fall about 20% week over week, while the blog is stable.

• Timeline for the prior 14 days: a product page template release (Tuesday), a GTM publish adding a new event (Wednesday), a Google Ads budget increase (Thursday).
• Tracking check: Search Console clicks fell too, not only GA4 sessions, so this is not a tag problem. The GTM publish is ruled out.
• Scope check: only product pages dropped, the same pages the template touched. The Ads budget change cannot reduce organic clicks.
• Detail from the log: the before/after entry shows the release replaced the product description block with a tab that loads on click.
• Test: the team restores the description in the initial HTML on half of the categories and compares both groups over the next weeks.

Without the log, the team would have started with a guess, probably the most recent or most visible change.

How do I keep website changes and ad changes on one timeline?

Put all lanes in one place, because the question is rarely "what changed on the site" alone; it is "what changed anywhere before this metric moved".

In Changeline you log website, tracking and CRM changes per project with date, owner, tags and reason, and Google Ads changes can be imported automatically through a read-only connection, with before → after values. Website and other integrations are not available yet, so site changes are logged by the team. Entries are kept for as long as the project exists, which makes it easy to check what changed in the same weeks last year.

Whatever tool you use, review the log in your monthly report: list the site changes of the period next to the metrics they were meant to move, and note which ones worked.