A refreshed article gets more clicks the following week. That is encouraging, but it leaves two questions: did the intended change reach readers and search engines, and is the performance comparison fair?
I separate those checks. A working release, an observed crawl, a change in search performance and a useful business outcome are different pieces of evidence. Keeping them separate makes it easier to explain what improved, what remains uncertain and what to do next.
Write the hypothesis before the edit
I want a sentence that connects the reader’s problem with the proposed change. For example: “This guide does not explain how to choose between the two common options, so I will add a clear comparison and check whether relevant searches and enquiries improve.”
That is more useful than “optimise the article”. It defines something I can inspect in the page and something I can measure afterwards. I record what should stay, too: useful explanations, links, accessible formatting and information that existing visitors still need.
If I have not established the problem, I start with the content-decay diagnostic guide. A measurement plan cannot make an unsupported content decision sound.
Save the baseline before changing anything
I save the earlier report with its exact dates, filters, collection time and URL scope. The baseline includes absolute counts, not just percentages, and any missing or provisional measurements.
I also keep a copy of the page and a brief change log. That might include the title, main answer, useful links, canonical and indexing intention. If several URLs are being combined, I record the mapping and check what information each original page contributes.
I choose a primary measure that fits the purpose: relevant search visits, qualified enquiries or another useful action. Supporting measures help explain it. More appearances for unrelated searches would not, by itself, fulfil a brief to help the right people choose a service.
Choose the follow-up window in advance
I decide when the comparison will be worth making before I see the results. The window needs enough complete data for this site, a comparable stage of demand and time for the change to be discovered. A quiet specialist page needs a different approach from a busy, time-sensitive article.
Google’s Performance data guidance explains that recent data can be preliminary and change. I check the report’s completeness rather than adopting a blanket rule that the latest two days are always usable or always missing.
I write down what would count as a useful improvement, what would be inconclusive and what would trigger another investigation. I can review technical delivery immediately, but I do not choose an unusually good traffic week afterwards and present it as the original test window.
First prove that the change is actually being served
After publication, I check the normal URL from a fresh browser and a phone-sized view. I inspect the important answer, links, status, canonical and indexing intention. Where caching is involved, I verify the public version rather than relying only on the editor preview.
For a redirected page, I follow the old URL through to the destination. The right status is useful, but so is an answer that makes sense to somebody who expected the original page. I also check that internal links now use the intended destination.
This is the first checkpoint in the change log: the content is correctly served. It does not yet establish that Google has processed it or that the page will perform better.
Keep live tests and indexed evidence separate
Search Console’s URL Inspection documentation distinguishes the indexed view from a live test. The indexed information relates to Google’s recorded version; the live test examines the current page. Passing a live test does not guarantee indexing.
I record what I actually observed and when. “The live page contains the new comparison” and “the inspected indexed version reflects the update” are more useful notes than an undated tick marked “Google checked”. If the evidence does not establish that yet, I leave it open.
I do not keep requesting indexing as a way to accelerate the measurement window. Google’s recrawl guidance says repeated requests do not make crawling happen faster, and a request does not guarantee inclusion.
Use a comparison that fits the change
I rerun the same page scope, search type, country and device filters over complete comparable periods. I check the important query groups as well as the total, because a different mix of searches can move an average without improving the audience I intended to help.
When the topic is seasonal, I add the same stage of the previous event or season. My seasonal comparison guide explains how to make that date choice explicit. A rise during a predictable demand peak is useful traffic, but it is not all evidence for the edit.
Where possible, I also choose a small group of similar, unchanged pages before the review. They need comparable audiences and demand, not simply URLs in the same folder. I record other releases, campaigns, tracking changes and search-market events that could affect either group.
A fictional before-and-after result
This example is invented; it is not an experiment or client result. Suppose an updated guide rises from 200 to 240 relevant search clicks across two matched complete periods: a 20% increase. A selected group of unchanged pages rises by 18% over the same dates.
I would report both movements. The updated page improved, but the comparison suggests that wider demand or another shared influence could explain much of the rise. I would not subtract the two percentages and announce a precisely measured “2% SEO lift”. The groups are not randomly assigned, and their audiences may differ.
Now suppose the new comparison section also receives useful enquiries and the intended queries show a sustained improvement across later reviews. That would strengthen the case that the work helped. I would still describe the evidence and its limits, rather than claim that the edit caused every additional visit or enquiry.
A fall deserves the same discipline. I check delivery, demand, query mix and measurement before deciding that the new answer was wrong. If the update has made the page misleading or broken an important journey, I correct that promptly instead of waiting for a traffic verdict.
Keep a readable change record
I use a record that somebody else can understand without reopening the whole investigation:
- Problem and hypothesis: the reader’s need, proposed change and intended outcome.
- Baseline: exact report scope, dates, completeness and saved page evidence.
- Delivery: publication time, changed URLs, checks and recovery route.
- Search evidence: what inspection or crawl information actually showed, with dates.
- Follow-up: the agreed period, primary measure, comparison pages and other relevant changes.
- Decision: keep the change, improve it, investigate further or restore something, with a reason and owner.
The blank review worksheet provides a starting structure. I save successive assessments rather than overwriting the earlier evidence.
I also keep publication and update dates honest. Google’s date guidance calls for visible and structured dates that describe the page’s actual publication or significant update. A measurement review alone is not a reason to make an unchanged article look newly written.
If you need help connecting the content work with reliable checks, I provide SEO review and implementation. I want the report to explain what happened and support the next decision, not just turn the chart green.