Боты хорошие и боты плохие: как различать, использовать и блокировать

Боты – это тема, к которой мы обращаемся уже не в первый раз. И, определенно, мы будем к этой теме возвращаться. Но сегодня мы от конкретики вернемся к теории и попробуем понять для себя, что есть хороший бот и что есть плохой бот. И, соответственно, определим методы обращения с ними.

В рамках данной публикации мы будем использовать термин бот, хотя в сети существуют и другие: робот, краулер, спайдер, или более специфичные (парсер, скрейпер, червь).

Чем хороший бот отличается от плохого

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

• хороший бот подчиняется принятым правилам, не скрывает себя и предоставляет возможность отказаться от своих “услуг”,
• плохой бот никаких правил не признает, скрывает или подделывает свой User-Agent (спуфинг) и выполняет свои задачи независимо от вашего желания.

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

В данном контексте нас интересует 4 вида ботов:

• поисковые боты,
• ИИ-боты,
• скрейперы (скреперы), парсеры и прочие вредоносные боты.

Уровень “хорошести” или позитивности данных ботов уменьшается по мере продвижения по списку. Об этом и поговорим.

Поисковые боты

Веб-краулеры или поисковые роботы представляют собой программный код, выполняющий поиск, сканирование и индексирование контента. Кроме поисковых ботов у поисковых систем отсутствуют другие объективные инструменты для для поиска и формирования базы онлайн-контента.

Владельцы проектов могут помочь поисковикам в индексации с помощью карты сайта, но ее верифицируют все те же поисковые боты.

Без доступа к вашему сайту поисковый бот не сможет получить необходимую информацию о его контенте. В результате ваш проект или “вылетит” из индекса или не попадет в него, не говоря уже о ранжировании и попадании на высокие позиции.

Тем не менее, есть нюансы, о которых мы говорили ранее. Дело в том, что существуют поисковые системы, предназначенные для определенных категорий пользователей по языковому признаку. Хороший пример – китайская Baidu. Если ваш проект не предполагает локализации контента под потребителя из Поднебесной, вам совершенно не понадобятся переходы из данного поисковика с высоким процентом отказов. А присутствие ботов Baiduspider в любых количествах не сделает статистическую картинку более ясной и понятной.

Но если Baiduspider вы увидите все же редко, то какой-нибудь PetalBot может заходить на страницы вашего проекта в товарных количествах и не просто без какой-либо пользы, а даже немного наоборот.

Несмотря на некоторую назойливость, поисковые боты в подавляющем большинстве являются “послушными”, т. е. “уважают” директивы robots.txt. Соответственно, существует возможность запретить для них доступ к вашему проекту по схеме:

# Запрещаем Amazonbot
User-agent: Amazonbot
Disallow: /

Все бы и нечего, но Robots Exclusion Protocol имплементирован по умолчанию как разрешительный. 

Иными словами, все, что в robots.txt не запрещено, является разрешенным. 

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

ИИ-боты

Повышаем градус негатива и переходим к ИИ-краулерам, которые индексируют ваш контент для:

• формирования ИИ-ответов,
• составления отзывов,
• обучения моделей.

Естественно, возникает вопрос: а нужно ли мне оно? Коммуницирование с AI в принципе не предполагает ни продвижения, ни ранжирования, ни переходов по ссылкам. Другое дело – поисковые нейронки, которые действуют по принципу не прижившихся у нас турбостраниц. Фактически, мы видим весьма бесперспективную для владельца сайта схему:

• ИИ-бот индексирует ваш контент,
• на основе собранных данных поисковик формирует в выдаче ИИ-ответ на пользовательский запрос,
• получив необходимую (но не факт что правильную) информацию, счастливый пользователь закрывает сессию.

Да, при этом в ИИ-ответе присутствуют какие-то мелкие (и не очень) ссылочки, причем некоторые из них открывают блок со сниппетами источников. Но сколько шансов на то, что уже получивший ответ пользователь будет кликать чтобы куда-то перейти?

Конечно, есть и ситуации, когда вклинивание ИИ в поисковую выдачу слегка нивелируется. Например, такие:

Но вот лично мне очень жаль, например, владельцев сервиса Stack Overflow, которые в одно прекрасное утро проснулись и увидели, что лишились примерно 95% органического трафика.

Что же нам предлагают взамен? Ожидаемо, это лишь ИИ-видимость и ИИ-узнаваемость бренда. Но ее, как показывает пример выше, на хлеб не намажешь. Так что можно утверждать, что если работа вашего проекта завязана на предоставление уникального или важного контента, AI-боты лучше блокировать. Но под такую трактовку попадают практически все легитимные сайты. Что же делать их владельцам?

Хорошая новость состоит в том, что ИИ-боты соблюдают директивы robots.txt, плохая – в том, что это их соблюдение не является ни обязательным, ни обязывающим. 

Отличный пример – сервис Internet Archive, который в 2017 году перестал учитывать robots.txt, по той лишь причине, что он “перестал удовлетворять задачам архивирования”.

Так что, Robots Exclusion Protocol не станет помехой: ни один из источников, в том числе официальных, не гарантирует что ИИ-боты не смогут добраться до вашего контента. Блокировка не помешает системам искусственного интеллекта формировать ответы с использованием вашего контента, а лишь незначительно повлияет на обучение.

Вредоносные боты

Без них, конечно, никуда. И здесь ассортимент просто огромен: это и скрэйперы и спам-боты и SEO-анализаторы и много других веб-насекомых.

Одни из наиболее неприятных для владельцев сайтов являются боты, предназначенные для неавторизованного копирования вашего контента. Это скрэйперы и парсеры. 

Первые выполняют задачи по скачиванию вашего контента “как есть”, вторые разбирают и структурируют его, часто с использованием шаблонов с HTML-элементами. С помощью таких ботов ваши конкуренты могут, например, получать прайс-листы ваших товаров и услуг. Или скачивать тематический контент из блога или новостной ленты.

Профит здесь сомнительный и неоднозначный: подобные вещи необходимы для как для анализа предложений конкурентов, так и для массового угона текстового материала. При оперативной индексации нового контента с первоисточником проблемы вряд ли возникнут. Тем не менее, как говорится, возможны варианты (например, потеря конкурентного преимущества). К тому же, нагрузки на сервер тоже никто не отменял.

Еще одним источником проблем для веб-разработчика являются спам-боты, которые сканируют сайт на предмет форм обратной связи, комментариев, откликов и проч. Ну а затем вам приходится регулярно вычищать или обратную связь или опубликованные комментарии с тоннами спамерских ссылок. Странно, но даже в 2026 году такое “наращивание ссылочной массы” не только кто-то предлагает, но и кто-то приобретает.

Дополнительные нагрузки для сайта несут и излишне агрессивные SEO-боты, которые используются веб-сервисами для анализа конкурентов, сбора ключевых запросов и других сомнительных историй. Если анализ логов показывает излишнюю активность, смело блокируйте их по User-Agent или IP-адресу.

Наконец, существуют и чистой воды вредоносные боты, которые пытаются найти точки входа для вашей CMS (например, файл wp-login.php и его аналоги в других CMS) и попытаться пройти авторизацию, например, грубым перебором паролей. Или банально перегрузить ваш сервер. Для этих историй существуют логи, которые при малейшем подозрении (например, внезапный пик посещений или рост числа отданных страниц) необходимо внимательно анализировать и принимать соответствующие меры.

Как блокировать ботов

Наконец, самое интересное: как противостоять нежелательным действиям, причиной которой являются боты.

Прежде всего, мы говорим о файле robots.txt. Конечно, это первая линия обороны – авангард, который боты сомнут без больших проблем. Тем не менее, все необходимые директивы стоит добавить. И чем раньше, тем лучше. Блокировать необходимо в первую очередь нежелательных поисковых ботов. Например:

User-agent: Baiduspider
Disallow: /

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

User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

Как мы уже говорили выше, robots.txt не является для ботов истиной в последней инстанции, поэтому если у вас на глазах боты начинают порабощать ваш проект, используйте кавалерию в лице .htaccess – радикального средства для борьбы с отдельным ботом:

<IfModule mod_rewrite.c>
	RewriteCond %{HTTP_USER_AGENT} PetalBot [NC]
	RewriteRule .* - [F,L]
</IfModule>

… или сразу с несколькими:

<IfModule mod_rewrite.c>
	RewriteCond %{HTTP_USER_AGENT} (PetalBot|Amazonbot) [NC]
	RewriteRule .* - [F,L]
</IfModule>

Конечно, все это при уверенности в том, что вы используете правильный User-Agent. Если ее нет, используйте обратный поиск по DNS. В противном случае, ваш единственный выход – блокировка IP-адресов или IP-диапазонов:

RewriteCond %{REMOTE_ADDR} ^213\.226\.101\.
RewriteRule . - [F,L]

Ловить спам-ботов по IP-адресам будет малопродуктивно. Поэтому либо точечно блокируем гостевые комментарии, либо делаем их модерируемыми (подробно о запрете комментариев).

Вместо заключения

При отсутствии в настоящее время серьезных механизмов контроля над ботами, ваш инструментарий будет ограничен. По одну сторону это малопродуктивный robots.txt, по другую – действенный (но не резиновый) .htaccess плюс довольно трудоемкая процедура идентификации ботов.

Для серьезных нагруженных проектов существует CloudFlare и аналогичные решения. Однако, до полной эффективности здесь тоже далеко, и пока что перевес явно не на стороне владельцев сайтов.

Ранее мы выясняли важность работы с логами для безопасности сайта.