A pruning rule put my renamed page in noindex: it measured the new URL, the history was on the old one

Two weeks ago I renamed 42 article URLs on a small VPN review site. An affiliate network's brand rules forbid using the partner's trademark in a URL, and several of our slugs did exactly that. So /en/blog/best-nordvpn-alternatives-2026 became /en/blog/best-vpn-alternatives-2026, with a permanent redirect from the old path, and every internal link was rewritten to the new one. Textbook migration.

Six days later, a separate cleanup job put the new URL in noindex. Nobody noticed for another six days. Here is how two correct jobs combined into one wrong result, and the check that would have caught it.

The pruning rule was reasonable

The site had too many thin pages. Google was crawling hundreds of URLs that never earned an impression. So the cleanup rule was simple: a page published before a cutoff date, with fewer than 12 impressions and zero clicks over 120 days in Search Console, goes to noindex, follow, leaves the sitemap, and is listed in a reversible JSON file.

293 URLs matched. Together they held 0.3 % of the site's impressions and 47 % of its sitemap. On paper, a clean cut.

The rule read the wrong key

Search Console reports performance by URL. The demand for "nordvpn alternatives" had been built over months on the old path. After the rename, Google kept showing the old URL in results, because it had not recrawled it yet and had never seen the redirect.

So when the pruning job asked "how many impressions did /en/blog/best-vpn-alternatives-2026 get in 120 days?", the honest answer was: almost none. The page was six days old in Google's eyes. The history lived on another key.

The page it removed had 7,836 impressions over 130 days at an average position of 10.8, all recorded on the old URL.

What the damage looked like

From Search Console, for the query "nordvpn alternatives":

And the URL Inspection API, on 30 October:

• Old URL: "Submitted and indexed", last crawl 1 October. Google still had not seen the redirect.
• New URL: "Discovered, currently not indexed", never crawled. It had spent its first days in noindex.

The redirect was correct, the canonical was correct, the page was in the sitemap and linked from 11 articles. None of that mattered while the page told crawlers not to index it.

The fix, and what it cannot undo

The 7 renamed URLs caught by the rule were taken out of the noindex list, the sitemap was resubmitted, and the URLs were pushed through IndexNow and the Bing Webmaster URL submission API. That restores eligibility. It does not restore the position: the new URL now has to be crawled, then earn back what the old one had.

The check I should have had

Any rule that judges a page by its own history needs to know that page's previous names. In practice:

1. Keep the redirect map as data, not only as server config. We had 53 redirects in a config file the pruning job never read.
2. Sum metrics over the URL and every path that redirects to it before applying a threshold.
3. Exclude any URL younger than one full measurement window from automatic pruning. A 120-day rule should not judge a 6-day-old URL at all.

The third point is the cheapest and would have been enough on its own.

The general pattern

Two jobs, each correct against its own spec: the migration preserved users and links, the pruning removed dead weight. The failure was in the join: one job created a new identity for an asset, the other measured the asset by identity. If your tooling has a "rename" step and a "measure" step, check that the measure step knows about renames.

If you want to see the page this happened to, it is the VPN alternatives comparison on the site. I will post the recovery numbers once Google has recrawled it.