The recovery that wasn't

Through March the site held about 550 to 670 impressions a week. The March core update rolled out March 27 to April 8, and the property fell apart right as the rollout completed: 327 impressions the week of April 6, then 31 the week of April 13, then near zero through May. The May core update ran May 21 to June 2, and the week of June 15 the property printed 661 impressions and settled back at its old ceiling of roughly 700 a week. On the property-level graph, that is the cleanest update story you will ever see: cored in the spring, forgiven in the summer.

There was a third flattering story on offer too. We had shipped a trust and redesign pass on June 17 and 18, so for a moment the recovery looked like our own good work paying off within days. The curve does not support that either: it turned the week of June 15, just before those deploys went out. Causation unclear at best, and "unclear at best" is not a result you get to publish as a win.

1. Property level against page level

The property-level graph rolls every URL the domain has ever ranked into one line, and one line can only tell one story. The page-level report told two. The URLs that lost their impressions in March were the old site's pages: a thin, flat architecture that the March core had assessed and dropped. The URLs earning the June impressions were a different set that had not existed in March, because in the near-zero months the site had been rebuilt and re-architected into topic clusters. Same property, two different sites. A death and a birth, drawn on one line, reads as a recovery.

2. The URL form changed underneath the graph

The rebuild also moved the site from www to the bare domain. A domain property in Search Console absorbs that change silently: both hostnames report into the same line, so the graph never announces that the thing being measured was swapped. Sorting the page-level rows by URL form made it unmissable. The dying rows were www URLs; the rising rows were not. Google was not re-scoring the pages that fell. It was indexing new ones.

3. Impressions returned to exactly the old ceiling

Roughly 700 impressions a week is where the old site topped out, and roughly 700 a week is where the "recovered" site settled. An algorithm rewarding a genuinely better site has no reason to reproduce your old number; reindexed demand for the same queries does. And the scale stayed micro: on the pull we ran, about 20 clicks over 90 days, average position around 19, with 63% of queries sitting at position 41 or worse. That is not what winning looks like. That is the same site-shaped hole in the results, refilled.

Before you credit or blame an update, write down every change you shipped in the window: host or URL-form moves, redirects, re-architectures, template rebuilds, mass content changes. Migrations and rebuilds mimic update recoveries almost perfectly. Traffic dies, a gap follows while the new structure is crawled, then impressions return in a step. If a confirmed update window happens to overlap the gap, the calendar will happily take the credit, in either direction.

We had three explanations available and spent weeks holding the two flattering ones: cored in March, rewarded in June, possibly helped along by our own deploys. The boring truth required nothing but an afternoon in the page-level report. The site that died was not the site that came back, and the site that came back earned exactly what the old one had. The real growth problem, rankings stuck deep on page four and a need for links and authority, was untouched by the whole episode, which is precisely why getting the diagnosis right mattered: a team that believes it just won an algorithmic recovery stops doing the work that was actually missing.