Как заблокировать накрутку поведенческих через .htaccess: реальный кейс, 6 подсетей и −95% ботов за час

В августе 2026 года на мои сайты пошла накрутка поведенческих факторов. Не десятки визитов, а тысячи в сутки — до 90% всего трафика делали боты. Я не стал паниковать, писать в поддержку и ждать месяц. Я открыл сырые логи, нашёл шесть подсетей, с которых лился весь мусор, и закрыл их на сервере через файл .htaccess. Через час трафик с этих сетей упал с 250 до 13 визитов в час — минус 95%. Ни один живой посетитель и ни один поисковый робот при этом не пострадал.

Меня зовут Анатолий Кузнецов, я занимаюсь SEO с 2005 года, за это время провёл больше 300 проектов и работаю только белыми методами. В этой статье я разберу по шагам, как самому заблокировать бот-подсети на сервере: покажу рабочий синтаксис для Apache, дам готовый шаблон блока, объясню, почему YandexBot и Googlebot от этого не пострадают, и предупрежу о ловушках, из-за которых блокировка может тихо слететь через три недели. Всё на реальном кейсе, без теории ради теории.

Материал рассчитан на владельца бизнеса, а не на технаря. Если что-то из терминов будет непонятно — я объясняю простыми словами по ходу. А если разбираться в конфигах сервера нет ни времени, ни желания, вы всегда можете заказать SEO-продвижение и передать эту головную боль мне.

Коротко

• Мобильный UA + серверный IP = 100% бот. Реальный телефон выходит в сеть через МТС, Мегафон или домашний Wi-Fi, а не через дата-центр хостинга.
• 99% накрутки шло всего с 6 подсетей. Такая концентрация — подарок: закрываешь шесть строк в конфиге и обрубаешь почти весь мусорный трафик.
• Блокировка делается в .htaccess директивами Require not ip (Apache 2.4) или Deny from (Apache 2.2). Результат — за час, а не за месяц.
• Поисковые роботы не пострадают. YandexBot ходит с сети 77.88.*, Googlebot — с 66.249.*. В дата-центровых подсетях ботоводов их нет.
• Главный риск — что .htaccess слетит. Плагин, бэкап или обновление CMS перезапишут файл, и боты вернутся. Решение — продублировать блок в конфиге nginx.
• Проверьте, видит ли Apache реальный IP. Если сайт стоит за nginx, в логах может быть один и тот же адрес прокси — тогда блок по IP не сработает, пока не настроите передачу реального адреса.

Что вообще случилось: как выглядит накрутка изнутри

Сначала я заметил странность в Яндекс.Метрике: трафик вырос в разы, но заявок больше не стало. Классический симптом накрутки. Настоящие клиенты не появились — появились боты, которые имитируют людей, чтобы испортить поведенческие факторы сайта и подставить его под фильтр Яндекса за накрутку.

Когда я открыл сырые данные через Logs API Метрики (это выгрузка событий мимо красивых отчётов, без сглаживающих фильтров), картина стала ясной. Боты приходили с User-Agent «Chrome Mobile / Android 12–15», аккуратно размазанным по версиям операционной системы — слишком ровно, чтобы быть правдой. У реальной аудитории версии ОС распределены неравномерно, а тут — будто по линейке.

Но главная улика была в IP-адресах. Они принадлежали дата-центрам: хостинги Miran, IMAQLIQ, Evro Telecom, TimeWeb. И вот тут ключевой вывод, который стоит запомнить каждому владельцу сайта: мобильный User-Agent в связке с серверным IP — это стопроцентный бот. Живой человек с телефона выходит в интернет через сотового оператора или домашний роутер. Он физически не может «сидеть» на сервере в дата-центре. Как только вы видите «мобильный Chrome», приходящий с IP хостинг-провайдера, — перед вами программа, а не покупатель.

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

Почему именно .htaccess, а не Cloudflare и не фильтр Метрики

Прежде чем блокировать, важно выбрать правильный инструмент. Я перебрал варианты и объясню, почему остановился на серверной блокировке.

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

Cloudflare для Рунета опасен. Западный сервис с его JS-челленджем (проверкой «докажи, что ты не робот») легко принимает YandexBot и Googlebot за ботов и не пускает их на сайт. Итог — выпадение из индекса и просадка позиций. Плюс Cloudflare гонит трафик через зарубежные серверы, что для сайта, который продвигается в Яндексе, скорее вред. Для Рунета это не решение.

Серверная блокировка через .htaccess — точная и быстрая. Мы закрываем конкретные подсети, с которых идёт мусор. Живых людей с дата-центров не бывает, значит риск задеть клиента — нулевой. Поисковые роботы в этих сетях тоже не ходят. Меняется всё за минуты, никаких сторонних сервисов и абонентской платы. Если же атака перерастает в мощный DDoS, есть тяжёлая артиллерия — российские анти-бот-решения (о них ниже).

Шаг 1. Проверьте, видит ли ваш Apache реальный IP посетителя

Это самый важный подготовительный шаг, который многие пропускают — и потом удивляются, почему блок не работает. Дело в том, что на большинстве современных хостингов и VPS перед Apache стоит nginx. Схема такая: посетитель стучится в nginx, nginx передаёт запрос дальше в Apache. Если связка настроена неправильно, Apache видит не адрес посетителя, а адрес самого nginx — например, 127.0.0.1 (это «локальный» адрес, сам сервер) или внутренний IP.

Если так, то блокировать по IP бесполезно: у всех запросов адрес одинаковый, и вы либо не заблокируете никого, либо заблокируете вообще всех, включая себя. Поэтому сначала проверяем.

Откройте лог доступа Apache (обычно это файл access.log в папке логов сайта) и посмотрите на первую колонку — там записан IP каждого запроса. Если вы видите живые, разные внешние адреса вроде 91.142.85.10, 5.18.x.x и так далее — отлично, Apache видит реальный IP, можно блокировать. Если же везде стоит 127.0.0.1 или один и тот же внутренний адрес — значит, реальный IP «спрятан» и лежит в заголовке X-Forwarded-For или X-Real-IP, которые передаёт nginx.

В этом случае нужно, чтобы Apache научился доставать реальный адрес из заголовка. За это отвечает модуль mod_remoteip. Настройка делается в конфиге Apache (не в .htaccess) и выглядит примерно так:

RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 127.0.0.1

После этого Apache начнёт видеть настоящие адреса посетителей, и блокировка по IP заработает как надо. Если доступа к конфигу нет, а хостинг общий (shared) — это повод обратиться в поддержку хостинга или сразу блокировать на уровне nginx, о чём я расскажу ниже. Если разбираться в этом самому тяжело, имеет смысл взять SEO-консультацию — за один разбор мы точно определим, где у вас теряется реальный IP.

Шаг 2. Найдите подсети, с которых идёт накрутка

Заблокировать нужно не отдельные IP (их у ботовода тысячи, он крутит их как перчатки), а целые подсети — диапазоны адресов, принадлежащие одному дата-центру. Запись вида 91.142.85.0/24 означает диапазон из 256 адресов от 91.142.85.0 до 91.142.85.255. Мы блокируем всю сеть сразу — и неважно, сколько адресов внутри неё бот успеет перебрать.

В моём кейсе выгрузка из Logs API Метрики показала золотую картину: 99% всей накрутки шло всего с шести подсетей. Такая концентрация — большая удача. Значит, закрыв буквально несколько строк в конфиге, я обрублю почти весь мусорный трафик, не трогая остальной интернет.

Кстати, в Logs API IP отдаётся с замаскированным последним октетом (то есть с точностью до /24-сети) — и этого как раз достаточно, чтобы понять, какой сети принадлежит адрес и к какому дата-центру он относится. Полный адрес конкретного бота не нужен — нам важна сеть целиком.

Вот те самые шесть подсетей и один диапазон IPv6, которые дали 99% накрутки:

Подсеть	Тип	Что это
91.142.85.0/24	IPv4	Дата-центр (хостинг)
45.135.94.0/24	IPv4	Дата-центр (хостинг)
81.29.135.0/24	IPv4	Дата-центр (хостинг)
81.29.136.0/24	IPv4	Дата-центр (хостинг)
109.248.57.0/24	IPv4	Дата-центр (хостинг)
37.77.107.0/24	IPv4	Дата-центр (хостинг)
2a00:f2a0::/32	IPv6	Крупный диапазон IPv6

Как найти свои подсети, если Logs API вам недоступен? Самый простой путь — открыть access.log сервера и посмотреть, с каких адресов идёт вал одинаковых мобильных запросов. Сгруппируйте адреса по первым трём числам (это и есть /24-сеть), посчитайте, сколько запросов пришло с каждой сети, и вы быстро увидите верхушку — несколько сетей, дающих львиную долю трафика. По каждому подозрительному адресу проверьте, кому он принадлежит, через любой whois-сервис: если это хостинг или дата-центр, а UA при этом мобильный — в блок.

Шаг 3. Готовый блок для .htaccess (Apache 2.4)

Теперь — самое главное. Файл .htaccess лежит в корневой папке сайта (там же, где index.php). Это текстовый файл настроек, который Apache читает при каждом запросе. Открываем его и в самое начало, до всех остальных правил, вставляем блок.

Современный Apache версии 2.4 использует синтаксис с директивой Require. Вот готовый шаблон — просто подставьте свои подсети:

<RequireAll>
  Require all granted
  Require not ip 91.142.85.0/24
  Require not ip 45.135.94.0/24
  Require not ip 81.29.135.0/24
  Require not ip 81.29.136.0/24
  Require not ip 109.248.57.0/24
  Require not ip 37.77.107.0/24
  Require not ip 2a00:f2a0::/32
</RequireAll>

Разберём, что тут происходит, по-русски. Блок <RequireAll> означает «должны выполняться сразу все условия внутри». Строка Require all granted — «пускаем всех по умолчанию». А каждая строка Require not ip — «кроме вот этой сети». В сумме: пускаем весь мир, но захлопываем дверь перед шестью бот-сетями и одним IPv6-диапазоном. Всем заблокированным Apache отдаёт ошибку 403 (доступ запрещён) — для бота это глухая стена.

Обратите внимание на IPv6-строку 2a00:f2a0::/32. Многие про IPv6 забывают, а зря: если бот умеет ходить по «новому» протоколу IP, а вы закрыли только «старые» IPv4-адреса, часть трафика продолжит просачиваться. Закрывайте оба типа.

Шаг 4. Запасной вариант для старого Apache 2.2 (Deny from)

Если хостинг древний и на нём стоит Apache версии 2.2, синтаксис Require он не поймёт — и вместо блокировки вы получите ошибку 500 (сайт ляжет целиком). Для старых серверов используется другой, «классический» синтаксис — Order и Deny from:

Order Allow,Deny
Allow from all
Deny from 91.142.85.0/24
Deny from 45.135.94.0/24
Deny from 81.29.135.0/24
Deny from 81.29.136.0/24
Deny from 109.248.57.0/24
Deny from 37.77.107.0/24

Логика та же: Allow from all — пускаем всех, Deny from — запрещаем перечисленные сети. Как понять, какая у вас версия? Проще всего спросить у поддержки хостинга или посмотреть в панели управления. А ещё надёжнее — не гадать: вставьте сначала одну строку, сохраните, откройте сайт. Если сайт открывается — синтаксис верный, дописывайте остальное. Если появилась ошибка 500 — синтаксис не тот, откатывайте и пробуйте второй вариант.

Важное предупреждение. Всегда сохраняйте копию исходного .htaccess перед правками. Одна лишняя буква в этом файле кладёт весь сайт с ошибкой 500. Скопировали файл, внесли блок, проверили сайт — и только потом выдыхаете.

Шаг 5. Почему YandexBot и Googlebot не пострадают

Это вопрос номер один, который мне задают: «А не выпаду ли я из поиска, если начну блокировать по IP?» Отвечаю твёрдо: нет, если блокируете правильно — по конкретным дата-центровым подсетям.

Поисковые роботы ходят со своих, хорошо известных сетей. YandexBot приходит с адресов вида 77.88.* (и ещё пары официальных диапазонов Яндекса), Googlebot — с 66.249.*. Этих сетей в нашем списке блокировки нет и близко. Ботоводы-накрутчики арендуют дешёвые серверы у хостингов вроде тех, что я перечислил, — и это совершенно другие подсети. Пути поисковиков и накрутчиков не пересекаются.

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

Результат: −95% за час

Теперь цифры. До блокировки на сайт лилось около 250 визитов в час с этих сетей — сплошной бот-трафик. Я вставил блок в .htaccess, сохранил файл. Ждать не пришлось: .htaccess применяется мгновенно, при следующем же запросе.

Показатель	До блокировки	После (через час)
Визиты в час с бот-сетей	~250	~13
Доля ботов в трафике	до 90%	единицы процентов
Нагрузка на сервер	высокая	вернулась в норму
Живые посетители потеряны	0

Через час трафик с этих сетей упал до 13 визитов — минус 95%. Оставшиеся 13 — это либо новые адреса того же ботовода, которые я потом добил, либо случайный фоновый шум. Заявки от реальных клиентов не изменились ни на единицу — потому что реальных клиентов среди заблокированных не было. Побочный бонус: снизилась нагрузка на сервер, сайт стал отвечать быстрее. Кстати, если вас волнует скорость, почитайте, как проверить скорость загрузки сайта в Яндексе — боты часто незаметно её съедают.

Главная ловушка: .htaccess может слететь через три недели

А теперь урок, за который я заплатил на другом своём сайте. Там я тоже поставил блок в .htaccess, порадовался результату и забыл про него. Через три недели боты вернулись — трафик снова пополз вверх. Я полез в файл и обнаружил, что моего блока в нём нет. Он просто исчез.

Причина в том, что .htaccess — файл нежный, и его любят перезаписывать:

• Плагины кэширования и SEO-плагины (в WordPress это делают многие) переписывают .htaccess «под себя», затирая ваши ручные правки.
• Восстановление из бэкапа откатывает файл к состоянию до блокировки — и блок пропадает.
• Обновление CMS или движка может сгенерировать .htaccess заново.
• Панели управления хостингом иногда перезаписывают файл при смене настроек PHP или SSL.

Вывод простой: .htaccess — это не то место, где блок будет жить вечно. Он отлично подходит, чтобы закрыть атаку прямо сейчас, за минуту, без доступа к конфигам сервера. Но как надёжное долгосрочное решение он ненадёжен. Поэтому серьёзный блок нужно дублировать уровнем выше — в конфиге nginx.

Дублируем блок в nginx — чтобы держался намертво

nginx — это тот самый сервер, который на большинстве хостингов стоит первым и принимает запросы раньше Apache. Блок в его конфиге не перезапишет ни один плагин WordPress, ни один бэкап сайта — потому что конфиг nginx лежит вне папки сайта, куда плагины не дотягиваются. И работает он даже эффективнее: nginx отсекает бота на самом входе, до того как запрос вообще дойдёт до тяжёлого PHP.

Блок в конфиге сервера (в секции server или в отдельном подключаемом файле) выглядит так:

deny 91.142.85.0/24;
deny 45.135.94.0/24;
deny 81.29.135.0/24;
deny 81.29.136.0/24;
deny 109.248.57.0/24;
deny 37.77.107.0/24;
deny 2a00:f2a0::/32;

После правки конфига nginx нужно перезагрузить (командой nginx -s reload или через панель хостинга) — и блок вступит в силу без остановки сайта. Идеальная схема: держите блок и в .htaccess (быстро, под рукой), и в nginx (надёжно, не слетит). Так вы защищены с двух сторон. Настройка конфигов сервера — как раз та задача, которую логично делегировать: это часть доработки сайта, которую я делаю под ключ.

Когда одного .htaccess мало: российские анти-бот-решения

Ручная блокировка подсетей идеальна, когда атака идёт с ограниченного числа сетей (как в моём кейсе — шесть штук). Но бывает, что ботовод рассеивает трафик по сотням сетей или переходит в полноценный DDoS — тогда вручную не наугоняешься, придётся дописывать блок каждый день. В такой ситуации разумно подключить специализированный анти-бот-сервис.

Для Рунета я рекомендую именно российские решения — они умеют отличать YandexBot от накрутчика и не гонят трафик за рубеж:

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

Ещё раз подчеркну: Cloudflare для сайта под Яндекс — плохая идея. Его JS-проверка регулярно принимает поисковых роботов за ботов, из-за чего сайт вылетает из индекса. Для Рунета берите отечественные решения либо оставайтесь на ручной блокировке, если атака компактная.

Отдельный случай: накрутка CTR, которую нельзя заблокировать на сервере

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

Фокус в том, что на сайт эти боты не заходят. Значит, в Метрике их нет, их IP вы не видите, и блокировать на сервере попросту нечего. .htaccess тут не поможет — цель атаки в самой выдаче, а не на вашем сервере. Такое лечится не блоком, а жалобой в поддержку Яндекса (Платон) и, если накрутку заказал недобросовестный «подрядчик по продвижению», — отказом от его услуг. Я подробно разбирал, как конкуренты пытаются выдавить сайт из ТОП-1 именно такими методами негативного SEO.

Чек-лист: проверьте себя перед и после блокировки

Собрал короткий список, по которому удобно пройтись, чтобы ничего не забыть и не уронить сайт.

1. Сделал резервную копию исходного файла .htaccess.
2. Проверил в access.log, что Apache видит реальные внешние IP посетителей (а не 127.0.0.1). Если нет — настроил mod_remoteip или блокирую в nginx.
3. Нашёл подсети накрутки: по Logs API Метрики или по группировке адресов в логах сервера.
4. Проверил каждую подсеть через whois — это действительно дата-центр/хостинг, а не сотовый оператор.
5. Убедился, что в списке нет сетей Яндекса (77.88.*) и Google (66.249.*).
6. Вставил блок с правильным синтаксисом: Require not ip для Apache 2.4 или Deny from для 2.2.
7. Не забыл про IPv6-диапазон.
8. Сохранил файл и открыл сайт — убедился, что он работает (нет ошибки 500).
9. Через час посмотрел в Метрику/логи — трафик с бот-сетей упал.
10. Продублировал блок в конфиге nginx, чтобы он не слетел через три недели.
11. Поставил напоминание раз в неделю проверять, не появились ли новые бот-сети.

Если после всех шагов трафик не изменился — почти наверняка вы блокируете, но Apache не видит реальный IP (вернитесь к шагу 1) либо у вас не поведенческая накрутка, а CTR-накрутка в выдаче (её на сервере не берут). А если хочется разобраться, не наложен ли на сайт фильтр и что вообще происходит с позициями, начните с материала о том, что влияет на позиции сайта в выдаче.

Вывод

Накрутка поведенческих факторов — неприятная, но решаемая проблема. Когда атака идёт с ограниченного числа дата-центровых подсетей (а так бывает чаще всего — ботоводы экономят на серверах), её можно обрубить за час прямо руками, через .htaccess. Главное — блокировать по подсетям, а не по отдельным адресам, проверить, что сервер видит реальный IP, не забыть про IPv6 и обязательно продублировать блок в nginx, чтобы он не слетел. Поисковые роботы и живые клиенты при грамотной блокировке не страдают вообще.

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