Connect GitHub to Google Search Console

Each system alone answers half the question

Your deploy history is a list of changes with no outcomes. Your Search Console data is a list of outcomes with no causes. When average position moves three weeks after a refactor, neither system can connect the two on its own — and on a site that ships code every week, a deploy is very often the cause.

The gap is where SEO regressions hide. A PR removes a component, a template drops its internal links, and nobody notices until traffic is already down. We've written about how to detect an SEO regression caused by a deploy — the short version is that you need both timelines in one place before you can do any of it.

Two permissions and about five minutes

• A GitHub repository you can install a GitHub App on

  Code Results connects through a GitHub App install, so you need admin rights on the repo or org — or an admin willing to approve the install. You choose which repositories it can see.

• Access to the Search Console property

  You'll sign in with the Google account that has access to the property — the connection needs read access to your Search Console data, nothing more.

That's it. No tracking snippet, no code change, no deploy hook to wire up. The free tier covers the whole setup.

Four steps, in order

• 1. Sign up — free

  Create an account on the free tier.

• 2. Connect GitHub

  Install the GitHub App and choose the repositories that ship your site. Code Results reads your merged PRs and deploy timeline from there.

• 3. Connect Search Console

  Sign in with Google and pick the property that matches the site those repositories serve. The connection asks for read access to your Search Console data.

• 4. Let the dashboard backfill

  Code Results pulls your historical search metrics and annotates them with your deploy timeline. From then on, every merged PR shows up against clicks, impressions, CTR, and average position.

One honest caveat on timing: Google doesn't react to a deploy the day it ships. Crawl-and-index lag runs days to weeks, and the analysis accounts for that — here's how long Google takes to notice code changes.

Once connected, three things start working

First, deploy-annotated search reporting — your Search Console metrics with the ship dates drawn on them, so "what changed around then" stops being an archaeology project.

Second, continuous changepoint monitoring. Code Results watches clicks, impressions, CTR, and average position for statistical shifts — not day-to-day noise, actual changes in the trend.

Third, attribution. Each changepoint is lined up against the deploy timeline, allowing for crawl lag, and attributed to the pull requests most likely to have caused it — with a confidence score and a counterfactual baseline showing what the trend would have done without the change. A worked example: changepoint June 12, average position 19.4 → 11.1, attributed to 3 PRs at 91% confidence. How attribution works covers the mechanics.

Questions people ask before connecting

• Does it write to my repo or my Search Console?

  No. It reads. It does not modify your code, open PRs, or change any search settings.

• What if we deploy without merging PRs?

  Attribution keys off what ships to your default branch. If most of your changes land there through PRs, attribution works well. If you push straight to the default branch routinely, you'll still get changepoints, but the per-PR attribution has less to work with.

• How far back does the data go?

  As far back as Search Console keeps it. Code Results backfills what Google exposes for your property — its own retention limits apply, and we can't recover data Google no longer holds. Connect earlier rather than later.