Tomasz.NEditor
Search and analytics data are easier to interpret when a team knows what changed on the website and when. A lightweight change register provides that context without requiring every minor edit to become a formal project event. Its purpose is to make the history of meaningful changes visible to the people responsible for interpreting performance, maintaining content and testing releases. A small UK agency can use one controlled register across editorial and technical projects, provided the entries identify what actually happened rather than what somebody intended to do. A deployment date, a decision date and a public verification date may be three different events, and none should be silently substituted for another.
Record changes likely to affect interpretation
Include migrations, template releases, major content updates, navigation changes, tracking changes and other material events. Routine spelling corrections usually do not need a permanent entry unless they form part of a larger release.
Use a practical inclusion test: would an analyst investigating a changed customer journey, indexing state or reported performance need to know that this event happened? A global canonical change probably passes. So does a website redesign, a replacement of an important form, a new service-area policy or a large article consolidation. A correction to punctuation on an unrelated page may not. The purpose is a dependable timeline rather than a detailed account of every keystroke. Keep routine content editing in its normal revision history and link significant entries when they affect the wider site.
Distinguish technical and editorial changes without pretending they operate independently. A rewritten service page might change the offer's meaning, while a developer's template update might hide its carefully approved text. The register can describe both changes and their dependencies. Keep affected URLs, relevant page types and owner clear. A small set of useful categories is better than dozens of highly specific labels which no one applies consistently.
Describe what changed in plain language
Note the affected area and the nature of the change without relying entirely on technical ticket numbers. Future analysts should be able to understand the event even if they do not have access to the original development system.
Write one sentence about the before and after state: ‘The navigation previously linked to the old audit page; it now links directly to the approved service destination.’ Another entry might explain that a shared component began adding a canonical URL to a certain class of public article. Explain the reason where it matters, but do not turn the register into a duplicate of the engineering specification. Link to the ticket, code change or approved content decision for someone who needs the detail.
Avoid jargon without definitions. A future account manager might not know an internal sprint label or the meaning of a proprietary issue code. Include the actual site hostname or group and whether this was a production deployment, a staging experiment or merely an approved proposal. The same change description means very different things depending on environment. Describe affected pages as observed rather than asserting sitewide scope from one test URL.
Separate deployment dates from decision dates
Performance context depends on when a change reached the relevant environment, not merely when it was approved. Record the effective release timing as accurately as the team can verify.
Useful fields include the date a business decision was approved, the date the implementation occurred, and the date public acceptance was observed. If the deployment time is unknown, do not reconstruct it confidently from a later dashboard screenshot. A record can say that a release was reported on one date and verified on another, with the true effective time still uncertain. Preserve a consistent timezone when exact times matter. For projects crossing several regions, an ambiguous time such as 09:00 without an offset can mislead future incident reviews.
Also distinguish a gradual rollout from one universal switch. A CDN, regional deployment or feature flag may expose different versions temporarily. A content field saved to a Production database could remain invisible until a frontend cache updates. When identifying an event in Search Console, the reporting time window and Google's processing do not necessarily align exactly with the release. Record what was actually checked rather than converting the date of a CMS edit into an asserted global website cutover.
Link to deeper documentation where useful
A migration may have a redirect map or a redesign may have release notes. Reference those records rather than duplicating them. The change register should remain a navigable timeline, not a complete archive of implementation detail.
For a URL migration, link the approved mapping and the verification results. Google's site-move guidance describes collecting old URLs, preparing redirects and checking the resulting site; it does not demonstrate that a particular client's migration succeeded. The change-register entry can identify the release and affected group while the mapping document lists individual paths and successors. Keep that separation so a correction to one redirect can be recorded without copying a large spreadsheet into every monthly report.
For an editorial change, link the approved brief, reviewed sources or content inventory where appropriate. If a page acquired a new factual service condition, record who approved that claim and when. If its H1 or canonical purpose changed materially, describe the reader-facing consequence. Avoid placing confidential comments, passwords or raw customer enquiries into a broadly shared log. A pointer to restricted evidence is preferable when the detail is sensitive.
Use the register to investigate, not prove causation
A performance movement occurring after a website change is a reason to investigate, not automatic evidence that the change caused it. The register provides hypotheses and context; analysis still needs to consider other plausible factors.
For example, a drop in impressions following a redesign warrants checks on public response codes, important URLs, navigation and indexability. But demand, competitor content and changes in search-result presentation may also be involved. Google's traffic-drop debugging guidance encourages examining different types of decline and possible explanations. A dated release note lets the analyst form a testable hypothesis; it is not a controlled experiment.
Use suitable page groups and time windows when assessing the connection. A navigation change affecting a small category cannot automatically explain movements across unrelated articles. A tracking deployment might change reported analytics events without altering actual visitor behaviour. Keep Search Console clicks and impressions separate from customer enquiries and sales. Do not claim that the register itself proves commercial return or a ranking gain. An honest entry should make further investigation easier, even when the original belief turns out to be wrong.
Make updating the register part of release closure
Assign responsibility for recording material changes when work is completed. A register reconstructed months later from memory is far less useful. The habit should be small enough to survive normal agency workloads.
Identify one person responsible for the change register and a handoff from editorial, engineering and operations when relevant work is delivered. A release checklist can ask whether the event crosses the agreed materiality threshold and whether the register has a complete entry. This takes little time if the required fields are concise: event, affected scope, approved owner, deployment status, known verification and supporting reference. Do not require a formal meeting for every minor update.
Review the timeline during monthly client reporting and major technical incidents. Missing entries should be recorded as gaps rather than rewritten from memory to create a false appearance of completeness. If an old entry was inaccurate, add a dated correction with the observed reason. Preserve enough history to explain what future colleagues saw at the time. Good governance does not require pretending no mistakes were made.
Coordinate the register with the decision log
A client decision log records why a consequential option was selected. The change register records when an approved change was implemented and what became publicly observable. They may refer to the same project, but they answer distinct questions. A decision to merge overlapping articles does not establish that their old URLs were redirected. A developer's deployment report does not establish that the merger preserved important explanations. Link the documents where necessary without copying all their content.
The distinction also clarifies responsibility. Business owners approve actual service descriptions; technical owners deploy appropriate routing or template changes; publishing reviewers accept the public result. One person can play several roles in a small team, but the underlying evidence still differs. A verified production database read-back is evidence of field persistence, not proof that browser rendering, media loading or keyboard navigation succeeded. Record these as separate states.
Include failures and rollback events
The most useful timeline includes changes that did not go as planned. If a release had to be rolled back, state the affected area, observed problem, rollback date and remaining uncertainty. A report that includes only successful deployments can make a later traffic investigation misleading. Do not invent a root cause before the relevant engineer has established it.
For a redirect error, a rollback might restore old paths while an improved map is reviewed. For a tracking problem, a corrected event configuration may change reported counts without representing real additional conversions. Make the effective state clear for each period. If a release was partial, identify which groups were verified and which remained untouched. A short exception record helps clients understand why a planned task moved to another month and protects the next team from repeating the same failure.
Protect the register and keep it useful
A change register can contain internal system names, release links and personnel information. Share it only with authorised stakeholders and avoid duplicating credentials or unnecessarily identifiable user data. The UK ICO data-minimisation guidance supports limiting personal data to what the purpose requires; it does not supply a universal retention schedule for every agency.
Keep the number of mandatory fields small and the writing clear. If the team finds itself managing duplicate timelines in several tools, choose one authoritative log and link out to the underlying records. A useful audit history is maintained routinely because it supports real diagnosis, not because a contract demands an elaborate dashboard. Its most valuable quality is trust: dates, environments, affected pages and acceptance states mean what they say.
A website change register gives context for SEO work and prevents future staff from interpreting the current site without its history. It does not independently establish causality or SEO gains. Used alongside actual public tests and honest reporting, it allows a small agency to investigate changes with more precision and explain its work without exaggeration.