How to tell if your last deploy hurt your SEO
Traffic dipped a few days after you shipped. Now you're staring at a graph trying to decide whether it was your deploy, a Google update, or just the weekend. Here's a diagnostic that actually separates the three — instead of guessing.
Every engineer who owns a site that ranks has had this moment: organic clicks are down, the last thing that changed was your deploy, and nobody can say for sure whether the two are connected. The instinct is to either panic-revert a perfectly good release or shrug and blame "an algorithm update." Both are guesses.
There's a better way to read the evidence. It comes down to looking at the right data, on the right delay, sliced the right way — and knowing which three numbers tell you whether the cause is you or the world.
First: don't look too early
The single most common mistake is checking the day after you deploy. Two separate lags make that meaningless.
Reporting lag. Google Search Console's Performance report is not real-time. Under normal conditions the daily numbers settle a couple of days behind, and during slow periods that stretches to 48–72 hours. The last two or three days on the chart are always provisional and almost always look worse than reality simply because they're not done counting yet. (GSC's newer 24-hour hourly view is fresher, but it's noisier — useful for a pulse check, not for a verdict.)
Ranking lag. Even if a deploy genuinely broke something, Google has to re-crawl and re-process the affected pages before the damage shows up in rankings. That's typically days to a couple of weeks. A real regression often deepens over a week or two as more pages get re-crawled — which means a flat first day tells you nothing either way.
So the honest window for judging a deploy is roughly 3 to 14 days out, reading the settled portion of the curve, not the bleeding edge.
Set up the comparison that controls for the calendar
Raw "clicks went down" is not a signal — organic traffic has a strong weekly rhythm, and most B2B and dev-tool sites lose a third of their traffic every weekend. Comparing Saturday to Wednesday will manufacture a regression that isn't there.
Use Search Console's Compare mode and line up equivalent periods: the 7 days after the deploy against the 7 days before, same days of the week. Now a drop is a drop because the calendar is held constant, not because you straddled a weekend.
Slice by page and query — never trust the sitewide total
A deploy rarely touches your whole site. It touches a template, a route, a component. So a real regression usually lives in a subset of pages while the sitewide aggregate barely moves — which is exactly how teams miss it.
Filter the Performance report to the pages the deploy actually changed. If you shipped a change to your blog template, look at /blog/*. If the aggregate is flat but the pages you touched are down 30%, you've found your regression — and the flat total was hiding it.
The three-number triangulation
Here's the part that turns a vibe into a diagnosis. Search Console gives you three numbers per page or query — impressions, average position, and clicks — and the pattern between them tells you the cause.
- Average position worsens and impressions fall together, on the pages you touched. This is the signature of a real ranking regression. Google is showing your pages for fewer queries, lower down. If the timing lines up with your deploy and the affected pages overlap what the deploy changed, you have your answer.
- Position holds steady but impressions fall. Your rankings didn't move — the demand did. Fewer people searched, or seasonality kicked in. This is not your deploy. Reverting it would fix nothing.
- Impressions and position both hold, but clicks fall. Your ranking is fine; people are seeing you and not clicking. That's a click-through-rate problem — usually a changed
<title>, a lost rich result, or a new SERP feature (an AI overview, a competitor's snippet) eating the click. If your deploy changed titles, meta descriptions, or structured data, this is the one to check.
This is the difference between "we lost rankings" and "fewer people searched this week." The same downward clicks line can mean either, and only the position-and-impressions pattern tells you it was you.
Then confirm it's actually the deploy
A correlation in time isn't proof. Two checks raise it close to certainty:
- Overlap. Are the down pages the same pages the deploy changed? A blog-template change that tanks your pricing page is probably a coincidence (or a Google update); one that tanks your blog posts is probably the deploy.
- Changepoint timing. Does the drop start after the deploy date plus the crawl lag — not before it? A decline that began before you shipped can't be your fault, no matter how tempting the timing feels.
The deploy-level regressions worth ruling out first
When the triangulation says "yes, you," the cause is almost always one of a short, boring list of things a code change can do to a page's crawlability. Check these before you touch rankings strategy:
| Regression | What to look for |
|---|---|
Accidental noindex | A <meta name="robots" content="noindex"> or X-Robots-Tag header shipped on pages that should be indexed |
robots.txt block | A build that disallows a path crawlers need |
| Canonical drift | rel=canonical now pointing at the wrong URL (or a staging domain) |
| URL / slug changes without redirects | Routes renamed, old URLs 404ing instead of 301-ing to the new ones |
| JS rendering regression | Content that now requires client-side JS that Googlebot can't see in the rendered HTML |
| Lost structured data | A refactor that dropped the JSON-LD powering your rich results |
| Broken internal links / 404 spike | A template change orphaning pages or generating dead links |
Most "the deploy hurt our SEO" incidents are one of these, not a subtle ranking-quality shift. Use the URL Inspection tool on an affected page to see exactly what Google now renders and whether it's still indexable.
The hard part is the timeline, not the diagnosis
None of these steps are complicated on their own. What makes deploy-level SEO regressions genuinely hard is that the cause and the effect are separated by a week or more of crawl-and-reporting lag — long enough that by the time the dip is undeniable, you've shipped five more deploys and lost track of which one to blame.
That gap — connecting a ranking change back to the specific pull request that caused it, across the lag — is exactly what Code Results is built to close: it runs changepoint detection on your Search Console history and lines each shift up against the deploys that landed before it, so "did that PR hurt us?" stops being a guess.