A reasonable question with no easy answer
Mid-engagement, a client asks for a full log of everything that was changed, updated or modified on their site. Every change, with dates.
It is a completely reasonable request. It is also one that most teams, agencies and in-house both, cannot answer without a reconstruction exercise. Not because anyone is hiding anything. Because nothing in the normal toolchain produces that list, and nobody noticed that until the day it was asked for.
What usually gets delivered is a summary written after the fact from memory, calendar entries and whatever version names happen to be legible. It is honest work and it is a reconstruction, which is a different kind of document from a record. The gap between those two is what this post is about.
Where the history actually lives, and what each system misses
Change history for a website is scattered across at least four systems, none of which was designed to answer this question.
- The tag manager. It keeps versions, which sounds like a solution. But a version is described by whatever someone typed in the version name box, and under deadline that box gets "fix" or "update" or nothing at all. The auto-generated diff records that a tag was modified. It never records why, and why is the entire content of the question.
- The consent platform. Most CMP admin panels show current configuration. Which categories exist, which vendors are in which category, what the banner says today. Far fewer keep a browsable history of what that configuration was six months ago, which is precisely the period an audit will ask about.
- The CMS. Page revisions exist, usually per page, usually recording who and when and not why. Finding "every change in Q2" means opening every page's revision history one page at a time, and it captures nothing done outside the CMS.
- The vendor's ticket queue. Some changes were made by a platform's support team on request. Those exist in a system you may not have access to, in a format nobody will export, and they are frequently the changes that mattered most.
Each of these systems is good at its own job. None of them was built to answer "what did you do, in order, with dates and reasons." The information is genuinely distributed, and the union of four partial records is not a record.
Three moments that force the question
You do not choose when this comes up. It arrives in one of three ways, and the arrival is always inconvenient.
- Handoff. A relationship ends, or a new lead arrives internally, and someone asks what was actually done. This one is mostly commercial. It is uncomfortable rather than dangerous, and the discomfort is that good work becomes impossible to demonstrate.
- Incident. Something broke. The only question that matters is what changed just before it broke, and the faster it is answered the smaller the damage. Without a log, the incident starts with an archaeology phase, and that phase is where most of the outage time goes.
- Audit. A regulator, a partner, an insurer or a customer's legal team asks what the site was doing on a specific date. This is the hard one, and it is hard for a structural reason worth pulling out separately.
Why the audit version breaks everything
Handoff and incident are questions about recent work. Painful to answer from memory, but memory is at least in the right neighborhood.
An audit asks a question about history. Not what does the site do, but what did the site do on March 14. And every tool listed above answers questions about state, not history. You can demonstrate today's configuration in ten minutes. You cannot demonstrate March's at all, because nothing kept it.
This catches people out because being compliant today feels like it should settle the matter. It does not. A complaint or an enquiry arrives with a date attached, usually the date something was observed by whoever complained, and it is nearly always in the past. Showing that the banner works now says nothing about whether it worked then, and "we believe it was fine" is not evidence. It is a claim about a period you did not record.
The same asymmetry runs through most privacy enforcement we have looked at: the finding is usually about what a site was doing when someone checked, not what it does now. We went through that pattern in Every US Privacy Enforcement Action So Far Comes Down to One Broken Link.
The fix is two records, not one
One record is what you meant to do. The other is what the site actually did. You need both, and the reason is the gap between them.
The written log is created at the moment of change, by the person making it, in plain language. Date, person, what changed, why. It takes under a minute per change and it is the only artifact that captures intent, because intent exists nowhere else. No automated system can reconstruct why a decision was made.
The scheduled scan is independent and automated. It records observed state on a cadence: what tags load, what the consent configuration is, what the banner does, what requests the page makes. It captures things nobody logged, because nobody knew they happened. A vendor's script updating itself. A plugin adding a tracker. A change made by someone outside the process.
Either one alone leaves a hole. A written log with no scanning is a record of intentions, and it silently omits every change nobody intended, which in our experience is a meaningful share of what actually changes on a website. Scanning with no written log tells you the site changed on the eleventh and cannot tell you why, so every historical question turns into an interview.
Together they answer the audit question properly. Here is what we changed and why, and here is independent evidence of what the site was actually doing on that date. That second half is what makes the first half credible, because it comes from a system with no stake in the answer.
The gap between the two is not a failure of the process. It is the most valuable output of it. Every interesting problem in this line of work lives in the distance between what a team believes is deployed and what is actually running, and a hotfix landing more than intended is one common way that distance opens up, as in Your GTM Hotfix Went Into the Default Workspace.
What a log entry needs, and what to leave out
Keep it small enough that people actually do it. Five fields.
- Date. When it went live, not when it was written or approved.
- Person. A name. Not a team, not an agency. Someone who can be asked a follow-up question in a year.
- What changed, in plain language. "Added the Meta pixel to the checkout confirmation page." Not a tag ID, not a version number on its own. Written so a lawyer or a new hire can read it without opening the tool.
- Why. The single most valuable field and the one always skipped. "Requested by paid social to measure purchase events" is a complete answer and takes seconds.
- Where. Which system, which container, which pages. Enough to find it again.
Leave out the automated diff. It is already in the tool, it is unreadable to anyone outside the tool, and pasting it in makes the log longer without making it more useful. Leave out routine content edits unless the site is regulated in a way that makes copy changes material. Leave out anything you are only recording so the log looks thorough. A log people skim and maintain beats a complete one they abandon in six weeks.
Where it lives matters less than that it exists and that it is not inside a system you might lose access to. A shared document works. What does not work is a per-person convention, because the value of the log is that it is one list, in order.
One more thing worth logging that people rarely think of: migrations. When a measurement setup moves from one framework to another, the before state stops existing anywhere and the reasons behind the original build go with it, which is a large part of why the work in the Google tag migration tends to surface questions nobody can answer. And if you are starting the log from nothing, the current-state inventory in the GA4 audit checklist is a reasonable first entry: here is what exists today, verified on this date.
Almost nobody can describe March
Most teams can describe what their website does right now, in detail, with confidence. Almost none can describe what it was doing in March.
Compliance questions are almost always about March. So are incident questions, once the incident is a week old, and so is every handoff conversation that starts with what did we pay for.
The record has to be created at the time. There is no way to add it later, which is the whole problem, and it is why the cheapest minute you will spend this quarter is the one right after you change something.
Scheduled scanning is the independent half of the pair. It records what your site actually did, not what someone meant to change. Managed Privacy keeps that record running, or book a Privacy Audit to find out what your site is doing today.