How SEO attribution works

Two timelines, one question

Everything starts from two data sources. The first is Google Search Console: daily clicks, impressions, CTR, and average position for your property. The second is your GitHub repository: every merged pull request and deploy, timestamped. Once you connect GitHub to Search Console, both timelines sit on the same axis.

That alignment is the whole premise. Search data alone tells you something moved. The deploy log alone tells you something shipped. Attribution is the discipline of relating the two without fooling yourself.

Trajectory shifts, not threshold alerts

A threshold alert fires when a metric crosses a line. On Search Console data, that is a recipe for noise. Clicks swing with day-of-week cycles — a Saturday dip is not a regression. The most recent days of GSC data arrive incomplete and get revised. And the query mix drifts constantly: a burst of low-intent impressions can drag CTR down while nothing on your site changed.

Changepoint detection asks a harder question: did the underlying trajectory of the series shift? One bad Tuesday does not qualify, and neither does a still-settling recent day. A sustained break from the established pattern does. This is the same reason continuous SEO monitoring beats eyeballing a dashboard once a week.

The cause shipped before the shift

The naive move is to blame whatever deployed the day the metric moved. That is almost always wrong. Google has to recrawl the changed pages, reprocess them, and re-evaluate rankings — a lag that runs from days to weeks depending on crawl frequency and how much of the site the change touched.

So for each detected changepoint, Code Results builds a candidate window that reaches back before the shift, and considers every PR and deploy inside it. A changepoint on June 12 does not implicate the June 12 deploy. It implicates the set of changes Google plausibly digested by June 12 — which may have merged in late May.

The effect is the gap against the forecast

Measuring an effect requires knowing what would have happened without the change. Code Results fits a counterfactual forecast — the trajectory the metric was on before the changepoint, projected forward. The effect is the gap between that baseline and what actually happened. Not "position improved," but "position improved relative to where the pre-change trajectory says it would have been."

Then attribution is scored, not asserted — a confidence number rides on every result instead of an implied certainty. A result reads like this: changepoint June 12 · average position 19.4 → 11.1 · attributed to 3 PRs · 91% confidence. The same machinery works in the other direction — it is how you catch an SEO regression a deploy caused before it compounds.

What this can and can't tell you

Attribution is probabilistic evidence, not proof. Three limits are worth stating plainly.

• Gradual drifts are harder

  Changepoint detection finds breaks in trajectory. A slow six-month erosion with no distinct break gives the model much less to anchor on — the candidate window becomes everything, and everything explains nothing well.

• Confounds exist

  Algorithm updates, seasonality, a competitor shipping something better — all of these move the same metrics your code moves. This is exactly why confidence is a score and not a yes. A 91% is strong evidence. It is not 100%, and we will not pretend otherwise.

• This is not a controlled experiment

  Observational attribution cannot randomize. When your site is large enough to split pages into test and control groups, a real SEO A/B test gives you causal evidence attribution cannot match. Most sites shipping weekly are not in that position — attribution is the strongest evidence available to them.

If you are weighing this approach against split-testing platforms or rank trackers, the SEO testing tools comparison lays out when each category is the right choice.