When rankings move after a website update, the first useful question is not whether the update worked. It is what actually went live, where and when. An approved rewrite, a completed development ticket and a verified change on a public URL can represent different moments. Your ranking review needs the last of those, with enough detail to reconstruct the others.
An SEO change log connects that delivery history to search performance. Keep it in a shared spreadsheet or another record your team already uses. Give each live change a dated entry, identify the affected URLs, preserve the before and after states, and add evidence that the implementation matches the intention.
Our approach connects monitoring with verified delivery evidence. The purpose is to help you decide whether to keep watching, investigate a fault or reverse a change, without treating the nearest deployment date as proof of what caused a ranking movement.
Build the Log Around Live Changes
A task list records work to do. A change log records what happened to the website. Keep those functions distinct, even if both sit in the same system.
“Improve internal links” belongs in a task list. A useful change-log entry identifies the pages where links were added, their destinations, the deployment date and the evidence confirming that those links are present. Someone reviewing performance later should not need to ask the original editor what “improved” meant.
Use one entry for a change you can meaningfully review or reverse. A title rewrite on one URL can stand alone. A navigation update affecting a group of pages should have a shared entry with its scope attached. If a release contains unrelated changes, split them into separate entries and retain a common deployment reference.
This keeps the log manageable without disguising several interventions as one. When a title, main copy and internal links all change together, record that combination honestly. You can assess the release as a whole, but the log cannot isolate the contribution of each element.
Include changes made outside the SEO team when they affect the same pages. A developer’s template update or an editor’s removal of content may be more relevant to a later investigation than the optimisation work everyone remembers.
Record Enough Detail to Reconstruct the Change
Start with a compact set of fields. Each should answer a question you will need during a review:
- Change reference and owner: a stable identifier and the person responsible for checking the implementation.
- Live date and time zone: when the change became publicly available, not simply when someone approved it.
- Affected URLs and scope: exact addresses, or an attached URL list for a wider release.
- Before state and after state: what changed, expressed as specific text, settings or behaviour.
- Reason and expected observation: why the work was undertaken and what you intend to examine afterwards.
- Verification evidence: a dated record showing that the live implementation matches the intended change.
- Baseline and review details: the search data, filters and comparison periods to use.
- Follow-up and rollback: subsequent findings, decisions and any reversal linked to the original entry.
Keep the reason separate from the result. “Clarify the page title to better describe the offer” records an intention. “Title change increased clicks” is a conclusion requiring evidence. If both occupy the same field, an initial expectation can quietly become an accepted explanation.
For a site-wide change, avoid putting “all pages” in the scope field unless that scope has been checked. Identify the template or section involved, attach the intended URL set, and record which pages were inspected. Sampling a template is not the same as verifying every URL.
Use explicit states such as planned, live but unverified, verified and reversed. A completed ticket with no live check should remain distinguishable from a verified deployment.
Preserve Evidence Before the Old Version Disappears
The before state is easiest to capture before publishing. Save the original title, heading, copy or configuration alongside the proposed replacement. For a redirect, record the original URL and intended destination. For an internal-link change, preserve the source URL, destination and anchor text.
Choose evidence that demonstrates the actual change. A screenshot can show visible copy, but it does not establish a redirect response or confirm a robots directive. Those need checks of the relevant response or page code. A deployment record helps establish timing, while a live check establishes what the website now serves.
Record when verification happened as well as when deployment happened. If the team publishes in the morning but only checks the result later, those are separate facts. If the exact live time is unknown, retain that uncertainty rather than assigning the ticket’s completion time to the deployment.
Keep evidence somewhere the reviewer can access. A log entry that points to an inaccessible personal folder leaves the owner dependent on someone else’s memory. Name saved material with the change reference and enough context to distinguish before from after.
Verification also needs a result. “Checked” is less useful than “new title present on the affected URL” or “redirect reaches the intended destination”. The latter tells the next reviewer what the check established and what it did not.
Capture a Baseline You Can Compare Later
Before a planned change, save the relevant Search Console view or export. Record the date range, page and query filters, country, device and search type where applicable. Those settings are part of the evidence, not optional background.
A site-wide average can conceal a local problem. If the work concerns one landing page, begin with that URL and the queries relevant to it. If it concerns a section, retain a view of that group as well as the broader site context. This lets you see whether movement is concentrated around the change or appears elsewhere too.
Keep clicks, impressions and average position together. A fall in clicks is not automatically a ranking loss. Search demand can change, and results can attract different click behaviour even when visibility remains similar. Position helps explain the pattern, but it should not replace the traffic measures.
Choose comparison periods that make sense for the business. Similar periods help avoid confusing different trading patterns with an implementation effect. Where seasonal demand matters, examine the previous year as well as the immediately preceding period.
If the change has already happened, reconstruct the baseline from available historical data. Mark it as reconstructed and note any missing detail. Do not backfill a precise before state from memory just to make the record look complete.
Set a Review Point Without Inventing a Ranking Deadline
There are two different checks after deployment: whether the change is correct and how search performance develops. The first should not wait for the second.
Check implementation promptly. A wrong redirect destination or an unintended indexing restriction is a delivery problem to investigate, not something to leave untouched while collecting ranking data. Record the fault and its correction as part of the same history.
Performance needs a different timetable. Google explains that some changes may take effect within days while others can take months. A fixed promise that every update can be judged after the same interval would ignore the type and scope of the work.
Set a review date as a reminder to examine the evidence, not as a deadline for improvement. At that review, record the comparison period, the observed movement and whether the evidence supports a decision. If it does not, identify what remains unresolved and set the next check.
For a low-traffic page, a short period may offer little useful information. For a broad, persistent decline across important queries, waiting without investigating is a different risk. The review should respond to the pattern and its consequences, not simply to the calendar.
Compare the Pattern, Not Just the Dates
Small fluctuations in position can happen at any time. Google’s search-traffic debugging guide makes this distinction and advises against radical changes to a page that is already performing well because of a small shift.
Start your review by describing the movement before explaining it. Identify which URLs and queries changed, when the movement began, whether it persisted, and what happened to clicks and impressions. Then compare that pattern with the scope and timing of your logged changes.
If the decline started before the deployment, the deployment does not explain its onset. If untouched sections also declined, the investigation needs to extend beyond the edited pages. Neither observation resolves the whole case, but both narrow the questions worth asking.
Keep dated context notes for events that were not your own deployments. Relevant examples include confirmed search updates, website outages, migrations, seasonal demand changes and reporting anomalies. Label these as external events or incidents so they cannot be mistaken for work your team performed.
Check the evidence behind each possible explanation. Search Console’s indexing and crawl information can help investigate technical problems. Query-level comparisons and wider search-interest patterns can help assess demand. A known update occurring nearby is context, not enough on its own to assign a cause.
Write review notes in three parts: observation, interpretation and next action. For example, a hypothetical review might record that clicks fell on the edited URL while impressions remained similar. The interpretation would remain open: inspect query-level position and click behaviour rather than declaring the rewrite unsuccessful. The next action should specify that inspection, with an owner.
Make Rollbacks Part of the History
A rollback is another live change. Preserve the original entry and add a linked reversal with its own date, scope, reason and verification evidence. Overwriting the original before and after fields destroys the sequence you will need later.
Distinguish a confirmed implementation fault from an uncertain performance response. Restoring an accidentally removed section addresses a known error. Reverting a correct edit because a ranking moved slightly is a much less settled decision.
Where several changes went live together, confirm what the rollback will reverse. Restoring an entire template to undo one unwanted element may also remove useful fixes. The log should identify those consequences before the team acts.
After the rollback, verify the resulting live state rather than assuming the old version has been restored exactly. Keep monitoring against the original baseline and note intervening changes. Even a recovery after reversal does not, by itself, isolate a single cause if other conditions changed during the same period.
Keep the Routine Light Enough to Maintain
Assign responsibility at the point of deployment. The person making the change supplies the implementation details; a named reviewer confirms the evidence and maintains the follow-up. A website owner should be able to see both responsibilities without searching through messages.
Use delivery reviews to catch missing entries and unverified changes. Use performance reviews to update observations and decisions. This separates record maintenance from analysis and prevents a ranking drop from becoming the first occasion anyone tries to reconstruct the release history.
Do not turn the log into a diary of every conversation. Keep discussion in the relevant task and retain the decision, evidence and reference in the log. The practical test is whether another person could understand what happened and repeat the review without an oral briefing.
Our SEO Command Centre connects search monitoring with delivery QA and evidence-led action. A maintained change log supports that work by giving page and query movement an implementation history, rather than leaving performance reports disconnected from completed tasks.
Where the history points to unresolved technical or content questions, an SEO audit can investigate crawlability, indexing, on-page content and internal linking, then prioritise the findings. Bring the affected URLs, deployment history and saved comparisons so the investigation starts with the actual sequence.
The practical answer is to keep one shared record that survives both deployment and review. Begin with the next planned change: preserve its before state, record when it becomes live, verify the result and schedule a performance check with defined comparisons. Add observations and reversals without rewriting the past. That gives you a basis for deciding what to investigate or retain, instead of reacting to a ranking chart from memory.
