If your Yandex rank tracker drew dashes across half of October while the same URLs still sat on page one when you checked by hand, you finally have numbers instead of folklore. On 29 October Andrei Kalashnikov published a vc.ru study of 2,699,979 search sessions across 17 proxy pools between 16 and 23 October — the week Yandex was still rerouting after the Sasovo, Kaluga and Vladimir data-centre hits.
The headline ratio is ugly. On the busiest stationary (non-mobile) packs, HTTP 429 errors hit 75–76%. One pack of 414,018 outcomes managed a 4.99% success rate. Mobile operator packs in the same window held roughly 60–68% successful sessions once routing stabilised. That is not a tip about “buy better proxies”. It is a measurement of how Yandex’s balancers behaved when compute was scarce.
Two failure modes, not one
Kalashnikov separates what most SEOs mashed into a single “Yandex is broken” complaint:
- Pre-emptive 429s. Dense, repeating traffic from fixed residential and server subnets was cut at the edge so surviving capacity could serve people. No long behavioural check — just rate-limit and drop.
- “Not found” on page one. While shards and regional caches were out of sync, a session could open a results page and still miss a site that normally ranks in the top ten. On one Moldovan mobile pack that phantom miss rate reached about 6% during the worst week, then fell to 0% across six mobile packs once routing settled on 23 October.
By the 24-hour and three-hour slices ending mid-morning on 23 October, mobile packs showed zero “not found” losses on tens of thousands of sessions, while stationary packs were still stuck at roughly 71–76% 429s and a stubborn 3–5% phantom miss rate. In plain English: the index looked healthier, but Yandex kept serving a cheap, truncated SERP to burned fixed IPs.
Why rank-tracker history is contaminated
This sits beside the recovery stories we have already logged — Search API back on a night window, new pages ignored while old URLs are recrawled, and Webmaster tools returning in pieces. Kalashnikov’s logs explain the specific artefact of “site vanished from the checker but not from a phone”. Many October exports mixed genuine ranking moves with balancer triage. Annotate any series that hammered Yandex from datacentre or long-lived residential exits between about 11 and 23 October.
His practical conclusion is blunt: under emergency load shedding, Yandex learned that hard 429s on stationary nets plus a lighter SERP save CPU. Even after clusters are rebuilt, those thresholds may not return to the soft pre-attack settings. That matches what position-tool vendors are doing on the API side, which is a separate story.
My take
Treat mid-to-late October Yandex rank histories as suspect unless you know the exit type. Prefer mobile or lightly rotated residential paths for any live-SERP backfill, and do not grade an “update” off a week when three-quarters of stationary sessions never saw a real results page. The 2.7 million figure is large enough to be useful; it is still one operator’s stack, so keep the evidence threshold high and pair it with your own server logs before you rewrite a client’s October narrative.