What Recovery Looks Like After You Fix Something

A fix lands instantly and a position does not. Between the deploy and the number on your chart there are steps you don’t control: the page has to be recrawled, the change has to be reprocessed, and whatever reconsiders that query has to run. The drop was often a cliff on one day. The return is usually a staggered, partial slope over weeks, and it frequently stops somewhere short of where you were.

Knowing that shape in advance is what stops the second mistake, which is changing something else on day three.

Three stages, one of which is yours

The fix is live. The only stage you own. Verify it as a crawler sees it, not as your browser sees it — a change that is correct for a logged-in editor and absent for an anonymous fetch is a common way to spend a month waiting for nothing.

The change is crawled. Recrawl intervals vary by URL and by site, and the URLs you care about are not necessarily the ones that get crawled soonest. You can request attention for a handful of URLs; you cannot schedule a template rollout across thousands.

The change is reflected. Being crawled is not being reprocessed, and being reprocessed is not being reordered against the current competing set. This is the stage with no observable progress bar at all.

Because the stages are sequential and each has its own latency, the interval between the fix and any visible movement is genuinely unpredictable — and no figure anyone quotes for it is measured on your site.

What a real recovery looks like

Staggered by URL. If the fix was site-wide, expect the fastest-crawled pages to return first and the deep ones to lag by weeks. A recovery chart that moves as one block is more likely a numbering or configuration change than a ranking one.

Partial. The ordering carried on without you. Someone who gained your slot may have improved the page while holding it, and returning to the same number is not the default outcome.

Not to the same baseline. If the outage was long enough for the query’s result set to change composition, the old baseline describes a page that no longer exists. Re-establish it rather than treating the old median as the recovery target — you can’t read a position without a baseline.

Occasionally noisy on the way up. A few days of overshoot and settling is normal and is not a signal about anything.

Set the read date before you start waiting

The failure mode is not impatience, it is un-instrumented impatience. Before the fix ships, write down three things: the date the fix went live, the keywords and URLs you expect to move, and the date you will judge it. Then hold the rest of the site still on those URLs until that date.

If you change something else in week two, you have permanently lost the ability to say which change did what. Both changes will be credited to whichever result you prefer, which is how a team acquires a technique it never verified — ranking changes are not an experiment.

Pick the read date from the keyword’s own cadence: a term you check daily and that normally wanders by a couple of places needs a longer window than its noise floor, not a longer window than your patience — how often should you check keyword rankings.

When it doesn’t come back

Four possibilities, in the order worth checking:

1. The fix wasn’t the cause. The most common one. The original diagnosis promoted a plausible candidate to a conclusion — how to diagnose a ranking drop.
2. The fix isn’t actually live for an anonymous request, or is live on a different URL than the one that ranks.
3. The slot is genuinely gone. A competitor took it with a better page, or the query’s intent moved and your page no longer matches it.
4. The recovery is real and not yet observable. Nothing distinguishes this from the others except time, which is precisely why the read date matters.

Before concluding any of those, confirm the checks actually ran during the wait. A flat line across the recovery window is also what a tracker draws when it failed to collect anything — a flat line in rank history might be a gap.

There is also a fifth state that people misread as failure: the keyword is below your tracker’s search depth, so the series shows nothing while the page climbs from 120 to 105. Absence in a tracker means “not found within the depth we paid for” — when a keyword falls out of the top 100.

Reporting while you wait

Say what is known and what isn’t, and refuse to give a recovery date. “The fix is live and verified, the pages have not all been recrawled, and we will read the result on the 20th” is a complete status. A predicted return date is a guess about someone else’s infrastructure, and offering one converts a technical wait into a missed commitment.

What to actually do

1. Verify the fix as an anonymous crawler, before starting any clock.
2. Record the fix date as an annotation on every affected keyword’s series.
3. Commit to a read date and change nothing else on those URLs until it.
4. Expect staggered, partial returns, and re-baseline instead of aiming at the old number.
5. Report the wait as a wait. No recovery-date estimates.