Five steps
- Crawl the public siterobots.txt obeyed, identified as Rankelle-Audit, rate-limited per host. Page text is hashed and discarded — we keep a content hash and a word count, not the body.
- Group by root cause/blog/how-to-x and /blog/why-y collapse into /blog/*. Coverage is the confidence: 400 of 400 is a template, 6 of 14 is a question.
- Notice when it shipsWatched pages are re-checked on the SEO-relevant fields. When the defect is gone from every URL under the pattern, the cause is marked landed. Landed is not a claim that anything improved.
- Freeze a control setComparable untouched URLs, similar depth and impression volume, chosen at that moment and never recomputed. A moving control is not a control.
- Return a verdictAfter 28 days: worked, no effect, regressed, or inconclusive. Inconclusive is reported as itself, not rounded toward the flattering neighbour.
Grouping
A confidently wrong cause is worse than no cause at all.
Findings are grouped by issue type and URL pattern, where the pattern comes from templating the segments of a path that vary across the crawl. Each group carries a confidence derived from coverage.
Low-confidence causes are phrased as questions everywhere they appear, in the dashboard and in the report both. The catalog behind the crawl records the evidence for each rule and the condition that would make it stale.
The control set
This is the step that separates a ledger from a report.
At the moment a fix lands we freeze a set of URLs comparable to the affected ones but untouched by the change: similar depth, similar impression volume in the 28 days before landing, indexable, returning 200s.
Both sets are then measured over the same trailing 28-day window. If Google had a good month for the whole site, both sets rise and the fix gets no credit for it.
Where this can be wrong: a small site may have no adequate control set, and we mark the fix as having none rather than quietly scoring it anyway. A sitewide change affects its own control by definition, and those fixes are flagged as having no clean comparison instead of being handed a verdict they have not earned.
The verdict
Nothing is decided before the window closes.
Look on day nine and you see the movement so far, labelled as such. A number on a screen with no hedge beside it is a decision, and you will read it as one.
Once the window closes, the treatment set’s movement is compared against the control set’s. Inconclusive is a real and frequent outcome rather than a failure of the system.
Questions
Why 28 days and not a week?
Search Console data settles over days, weekday seasonality needs whole weeks, and Google takes time to recrawl and reprocess a change. A week-long window mostly measures noise.
What if the client ships three fixes in the same week?
Each fix has its own affected set and its own control set. Where two fixes touch overlapping URLs the attribution is genuinely ambiguous, and the ledger says inconclusive rather than splitting credit by a formula nobody can defend.
Does a Google core update ruin the measurement?
It is close to the reason the control set exists. A core update moves the control and the treatment together, so the comparison survives it far better than a before-and-after chart does.
Does the same method apply to AI visibility?
Not yet, and that is deliberate. These thresholds were derived for Search Console's daily aggregates, and answer engines vary in a way that data does not. Visibility is reported as a measurement rather than as a verdict until its own week-to-week variance is known.
Try it on your own site, free
No card, and the free tier does not expire — the first verdict takes about six weeks to arrive.