Почему Cloudflare убьёт ваши позиции в Рунете — и чем реально блокировать ботов

Раз в пару месяцев мне пишет очередной владелец бизнеса с одной и той же историей: «Подключили Cloudflare для защиты от ботов и DDoS, а через три недели сайт начал проваливаться в Яндексе. Совпадение?» Отвечаю сразу — почти никогда это не совпадение. Cloudflare — отличный инструмент для американского или европейского проекта, но для сайта, который живёт на трафике из Яндекса и Google по русскоязычным запросам, он способен тихо выбить вас из индекса и обрушить позиции. И самое неприятное: вы даже не поймёте, что причина в нём, потому что «сайт же открывается, всё работает».

Меня зовут Анатолий Кузнецов, я занимаюсь SEO с 2005 года, за плечами больше 300 проектов, и работаю только белыми методами. За эти годы я разбирал десятки случаев, когда сайт «падал ни с того ни с сего», и в изрядной части из них корнем зла оказывался как раз неверно настроенный Cloudflare или подобный зарубежный «защитный» сервис. В этой статье я по шагам объясню, как именно Cloudflare вредит позициям в Рунете, покажу механизм на пальцах, разберу реальный случай из своей практики и — главное — расскажу, чем защищаться от ботов правильно, не жертвуя индексацией. Если вам важно не просто «поставить защиту», а сохранить трафик, дочитайте до конца.

Сразу оговорюсь: я не против Cloudflare как технологии. Я против его бездумного включения на сайтах, чья аудитория — Россия и СНГ. Разница между «включил галочку Under Attack» и «настроил блокировку по подсетям на сервере» — это разница между потерей половины трафика и точечным решением проблемы. Об этом и поговорим.

Коротко

• Cloudflare в агрессивных режимах (JS-челлендж, «проверка браузера», Under Attack Mode) блокирует YandexBot и Googlebot так же, как ботов — поисковые роботы не проходят проверку, не видят контент и постепенно выкидывают страницы из индекса.
• Трафик уходит за рубеж. Cloudflare проксирует запросы через свои дата-центры, часто за пределами России, — растёт TTFB (время до первого байта), а это фактор ранжирования, плюс возможны сложности с требованиями РКН.
• По моему опыту, у клиентов после подключения Cloudflare позиции падали, а восстанавливались только после отключения проксирования или перехода на серверную защиту.
• Ботов надёжнее блокировать на уровне сервера — через .htaccess или nginx по конкретным подсетям дата-центров. Это не трогает поисковики и снимает нагрузку за час.
• Для Рунета есть российские анти-бот сервисы — Qrator, DDoS-Guard, Variti — они «понимают» YandexBot и держат трафик внутри страны.
• Cloudflare уместен, когда у вас реально зарубежная аудитория или нужен именно глобальный CDN, — но тогда его нужно тонко настраивать, а не включать «на всё подряд».

Что вообще делает Cloudflare и почему это выглядит соблазнительно

Cloudflare — это прокси-сервис, который встаёт между посетителем и вашим сайтом. Технически вы меняете DNS так, чтобы все запросы шли сначала на серверы Cloudflare, а уже они обращались к вашему хостингу. Отсюда все его плюсы: кеширование статики, скрытие реального IP сервера, фильтрация подозрительного трафика, защита от DDoS, бесплатный SSL-сертификат. Для владельца бизнеса это звучит как «поставил одну штуку — и сайт быстрее, безопаснее и защищён от атак». Причём базовый тариф бесплатный, что окончательно снимает возражения.

И в мире, где аудитория глобальна, всё так и работает. Проблема начинается там, где вашими главными «посетителями» являются не люди из США, а два робота — YandexBot и Googlebot, — от которых зависит, будет ли ваш сайт вообще виден в поиске. Cloudflare по умолчанию относится к любому автоматическому обращению с подозрением. А поисковый робот с точки зрения сервера — это и есть автоматическое обращение: он не двигает мышкой, не исполняет капчу, приходит массово и по расписанию. Вот здесь и зарыта мина.

Ключевое различие: режим DNS-only и режим проксирования

У каждого домена в Cloudflare есть переключатель — «оранжевое облако» (проксирование включено, трафик идёт через Cloudflare) и «серое облако» (DNS-only, Cloudflare работает только как система доменных имён, а трафик идёт напрямую на ваш сервер). В режиме «серого облака» большинство описанных ниже проблем отсутствуют, потому что Cloudflare не вмешивается в запросы. Но именно ради защиты и кеширования люди включают «оранжевое облако» — и получают весь набор рисков. Запомните это различие, к нему мы ещё вернёмся.

Механизм вреда №1: JS-челлендж выкидывает поисковых роботов

Главная опасность — это режимы проверки посетителя. У Cloudflare их несколько: «JS Challenge» (страница «Проверяем ваш браузер, подождите пять секунд…»), «Managed Challenge», интерактивная капча и, наконец, «Under Attack Mode» — самый жёсткий режим, который включают в панике во время атаки. Все они работают по одному принципу: прежде чем пустить посетителя на сайт, Cloudflare отдаёт ему промежуточную страницу с JavaScript, который браузер должен исполнить, чтобы доказать, что он «настоящий».

Живой человек в браузере этого даже не замечает — пять секунд, и он на сайте. А теперь представьте на его месте поискового робота. YandexBot и Googlebot умеют исполнять JavaScript, но делают это не всегда, не сразу и не для промежуточных челленджей. В подавляющем большинстве случаев робот, наткнувшись на страницу «проверки браузера», видит не ваш контент, а заглушку Cloudflare с кодом ответа, который для него означает «здесь смотреть нечего». Он не находит ни текста, ни ссылок, ни разметки — только техническую страницу-прокладку.

Что делает поисковик, когда раз за разом приходит на страницу и вместо контента получает заглушку? Сначала он снижает частоту обхода — решает, что сайт «недоступен» или «нестабилен». Потом начинает выкидывать страницы из индекса, потому что то, что нельзя просканировать, нельзя и показывать в выдаче. Это не мгновенный обвал, а медленное удушение: неделю-две всё выглядит нормально, затем в Яндекс.Вебмастере растёт число страниц со статусом «недостаточно качественная» или «страница не проиндексирована», и позиции ползут вниз. Владелец в это время грешит на что угодно — апдейт алгоритма, конкурентов, сезонность, — но не на «защиту», которую сам же и поставил.

Если вы хотите глубже понять, как устроен обход и что именно робот делает с вашими страницами, я подробно разбирал это в статье о том, как работают поисковые роботы — без этого понимания легко наступить на грабли Cloudflare второй раз.

Почему «белый список для ботов» не спасает так, как обещают

В ответ на это часто говорят: «Так в Cloudflare же есть режим «Verified Bots», он пропускает хороших роботов». Отчасти да — Cloudflare ведёт список известных ботов и старается их не блокировать. Но есть три «но». Первое: этот механизм ориентирован в первую очередь на Googlebot, Bingbot и крупных западных роботов; с YandexBot он работает менее предсказуемо, потому что Яндекс для Cloudflare — не приоритетная система. Второе: в режиме Under Attack Mode проверку проходят практически все, включая «верифицированных» роботов, — на то он и «режим осады». Третье: любая ошибка в определении бота (а робот Яндекса ходит с разных подсетей и меняет их) означает, что конкретный визит робота будет заблокирован, и вы об этом не узнаете. Ставить индексацию всего сайта в зависимость от того, правильно ли зарубежный сервис распознал российского робота, — это игра, в которой вы не контролируете правила.

Механизм вреда №2: трафик уходит за рубеж, растёт TTFB

Вторая проблема тоньше, но бьёт по всем без исключения, даже если челленджи выключены. Когда включено проксирование, запрос посетителя из, скажем, Екатеринбурга идёт не напрямую на ваш российский хостинг, а сначала на ближайший дата-центр Cloudflare. И вот тут начинается лотерея: у Cloudflare есть точки присутствия в Москве, но маршрутизация нередко уводит российский трафик через Франкфурт, Амстердам, Хельсинки или Стокгольм. То есть запрос физически совершает крюк за границу и обратно.

Для пользователя это лишние десятки, а иногда и сотни миллисекунд задержки. Но важнее, что растёт TTFB — время до первого байта, то есть насколько быстро сервер начинает отдавать ответ. Это один из технических факторов, на которые смотрят и Яндекс, и Google при оценке скорости сайта. Медленный отклик — минус к оценке качества, а на конкурентных запросах даже небольшое ухудшение технических метрик способно стоить нескольких позиций. Я не раз видел, как после отключения проксирования Cloudflare TTFB сайта на российском хостинге падал в два-три раза просто потому, что запрос перестал ходить за границу.

Скорость — это отдельная большая тема, и если вы не уверены, что у вас с ней порядок, начните с моего разбора о том, как проверить скорость загрузки сайта в Яндексе. Часто оказывается, что «тормозит» вовсе не движок, а именно лишний зарубежный прокси-слой.

Юридический слой: РКН и хранение данных

Есть и регуляторная сторона, о которой владельцы бизнеса обычно не думают, пока не столкнутся. Когда трафик и, потенциально, персональные данные пользователей проходят через зарубежную инфраструктуру, вы попадаете в серую зону требований о локализации данных российских граждан. Я не юрист и не даю юридических рекомендаций, но как практик скажу: для интернет-магазина, медицинского или образовательного проекта, который собирает данные пользователей, гонять их трафик через иностранные дата-центры — это лишний риск, которого легко избежать. Плюс сама инфраструктура Cloudflare периодически попадает под ограничения на российской стороне, и тогда часть ваших пользователей может ловить проблемы с доступом, а вы будете искать причину где угодно, только не в «защите».

Реальный случай из практики: атака ботов и роль «защиты»

Расскажу свежую историю — она хорошо показывает, почему Cloudflare часто оказывается не решением, а лишним слоем проблем. В августе 2026 года я расследовал массированную атаку на несколько своих же сайтов. Картина была такая: на сайт шла накрутка поведенческих факторов ботами — около 3000 визитов в день, до 90–92% всего трафика. Боты представлялись как «Chrome Mobile / Android 12–15», причём версии операционной системы были аккуратно размазаны по всему диапазону — явная искусственная ротация, чтобы выглядеть как разные живые телефоны.

Первое, что приходит в голову испуганному владельцу в такой ситуации, — «срочно включить Cloudflare и Under Attack Mode». И это была бы ошибка. Потому что, включив агрессивную проверку, я бы заодно перекрыл кислород YandexBot и Googlebot и превратил проблему с ПФ в проблему с индексацией — то есть сменил одну беду на другую, худшую. Вместо этого я пошёл разбираться в данных.

Как я вычислил ботов — и почему сервер оказался лучше прокси

Разгадка была в IP-адресах. Мобильный UA у ботов был, а вот IP — из дата-центров: хостинги Miran, IMAQLIQ, Evro Telecom, TimeWeb. А это невозможно у живого человека: реальный телефон выходит в интернет через МТС, Мегафон, Билайн или домашний провайдер, но никогда — через серверный хостинг. Мобильный UA плюс серверный IP — это стопроцентный бот, без вариантов.

Увидел я это через Logs API Яндекс.Метрики — там доступны сырые данные, которые проходят мимо фильтра отображения в обычных отчётах. IP в логах приходят с маской последнего октета (подсеть /24), но этого более чем достаточно, чтобы понять, из какой сети и какого провайдера идёт трафик. И тут выяснилась замечательная деталь: 99% всех ботов приходили всего с шести подсетей:

• 91.142.85.0/24
• 45.135.94.0/24
• 81.29.135.0/24
• 81.29.136.0/24
• 109.248.57.0/24
• 37.77.107.0/24
• плюс диапазон IPv6 2a00:f2a0::/32

Такая концентрация — это подарок для защиты. Не нужен никакой облачный прокси с эвристиками и капчами. Достаточно на уровне сервера закрыть эти шесть подсетей — и атака рассыпается. Что я и сделал через .htaccess: на Apache это директивы Require not ip (или Deny from на старых версиях) для каждой подсети. Результат: трафик упал с примерно 250 до 13 визитов в час — минус 95% — буквально за час. И заметьте: живых посетителей с дата-центров не бывает в принципе, поэтому риск заблокировать реального клиента был нулевой. А YandexBot (сети 77.88.*) и Googlebot (66.249.*) в этих «грязных» подсетях не ходят — индексация не пострадала ни на йоту.

Вот в этом и вся суть спора «Cloudflare против сервера». Cloudflare решал бы задачу вслепую, гадая, кто бот, а кто робот Яндекса, — и неизбежно ошибался бы в обе стороны. Серверная блокировка по конкретным подсетям решила её хирургически: убрала ботов, не тронула поисковики, не увела трафик за рубеж. Я подробно описывал методику определения таких атак в материале о том, как определить накрутку поведенческих факторов на сайте — рекомендую, если подозреваете, что вас «крутят».

Тонкое поведение ботов — и почему фильтр Метрики не защищает

Ещё пара наблюдений, чтобы вы понимали, с каким уровнем изощрённости приходится иметь дело. Боты вели себя «идеально»: глубина просмотра — 1 страница, время на сайте — 15–17 секунд. Заметьте, чуть выше порога отказа в 15 секунд — чтобы формально НЕ считаться отказом. Процент отказов у них выходил около 9%, тогда как у живых людей на этом сайте — примерно 30%, а среднее время — около 78 секунд. То есть боты подделывали «отличную вовлечённость», чтобы обмануть алгоритмы Яндекса и выглядеть как заинтересованные посетители.

И отдельно предупрежу про ловушку. В Яндекс.Метрике есть галочка «Фильтровать роботов по поведению». Многие думают, что она защищает. Нет — она всего лишь прячет ботов из отчётов, чтобы цифры выглядели красиво. Сами боты как грузили сайт и портили поведенческие факторы, так и продолжают это делать. Фильтр маскирует масштаб атаки, усыпляя бдительность. Если вам важно видеть реальную картину, а не причёсанную, посмотрите мой разбор, как уменьшить роботность в Яндекс.Метрике — там пошагово про то, как отделить настоящих людей от накрутки.

Вторая накрутка, которую не лечит вообще никакая защита сервера

Важный нюанс, который ломает шаблон «поставил защиту — и спокоен». Параллельно с ботами, ходившими на сайт, шла вторая, совершенно отдельная накрутка — CTR через поиск. Боты кликали по сайту прямо в выдаче Яндекса по запросам-конструкторам вида «услуга + бренд/домен», создавая невозможный CTR — 50–84% на позициях с 5-й по 12-ю. На реальный сайт эти боты не заходили — только кликали в поиске и уходили.

Что это значит на практике? В Яндекс.Метрике их нет — они же не открыли сайт. IP их не видно. Блокировать на сервере нечего — они физически не постучались к вам на хостинг. И уж тем более их не поймает Cloudflare — он видит только тех, кто пришёл на сайт. Единственное место, где эта накрутка вообще видна, — Яндекс.Вебмастер: там тысячи кликов из поиска при десятках реальных визитов в Метрике. Лечится это не блокировкой, а жалобой в Яндекс (Платон) и, если накрутку заказал недобросовестный «подрядчик по трафику», — отказом от такой услуги.

Я привожу это, чтобы вы поняли главное: Cloudflare не только вредит индексации — он ещё и не решает половину реальных задач с накруткой. Люди платят за иллюзию защиты, теряют на индексации, а самая опасная для позиций накрутка (CTR-фильтр) остаётся нетронутой. Это, кстати, классический сценарий негативного SEO: конкурент «крутит вас в минус» плохим поведением и переоптимизацией CTR, чтобы Яндекс наложил на вас фильтр за накрутку ПФ, а сам продвигается чисто. О том, как конкуренты пытаются выдавить сайт из ТОП-1, у меня есть отдельная статья — почитайте, если чувствуете, что против вас играют.

Чем реально блокировать ботов: рабочая связка вместо Cloudflare

Теперь самое полезное — что делать вместо того, чтобы включать зарубежный прокси. Я выстраиваю защиту по принципу «от простого и точного к сложному», и в 90% случаев хватает первых двух уровней.

Уровень 1. Блокировка по подсетям на сервере (.htaccess / nginx)

Это база и первое, что нужно сделать при атаке с концентрацией на нескольких сетях. Логика простая: вы находите подсети, откуда идёт мусорный трафик (через Logs API Метрики или логи веб-сервера), и закрываете их на уровне сервера.

• Apache (.htaccess): для каждой подсети добавляется правило доступа — на современных версиях это Require not ip 91.142.85.0/24 внутри блока контроля доступа, на старых — Deny from 91.142.85.0/24. Работает мгновенно, правится в одном файле.
• nginx: через директиву deny в конфигурации сервера или location (например, deny 45.135.94.0/24;), либо через модуль geo/map для более гибких правил.

Плюсы этого подхода: полный контроль, ноль зависимости от сторонних сервисов, поисковые роботы не затрагиваются (их подсети вы просто не блокируете), нет ухода трафика за границу и нулевая стоимость. Минус один — это ручная работа, и она эффективна против концентрированной атаки, а не против распределённого DDoS с тысяч разных IP. Но для типичной накрутки ПФ, которая почти всегда идёт с ограниченного пула дата-центров, это идеальное решение. Если внедрять правки в конфигурацию вам страшно или некому — это как раз то, с чем я помогаю в рамках доработки сайта: настраиваю блокировки так, чтобы ничего не сломать и не задеть индексацию.

Уровень 2. Российские анти-бот и анти-DDoS сервисы

Если атака распределённая и серверной блокировкой не обойтись, нужен специализированный сервис. И здесь принципиально важно брать российский, а не Cloudflare, — потому что российские сервисы держат трафик внутри страны и «знают» YandexBot как своего. Из проверенного:

• Qrator Labs — сильная защита от DDoS и ботов, российская инфраструктура, корректно работает с поисковыми роботами Яндекса.
• DDoS-Guard — популярное отечественное решение с точками присутствия в России, есть фильтрация ботов и CDN.
• Variti — специализируется именно на защите от ботов и парсинга без капчи для живых пользователей, что важно для сохранения поведенческих факторов.

Эти сервисы решают ту же задачу, что и Cloudflare, но без двух его главных минусов для Рунета: они не уводят трафик за рубеж и настроены под особенности российского поиска. Да, большинство из них платные, но за защиту, которая не убивает индексацию, платить не жалко.

Уровень 3. Защита от накрутки ПФ и работа с Вебмастером

Против той части атаки, что живёт в выдаче (накрутка CTR), техническая защита бессильна — тут работает только жалоба в поддержку Яндекса с выкладкой данных из Вебмастера и Метрики. Параллельно нужно укреплять собственные поведенческие факторы честными способами, чтобы «естественный» фон перебивал искусственный. Про это у меня есть подробное руководство — как улучшить поведенческие факторы без накрутки: девять приёмов, которые реально двигают позиции и при этом не подставляют вас под фильтр.

Когда Cloudflare всё-таки уместен

Чтобы не выглядеть догматиком, честно очерчу границы. Cloudflare — хороший инструмент, и есть сценарии, где он на своём месте:

• У вас реально международная аудитория. Если существенная доля посетителей — из США, Европы, Азии, глобальный CDN Cloudflare ускорит для них загрузку, и выгода перевесит риски. Для чисто русскоязычного проекта это не ваш случай.
• Вам нужен именно CDN для тяжёлой статики (видео, крупные изображения) на глобальную аудиторию — при этом основной домен можно держать в режиме DNS-only, а через Cloudflare гонять только поддомен со статикой.
• Вы попали под мощный распределённый DDoS прямо сейчас, и нужно продержаться несколько часов. Тогда Under Attack Mode — это временная экстренная мера, которую отключают, как только атака спала, а не постоянный режим.
• Вы умеете его тонко настраивать: держите режим DNS-only или минимальный уровень безопасности для российских подсетей, добавляете YandexBot/Googlebot в исключения, отключаете челленджи для поисковых user-agent и регулярно проверяете индексацию в Вебмастере.

Ключевое слово везде — «тонко настраивать». Проблема не в самой технологии, а в том, что 9 из 10 владельцев включают «оранжевое облако» с настройками по умолчанию и режимом «защитить всё», не понимая, что заодно защитили сайт от собственных поисковиков. Если сомневаетесь, нужен ли вам Cloudflare вообще и как его настроить без вреда, разумнее один раз получить SEO-консультацию и решить точечно, чем месяцами гадать, почему просели позиции.

Как понять, что Cloudflare (или похожая защита) уже вредит вашему сайту

Диагностика простая, проверьте по чек-листу:

1. Зайдите в Яндекс.Вебмастер и посмотрите динамику проиндексированных страниц. Если после подключения «защиты» число страниц в поиске поползло вниз, а в «исключённых» растёт «недостаточно качественная» или «страница не отвечает» — это тревожный звонок.
2. Проверьте «Обход» и «Статистику обхода» в Вебмастере: если код ответа для роботов стал не 200, а 403/503 или робот стал реже приходить — Cloudflare режет вашего же поисковика.
3. Используйте «Проверку ответа сервера» в Вебмастере с указанием user-agent YandexBot: если вместо контента страницы вы видите челлендж Cloudflare — диагноз подтверждён.
4. Замерьте TTFB до и после — если после отключения проксирования отклик заметно ускорился, значит, трафик ходил за границу.
5. Сопоставьте даты: наложите дату подключения Cloudflare на график позиций и трафика. Совпадение начала просадки с подключением — почти всегда не случайность.

Если по нескольким пунктам совпало — первое, что я рекомендую сделать, это перевести домен в режим DNS-only (серое облако) и понаблюдать неделю-две за индексацией. Часто уже одного этого шага достаточно, чтобы страницы начали возвращаться в поиск. Причины просадок бывают и другими, но «защиту, которая душит роботов», всегда стоит проверять в первую очередь, потому что её ставят добровольно и потом о ней забывают.

Итог: защита не должна стоить вам индексации

Соберём всё вместе. Cloudflare в агрессивных режимах опасен для сайта, живущего на трафике из Яндекса и Google по русскоязычным запросам, по двум причинам: он блокирует поисковых роботов JS-челленджами и Under Attack Mode, из-за чего страницы выпадают из индекса, и он уводит трафик за рубеж, ухудшая TTFB и добавляя регуляторные риски. При этом самую коварную накрутку — CTR через выдачу — он всё равно не лечит.

Правильный путь — блокировать ботов там, где вы всё контролируете: на уровне сервера, точечно по подсетям дата-центров через .htaccess или nginx. Это работает мгновенно, ничего не стоит и не трогает поисковики. Если нужна защита от распределённых атак — брать российские анти-бот сервисы (Qrator, DDoS-Guard, Variti), которые держат трафик в стране и дружат с YandexBot. А Cloudflare оставить для проектов с зарубежной аудиторией и только при грамотной настройке.

Если вы не хотите разбираться в подсетях, логах и режимах прокси самостоятельно, а хотите просто, чтобы сайт был защищён и при этом рос в поиске, — это ровно то, чем я занимаюсь. Приходите на профессиональное SEO-продвижение: разберу вашу защиту, найду источники мусорного трафика, настрою блокировки без вреда для индексации и выстрою стратегию, которая двигает позиции белыми методами. Проверять «а не убивает ли вас собственная защита» лучше до того, как просядет трафик, а не после.