Кто грузит ваш сайт: как отличить полезного краулера от парсера

Сервер не видит «людей» и «ботов» — он видит поток запросов, где каждый клиент сам решает, как представиться, и пишет это в лог без проверки. Поэтому решения о ботах принимают по самоподписи: кто-то написал «Googlebot», и отчёт посчитал его краулером. Здесь — как установить личность клиента по логу: три уровня доказательства, подтверждение через DNS и списки диапазонов, семь признаков парсера и способ оценить долю автоматики. И цена ошибки: чем рискует тот, кто ставит широкое правило в WAF.

Кто ходит на ваш сайт: семь категорий автоматики

Слово «бот» склеивает семь сущностей с разными мотивами, разной ценностью для бизнеса и разной реакцией на блокировку — и почти все дорогие ошибки начинаются с того, что их не разделили. Ценность обращения определяется не тем, бот это или человек, а тем, чем вы платите за его отсутствие.

User-Agent — самоподпись, а не документ

User-Agent — строка, которую клиент сам о себе пишет в заголовке, и подменяется она одним параметром командной строки, поэтому сама по себе не доказывает ничего. В протоколе нет механизма, заставляющего клиента говорить правду: сервер принимает заголовок как есть и как есть кладёт в лог. Браузер, curl и десять строк на Python одинаково свободны назваться чем угодно.

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.ru/
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/128.0" https://example.ru/

# обе строки легли в access.log как есть, без всякой проверки
203.0.113.77 - - [01/Sep/2026:11:04:12 +0300] "GET / HTTP/1.1" 200 18422 "-" "...Googlebot/2.1..."
203.0.113.77 - - [01/Sep/2026:11:04:19 +0300] "GET / HTTP/1.1" 200 18422 "-" "...Chrome/128.0"

Зачем тогда UA нужен: он делит наблюдения на два потока. «Представился» — заявку проверяют процедурами из следующих разделов. «Не представился» — проверять нечего, остаётся поведение. Отсюда терминология всей статьи: декларация — что клиент о себе сообщил, подтверждение — доказательство из источника, который он не контролирует. Отчёт «по ботам» на одной строке UA считает декларации: сколько клиентов назвались краулером, а не сколько ими были.

Подтверждение через обратный DNS

Заявившегося краулера подтверждают двойной DNS-проверкой: по адресу находят имя хоста, затем проверяют, что имя принадлежит домену вендора и резолвится обратно в тот же адрес. Одного обратного запроса мало: PTR-запись настраивает владелец адреса, и вписать в неё чужое имя технически можно. Прямую запись в зоне вендора подделать нельзя — доказательство не имя, а совпадение двух направлений.

IP=203.0.113.77
NAME=$(dig +short -x "$IP" | sed 's/.$//')   # шаг 1: имя по адресу
echo "PTR: ${NAME:-обратной записи нет}"
# шаг 2: суффикс сверяем с документацией вендора
dig +short "$NAME"                            # шаг 3: должен вернуть тот же $IP

Границы метода: он подтверждает подлинность, но не полномочия; обратные зоны ведут не все вендоры; это сетевой запрос, поэтому результат кэшируют или разбирают логи постфактум. Суффиксы берите в документации вендора, а не в чужой статье.

Подтверждение по диапазонам вендора

Часть вендоров вместо обратных зон публикует машиночитаемые списки своих IP-диапазонов: сверка по списку быстрее DNS-проверки, но требует регулярного обновления файла. Разница в том, где хранится истина: при DNS-проверке — у вендора, при сверке — у вас на диске. Вендор добавляет подсети, устаревший файл — и легитимный краулер с нового адреса уезжает в «заявился, но не подтвердился».

Что читать в логе сервера

Для расследования хватает шести полей стандартного лога: адрес, время, метод и URL, код ответа, размер ответа и User-Agent. Адрес — единственное поле, которое клиент не пишет сам. Время даёт ритм, URL — форму обхода, код ответа — главный вопрос регламента (200 или 403 у подтверждённых краулеров), размер — цену обращения.

# топ адресов
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

# топ User-Agent — это декларации, не факты
awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -20

# распределение кодов ответа
awk '{print $9}' access.log | sort | uniq -c | sort -rn

# сколько мегабайт отдано каждому UA — вот это уже деньги
awk -F'"' '{split($3,a," "); b[$6]+=a[2]} END {for (u in b) printf "%10.1f МБ  %sn", b[u]/1048576, u}' access.log | sort -rn | head -20

Поправка, без которой аналитика неверна: за CDN или прокси в первом поле лежит адрес прокси, а настоящий приходит в заголовке пересылки и должен быть в формате лога — иначе топ адресов состоит из ваших узлов. Проверка кодов ответа для краулеров — пункт общего технического чек-листа.

Парсер, который притворяется браузером

Если клиент объявляет себя обычным Chrome, отличить его от человека по заголовкам невозможно в принципе — здесь заканчиваются доказательства из запроса и начинается работа с поведением. Строка UA берётся из настоящего браузера и ротируется, headless-браузер выполняет JavaScript и принимает cookies, а запросы идут с резидентных адресов, неотличимых от домашних. Отпечатки TLS-рукопожатия существуют, но это инструмент специализированных сервисов, а не панели хостинга.

И про мотивы: снимая позиции сайта сервисом, вы сами заказчик парсинга. За парсингом вашего сайта часто стоит чей-то мониторинг цен, а не атака: повод соразмерять реакцию.

Поведенческие признаки парсера

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

Правило порога: реагируем при совпадении трёх и более признаков на одном источнике. Один признак — гипотеза, три — профиль; проверьте её руками на конкретном адресе, прежде чем делать правилом.

Логи против счётчика

Разница между числом обращений в логах и числом визитов в счётчике за тот же период — самая быстрая оценка автоматического трафика, потому что счётчик считает только тех, кто выполнил JavaScript. Простой HTTP-клиент скрипт не выполняет и в статистику не попадает, а в логе есть всегда. «Логи минус счётчик» — верхняя оценка автоматики плюс люди с блокировщиками. Возьмите одинаковое окно и посмотрите, какая часть разницы объясняется подтверждёнными краулерами, а какая остаётся неопознанной. Интересна вторая.

# только успешные HTML-страницы, без статики
grep ' 200 ' access.log | grep -vE '.(css|js|png|jpe?g|webp|svg|ico|woff2?)( |?)' > html.log
wc -l html.log                                   # всего обращений

grep -icE  'bot|crawler|spider|slurp' html.log   # корзины 1+2: назвались ботом
grep -icvE 'bot|crawler|spider|slurp' html.log   # корзина 3: назвались браузером

# адреса первых двух корзин прогоняем через проверку из раздела 2
grep -iE 'bot|crawler|spider|slurp' html.log | awk '{print $1}' | sort -u

Если счётчик и цели не настроены, сравнивать не с чем — начните с настройки Метрики и целей. Это разовая проверка руками, а не постоянный мониторинг AI-трафика. И не превращайте результат в универсальную цифру: она верна только для вашего сайта и за это окно.

Сколько ресурсов реально уходит на ботов

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

Дорогой бот указывает не на бота, а на дефект структуры. Если обход генерирует сотни тысяч адресов, смотрите на то, что он нашёл: обычно это комбинаторный взрыв на фильтрах, тема структуры каталога и фильтров. Блокировка уберёт симптом, адреса останутся. Заодно проверьте Core Web Vitals: они меряются на живых визитах и проседают, когда сервер занят.

Три реакции: лимитировать, удешевить, заблокировать

Порядок реакции такой: сначала удешевить ответ кэшем, затем ограничить частоту и только потом блокировать — адресно и с датой пересмотра правила. Приоритет: сначала удешевляем, потом лимитируем, блокируем только адресно и с датой пересмотра.

Про robots.txt здесь одна мысль: это просьба, а не механизм принуждения — тот, кто парсит вас вопреки правилам, файл не читает. Кого и как в нём закрывать — в статье про robots.txt для AI-ботов.

Цена широкого правила

Обращения от AI-систем делятся на три вида с разной коммерческой ценностью, а правило «резать ботов» бьёт по всем трём одинаково — включая то, за которым стоит живой человек, уже спросивший про вас.

• Краулер сбора впрок. Ходит независимо от чьих-либо вопросов. Потеря отложенная и трудноизмеримая.
• Краулер реального времени. Забирает страницу в момент формирования ответа. Отказ — «источник недоступен» в ответе, который читают сейчас.
• Агент по поручению пользователя. Идёт по ссылке от имени человека: блокируя его, вы блокируете не бота, а клиента, которого к вам привели.

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

Регламент проверки правил

После каждого изменения правил проверьте три вещи: коды ответов для подтверждённых краулеров в логах, доступность страниц в панелях вебмастеров и живой запрос с внешнего адреса.

• У каждого правила есть автор, причина и дата пересмотра. Записанные там же, где само правило, а не в переписке.
• Неделя наблюдения. Если платформа даёт режим «только логировать», новое правило неделю живёт в нём.
• Ежедневный отчёт по 403 и 429 для подтверждённых краулеров. Там должен быть ноль; любая строка разбирается в тот же день.
• Проверка ключевых страниц в панелях вебмастеров. Вручную, по десятку страниц, которые приносят деньги.
• Контрольный запрос со стороннего адреса. Не из офиса, чей IP давно в белом списке.
• Проверка без cookies и без JavaScript. Именно так страницу видит краулер.

Типичные ошибки

Почти все дорогие ошибки сводятся к одному: правило приняли по декларации, а не по подтверждению, и не поставили дату пересмотра.

• Верить User-Agent без проверки. Отчёты считают самоподписи, решения — по вымышленным данным.
• Блокировать по подстроке «bot» или облачные диапазоны целиком. Отсекаются честные краулеры, включая AI-ботов из тех же облаков; парсер под видом Chrome не задет вовсе.
• Отвечать 403 там, где нужен 429. Краулер читает это как запрет доступа, а не как «зайди позже».
• Включить «защиту от ботов» и не посмотреть, кого она режет. Падение потом объясняют чем угодно, кроме галочки.
• Реагировать на один поведенческий признак. Под правило попадают люди с блокировщиками и ваш мониторинг.
• Считать долю ботов в запросах. Дешёвый выглядит страшно, дорогой прячется за скромным числом обращений.
• Не оставлять причину, автора и дату пересмотра. Через год правило боятся трогать.
• Хранить логи сутки. Месячную аномалию расследуют по памяти, то есть никак.
• Искать бота вместо починки структуры URL, которая его кормит. Симптом уходит, причина остаётся.
• Путать парсера с посетителем, приведённым агентом. Во втором случае вы отказываете клиенту, а не роботу.

Что в итоге

Распознавание сводится к трём уровням: User-Agent даёт гипотезу, DNS-проверка или официальный список диапазонов её подтверждает, а тем, кто не заявляется вовсе, остаётся поведенческий профиль. Принцип один: доверять подтверждению, а не декларации. Всё, что построено на самоподписи клиента, — учёт намерений, а не фактов.

Вторая часть дела — экономика. Меряйте нагрузку в отданных байтах и времени генерации: часто выяснится, что закэшировать дешевле, чем воевать. Дорогой бот указывает на дефект структуры сайта — он не создаёт сотни тысяч адресов, он их находит.

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

Что сделать на этой неделе: продлить хранение логов; снять сводку по трём корзинам за сутки; проверить, что подтверждённые краулеры получают 200, а не 403; прочитать, что включено в «защите от ботов» у хостера или CDN.