When reports of strikes on Yandex data centers spread, aggregate HTTP traffic charts showed steep drops that fueled claims Russian bot farms and influence operations had been knocked offline. Cloudflare's analysis of Radar and Bot Management data shows that conclusion was too simple. Yandex operates two distinct autonomous system numbers, and each was affected differently.
- AS13238, used by Yandex Search, saw a traffic drop made up almost entirely of verified search crawlers indexing web pages, images and site resources.
- AS200350, which runs Yandex.Cloud, showed a decline in malicious activity such as vulnerability scanning and probing.
- High-volume automation did not disappear from AS200350; it migrated to other hosting providers.
- Cloudflare notes that while malicious traffic may originate from a particular provider, origin does not by itself establish who is responsible for that traffic.
The key lesson here is methodological. Aggregate traffic metrics anonymize distinct workloads: crawling, cloud hosting, scanning and bot traffic all blend into one line on a chart. Splitting by ASN reveals that the visible decline on the search side was largely legitimate indexing behavior, not adversarial infrastructure going dark. On the cloud side, the adversary adapted rather than stopped.
For developers building abuse detection, rate limiting or anti-bot defenses, this matters in practice. First, treat traffic drops at a hosting provider as a signal to re-check where the traffic moved, not as a resolution. Second, track per-ASN and per-workload baselines so crawler declines are not confused with mitigation success. Third, be cautious about attributing intent from source IP ranges, since a request originating from a given network does not prove that network's operator is behind it. Cloudflare's takeaway is that resilience against such disruptions is cheap for attackers: infrastructure can shift faster than the measurement window most dashboards use.