Yandex outage: data shows that instead of going dark, malicious bots moved

What happened to Yandex, and did the bots really go away?

Between 7 and 11 October 2026, reported Ukrainian drone strikes hit three Yandex facilities in Russia. Traffic from Yandex Search fell 99% below baseline on 11 October, and Yandex.Cloud fell 90%. By 18:00 UTC on 14 October, traffic was back to about 85% of normal. The malicious bots, however, did not go away.

These figures come from Cloudflare's own network only. Cloudflare's post also contains some inconsistencies, and press reports of the drop vary (94%, under 1%, or 0.4% of peak requests). Treat the numbers as approximate, and the direction as reliable.

Was the traffic drop really a drop in attacks?

No. The Yandex Search collapse was almost entirely legitimate crawling: in sampled requests, 78.1% came from YandexBot, 11.5% from YandexRenderResourcesBot and 1.9% from YandexImages. That was a loss of search indexing, not a loss of attackers. A headline number can hide what the traffic actually was.

On Yandex.Cloud, hostile activity did fall. Bot traffic dropped about 40%, WordPress plugin probing fell 90% and scanner-identified requests fell 93%. But a fall on one network is only half the story.

Where did the malicious bots go?

They moved to other hosting providers. Russian bot traffic aimed at gambling accounts rose from 167.7 million to 170.1 million requests over the week (+1.4%), even as Yandex.Cloud's own share fell 18.3%. Cloudflare concluded that operators relocated their workloads.

The clearest evidence: requests from Yandex.Cloud to one gambling customer dropped to zero after the 8 October disruption. Identical requests then appeared from Radist and Selectel, sharing the same JA4 TLS fingerprint, request paths, headers and User-Agent strings. Same clients, new address.

Why does this matter for a small business?

Because many small businesses defend themselves by blocking a country, a network or a list of IP ranges. This event shows how fragile that is. When an attacker can change hosting provider within days, a block aimed at one network protects you only until the next move.

Your exposure is probably a login page, a booking form, a checkout or a WordPress site with plugins. These are what scanners probe. Cloudflare noted that WordPress plugin probing was one of the activities that dropped on Yandex.Cloud, which tells you it is routine background noise for any site running that software.

How should I protect my website from bots, whatever network they use?

Judge traffic by behaviour, not by origin. That is Cloudflare's own advice: look at request patterns, shared fingerprints and abnormal rates, and protect sensitive endpoints with firewall rules regardless of which network the requests come from.

A practical checklist for a small site:

1. Rate limit your sensitive pages. Login, password reset, contact and booking forms should reject a single client making dozens of attempts a minute.
2. Put a web application firewall in front of the site. Managed rules catch known probing for plugin vulnerabilities without you maintaining IP lists.
3. Add bot challenges to forms. A lightweight challenge stops most automated submissions without annoying genuine customers.
4. Update or remove plugins. Scanners look for outdated ones. Every plugin you delete is one less thing to probe.
5. Read your logs weekly. Look for repeated identical requests, odd paths such as /wp-content/plugins/ names you do not use, and spikes at unusual hours.

Should I block Russian traffic altogether?

Only if you have no customers there and accept that it is a blunt tool. A country or network block removes some noise, but this episode shows operators simply reappear elsewhere. Use it as one layer, never as your main defence.

There is also a cost: geographic blocks can catch legitimate visitors using VPNs or travelling. Behavioural rules aim at the actual problem, which is what a request does rather than where it appears to come from.

Does the Yandex outage affect my search visibility?

For most UK businesses, not directly. Yandex is a Russian search engine, and the outage mainly shows how quickly crawling can stop when infrastructure fails. The lesson applies to Google too: if the platforms you depend on stop for a few days, your visibility goes with them.

What is Braynex Services' view?

At Braynex Services, our view is that the lesson here is about control. If your security depends on a list someone else maintains, or your customer access depends on a platform you rent, you are exposed to events you cannot predict. Moving the problem is easy for attackers. Moving your own defences should not be hard.

That is why we favour owning your infrastructure: a real website, your own bookings and your own data, protected by rules you understand. A nail salon we worked with moved from a booking marketplace costing about 1,800 a month in commission to its own system at 35 a month. Ownership also meant it could set its own protections on its own forms.

Our opinion, plainly: stop treating bot defence as a list of countries to block. Treat it as a set of behaviours you will not tolerate, and apply it everywhere.

Want to know how exposed your site is?

Book a free audit at braynexservices.com. Braynex Services will review your website, forms and bookings, show you where bots and missed enquiries are costing you, and give you a short, prioritised list of fixes.