Summary: After reported drone strikes hit three Yandex data centers in Russia between October 7 and 11, 2026, claims spread that Russian bot farms had been knocked offline. Cloudflare’s Radar and Bot Management data tells a different story: search crawling collapsed, but malicious automation simply reappeared on other hosting providers. For anyone building detection or infrastructure decisions on traffic volume, that distinction matters a lot.
Two networks, two very different outages
Yandex runs two ASNs with different jobs. AS13238 serves the search engine: Cloudflare classified 99.5% of its requests as automated, and 93.6% of its bot requests as verified crawlers. AS200350 is Yandex.Cloud, a hosting network where roughly 95% of scored requests were bots — none of them verified.
By October 11, traffic fell to 99% below baseline for Yandex Search and 90% for Yandex.Cloud, and both networks stayed 86–90% below normal through October 13. The headline drop was real. What it meant depended entirely on which network you looked at.
The search drop was mostly indexing
The decline on AS13238 was almost entirely verified YandexBot (78.1% of sampled requests), YandexRenderResourcesBot, and YandexImages. The sector hit hardest was publishing: traffic from Yandex networks to news sites fell 44%, and 40.5% of Cloudflare customers had already been returning 403s to the crawler anyway. The practical effect was less content discovery in Yandex Search, not less malicious activity.
The malicious traffic moved, it didn’t stop
Yandex.Cloud is where the story gets instructive. Attack-like categories dropped sharply — WordPress plugin probing fell 90%, scanner-identified requests fell 93%. But the clearest signal came from a single gambling customer account. Bot requests from Yandex.Cloud to it went to zero after the October 8 disruption, and identical requests immediately started arriving from other Russian hosting ASNs, including Radist and Selectel. Same JA4 TLS fingerprint, same unusual request paths and headers, same custom User-Agent strings.
Overall Russian bot traffic targeting gambling accounts was essentially flat for the week: 167.7 million to 170.1 million requests, up 1.4%. Cloud workloads are portable, and the operators redeployed within hours.
Cloudflare also found no evidence the strikes disrupted social media manipulation: Russian-origin traffic to a major platform’s post, reply, and like endpoints declined only 5.7% over the event period, with global traffic up 1.1%. They note that without data outside Cloudflare they can’t conclusively rule out a connection — the claims just aren’t supported by this data.
What this means for how you build
The core lesson is that client ASN and traffic volume are unreliable proxies for threat activity. A near-total network outage coexisted with zero net reduction in malicious automation. Cloudflare’s recommendation is to inspect request behavior instead: track shared JA4 fingerprints, watch anomalous request rates, and apply WAF rules to sensitive endpoints regardless of origin network.
If you run bot detection or API protection, ask whether your dashboards would catch this pattern. If your alerting keys on volume spikes from a known-bad ASN, a migration like this one looks like an outage resolving — nothing to see. Fingerprint-level correlation across providers is what reveals it. It’s the same principle I covered when looking at Cloudflare’s data pipeline and deferred hardware spend: aggregate metrics hide the details that actually drive decisions.
One limitation worth keeping in mind: this is Cloudflare’s view of its own network, which is enormous but partial. The conclusion is about what its telemetry shows, not a census of the internet. Still, the takeaway for builders is concrete — physical infrastructure is static, and the automation worth defending against is built to move. Plan your detection accordingly.