On October 12, United24 Media reported that Ukraine had struck three Yandex data center sites over four days, starting with a facility in the Ryazan region overnight on October 8. The article pointed to Cloudflare Radar, which showed automated traffic from Yandex’s network falling close to zero by October 11.

We wanted to know whether that showed up from the other side: not Yandex’s outbound network as a whole, but its search crawler actually arriving at websites. It did.

What our sensors saw

WebDecoy sensors log every crawler that requests a page, including the ones that never run JavaScript. YandexBot was one of the busiest of them in early October, and close to 99% of its requests geolocated to Russia.

Measured against October 7, the last full day before the first reported strike:

Date (UTC)YandexBot traffic vs October 7
October 8down 81%
October 9down 88%
October 10down 93%
October 11down 100%
October 12down 100%
October 13down 100%

The daily view understates how sudden the first drop was. Hour by hour, YandexBot was steady through the night of October 7 and the first hours of October 8. Then, starting around 03:00 UTC on October 8 (06:00 Moscow time), its hourly rate fell 94% and stayed there. That lines up with the overnight strike the article describes.

For almost three days after that, a trickle kept coming. The last YandexBot request on any site we monitor arrived at 23:23 UTC on October 10. As of this post, we have seen none since.

It wasn’t us

When a crawler vanishes from your logs, the first suspect should be your own pipeline. So we checked the crawlers that share those sites with Yandex.

Every day from October 8 through October 13, Googlebot stayed between 20% below and 16% above its October 7 level, and Bingbot between 21% below and 12% above. Both are normal day-to-day swings. The sensors were up, logs were flowing, and every other major search crawler kept working the same pages. Only Yandex went away.

What we can and can’t say

Our data supports a narrow claim: Yandex’s search crawler stopped visiting the sites we monitor, in two steps that match the reported strike dates.

It doesn’t tell us why. A crawler can stop because its servers are damaged, because the company shut it down to save capacity for user-facing services, or because traffic was rerouted somewhere it no longer reaches the open web. We can’t tell those apart from the receiving end.

It also doesn’t say anything about propaganda bots or influence operations, which some of the coverage has focused on. Those run on accounts and platforms, not search crawlers, and none of our data measures them. The United24 piece makes the same point about the Cloudflare numbers.

One difference is worth noting. The article cites the German outlet t3n reporting that automated traffic from Yandex’s network had partly recovered by the evening of October 11. We see no recovery in YandexBot itself. Network-wide automated traffic includes many services besides the search crawler, so both can be true at once.

Russia-located crawler traffic overall dropped by about the same percentage as YandexBot on our sensors, because Yandex was nearly all of it.

If your site gets Yandex search traffic

  • Nothing on your side is broken. Your pages aren’t being refreshed in Yandex’s index while the crawler is gone. Content you publish now won’t show up there until it returns.
  • Don’t block it in the meantime. It’s tempting to tidy up rules for a bot that isn’t visiting, but you’ll want it back when it returns.
  • Expect a recrawl burst. Crawlers that have been offline usually catch up quickly. Make sure your rate limits allow for that from verified YandexBot IPs.
  • Verify before you trust. Anyone can send a YandexBot user agent. Yandex’s documented check is reverse DNS: a genuine crawler resolves to a host under yandex.ru, yandex.net or yandex.com, and that host resolves back to the same IP. With the real crawler offline, any “YandexBot” you see right now deserves a closer look.

Crawler traffic depends on someone else’s infrastructure

Search visibility depends on crawlers you don’t control, running in data centers you’ll never see. Most of the time that dependency is invisible. This week, for anyone relying on Yandex, it wasn’t.

The way to notice is to track crawlers individually, not as one “bots” line. A 94% drop in one crawler disappears in a total that’s dominated by Googlebot. Broken out per crawler, it’s obvious within the hour.

We’ll update this post when YandexBot comes back.

Frequently Asked Questions

Did YandexBot stop crawling websites in October 2026? +

On the sites we monitor, yes. YandexBot's hourly request rate fell 94% starting around 03:00 UTC on October 8, and its last request arrived at 23:23 UTC on October 10. We have seen none since, as of October 13.

Was the drop caused by WebDecoy or by a monitoring gap? +

No. Googlebot and Bingbot kept crawling the same sites at their usual levels through the whole period, so the sensors were working and seeing crawler traffic. Only Yandex disappeared.

Should I do anything if Yandex search matters to my site? +

Nothing to fix on your side. Pages simply aren't being refreshed in Yandex's index while the crawler is down. Don't block or rate-limit YandexBot in the meantime, and expect a recrawl burst when it returns. Verify any YandexBot traffic by reverse DNS, since the user agent alone is easy to fake.

Want to see WebDecoy in action?

Get a personalized demo from our team.

Request Demo