Rank Movement and Your Deploy Log

The question “what changed?” is asked at the end of most ranking investigations, after the position data has been exhausted. It’s answerable in about a minute if someone has been writing down what shipped. It’s often unanswerable weeks later if nobody has.

This is the cheapest improvement available to a rank-tracking setup, and it isn’t a tracker feature. It’s a list of dates and changes, kept somewhere you’ll find it.

What the log needs to contain

Not your git history — that’s too granular to read against a weekly chart. What you want is a short entry per change that could plausibly affect search, with the date it went live rather than the date it was merged:

• Template and layout changes. A new header, a changed nav, a removed sidebar. These affect many pages at once and are the most common cause of correlated movement across a keyword set.
• Content changes on tracked pages. Rewrites, retitling, expansions, consolidations, deletions.
• URL changes and redirects. Anything that changed an address, plus what it now points at.
• Directive changes. noindex, canonical tags, robots rules. Small diffs, large effects.
• Internal linking changes. A new hub page, a removed link block, a changed footer.
• Infrastructure changes. A CDN or host migration, a new caching layer, an edge rule.
• Non-engineering changes too. A press release, a campaign launch, a pricing change, a product rename. These move brand and category demand, which shows up in position data without any deploy involved.

Two fields make or break the log: the date it was live in production, and which URLs it touched. Without the second, you can’t tell whether a change should have affected the keyword you’re looking at.

Reading the two together

The combination lets you rule things out quickly, which is most of what diagnosis is.

A cliff on the same date as a deploy that touched those URLs. Strong candidate. Not proof, but you now have one hypothesis instead of ten. Cliff, Slide, or Step covers why a cliff is the shape that has a date at all.

A cliff on a date with no deploy. Now you’re looking outward: a ranking system update, a competitor change, or a change in the result page’s composition. The absence of a deploy is genuinely informative and you can only have it if the log is complete.

A slide with deploys scattered through it. Almost certainly unrelated. Slides don’t have single causes, and matching one to a deploy in the middle of it is how people arrive at confident wrong answers.

Movement across many keywords on one date, with a template deploy on it. The strongest inference the pairing supports, because the correlation is across the set rather than on one keyword. Compare with Sitewide Drops Versus Page-Level Drops.

Recovery after a fix, lining up with the fix date. Weak evidence individually, better across several instances. The realistic expectations are in What Recovery Looks Like After a Fix.

Two things the pairing cannot do

Be honest about the limits, because the log makes it very easy to overclaim.

It doesn’t establish causation. A deploy and a drop on the same day is a coincidence you now know about. Other things happened that day too, including things at the search engine you have no visibility into. Ranking Changes Are Not an Experiment covers why the standard experimental logic isn’t available here: no control group, no isolation, one timeline.

It doesn’t fix the lag. A change has to be crawled and processed before it can affect anything, and that delay varies by page and site. So the date a deploy went out and the date its effect appears are not the same date, and the gap isn’t a fixed number you can subtract. This is why a strict same-day match isn’t the standard — a window is, and the window’s width is a judgement call.

Both limits argue for using the log to narrow candidates rather than to select a winner.

Keeping it in practice

The failure mode is not that people disagree with this; it’s that the log stops being updated in week three.

Put it where the work happens. A file in the repo that a release checklist requires touching, or an entry in whatever release notes already exist. A separate document nobody owns will die.

Make it a line, not a report. Date, one sentence, URL pattern affected. If it takes more than fifteen seconds it won’t survive a busy week.

Use your tracker’s annotations if it has them. Some trackers let you mark events directly on the chart, which puts the two datasets in one view and is worth the setup time.

Include things engineering doesn’t consider a deploy. Content edits made in a CMS, a campaign going live, a competitor’s launch you noticed. These are the entries that most often explain movement, and they never appear in a release pipeline.

Record the date it was live, not merged, and note it explicitly when the two differ by more than a day.

What to actually do

1. Start the log today, empty. Its value is entirely prospective; you cannot backfill what nobody wrote down.
2. Add three fields per entry: live date, one-line description, URLs affected.
3. Include non-engineering changes — content, campaigns, pricing, naming.
4. When a drop appears, read the shape first, then check the log for the window around it rather than the exact day.
5. Treat a match as a candidate, not a conclusion, and check whether the keywords affected are the ones whose URLs were touched.
6. Treat no match as information too. It’s what points you at causes outside your site, and it’s the half of the value most people never get, because their log has holes.

The general diagnostic order is in How to Diagnose a Ranking Drop. The deploy log is what turns its middle steps from guesswork into lookups.