Блокировка ботов, скраперов и AI-краулеров через .htaccess

Агрессивные краулеры, сканеры уязвимостей, контент-скраперы и AI-обучатели (GPTBot, ClaudeBot, CCBot, Bytespider, PerplexityBot, Google-Extended) способны съедать трафик, нагружать сервер и брать ваш контент для обучения языковых моделей без какой-либо отдачи. Через .htaccess можно заблокировать их по User-Agent, Referer или IP — ниже готовые блоки для каждого случая. Общие принципы безопасности — в гиде «Безопасность сайта»; автоматически собрать блоки чекбоксами — в генераторе; найти реальных агрессоров в логах — в анализаторе access.log; про блокировку по реферу подробно — статья «Блокировка по Referer».

Блоки написаны для Apache 2.4 (Require-синтаксис). На Apache 2.2 используйте Order/Allow/Deny — сконвертировать поможет конвертер 2.2↔2.4. Синтаксис проверяйте через линтер и аудит.

1. Кто такие «плохие боты» и чем вредят

«Плохие боты» — собирательное название для нескольких категорий автоматических агентов, которые приходят на ваш сайт без пользы для вас (или напрямую во вред):

Агрессивные SEO-краулеры (AhrefsBot, SemrushBot, MJ12bot, DotBot) — анализируют ссылочную базу конкурентов, обходят ваш сайт сотни раз в сутки, генерируют лишний трафик и нагрузку на CPU/диск без каких-либо преимуществ для вас.
Сканеры уязвимостей (Nikto, sqlmap, Nmap, masscan, Nuclei, zgrab, libwww) — ищут незащищённые файлы, SQL-инъекции, слабые пароли. Чаще всего признак подготовки взлома.
Контент-скраперы — копируют ваши тексты, изображения, цены для конкурентов или «мусорных» агрегаторов; создают дубли контента в сети, что может навредить SEO.
AI-краулеры — собирают ваш контент для обучения языковых моделей (LLM) или использования в ответах ИИ без трафика на ваш сайт: GPTBot (OpenAI), ChatGPT-User (OpenAI, при обращении из ChatGPT), ClaudeBot и anthropic-ai (Anthropic), CCBot (Common Crawl — база данных для обучения LLM), Bytespider (ByteDance/TikTok), PerplexityBot (Perplexity AI), Google-Extended (Google — обучение Bard/Gemini), Applebot-Extended (Apple AI), Amazonbot, Diffbot, cohere-ai, FacebookBot, Omgilibot, ImagesiftBot, Timpibot.

Стратегия выбора инструмента: «вежливый отказ» (боты уважающие правила его соблюдут) — robots.txt; жёсткий технический блок (сервер вернёт 403 независимо от желания бота) — .htaccess. Подробнее о выборе — следующий раздел.

2. robots.txt vs .htaccess: когда что использовать

Оба инструмента ограничивают доступ ботов, но работают принципиально по-разному:

robots.txt — вежливая просьба, протокол «исключений роботов». Добросовестные боты (Googlebot, Bingbot, GPTBot, ClaudeBot, CCBot) читают его перед обходом и выполняют. Недобросовестные (сканеры, агрессивные скраперы, самописные парсеры) — игнорируют. Файл публичен, его может прочитать любой — не используйте для скрытия структуры сайта.
.htaccess — жёсткий блок на уровне веб-сервера (Apache). Сервер возвращает 403 или 404 — бот ничего не получает. Работает для любого клиента, которого можно идентифицировать по UA, IP или Referer. Но User-Agent легко подделать (это не криптографическая защита).

Практическая стратегия: robots.txt — для добросовестных ботов (включая AI, если не хотите попадать в обучающие датасеты); .htaccess — для тех, кто robots.txt игнорирует.

Пример robots.txt для отказа AI-краулерам (это не .htaccess — кладётся в корень сайта как robots.txt):

robots.txtкопировать

User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Amazonbot
Disallow: /

Если хотите дополнительно жёстко заблокировать их на уровне Apache — используйте блок по User-Agent из следующего раздела вместе с robots.txt.

3. Блокировка по User-Agent

Самый распространённый метод. Два варианта в .htaccess:

Вариант 1: через mod_setenvif — рекомендуется для длинных списков (не страдает от ограничений на длину строки в mod_rewrite):

.htaccessкопировать

SetEnvIfNoCase User-Agent "(nikto|sqlmap|nmap|masscan|zgrab|nuclei|libwww|python-requests|scrapy|httpclient|AhrefsBot|SemrushBot|MJ12bot|DotBot)" bad_bot
<RequireAll>
    Require all granted
    Require not env bad_bot
</RequireAll>

Вариант 2: через mod_rewrite — удобен, если уже используете RewriteEngine On:

.htaccessкопировать

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (nikto|sqlmap|nmap|masscan|zgrab|nuclei|libwww|python-requests|scrapy|AhrefsBot|SemrushBot|MJ12bot|DotBot) [NC]
RewriteRule .* - [F]
</IfModule>

Блокировка AI-краулеров (отдельный список — добавляйте осознанно, если не хотите попадать в LLM):

.htaccessкопировать

SetEnvIfNoCase User-Agent "(GPTBot|ChatGPT-User|CCBot|anthropic-ai|ClaudeBot|Claude-Web|Bytespider|PerplexityBot|cohere-ai|Diffbot|FacebookBot|Google-Extended|Applebot-Extended|Amazonbot|Omgilibot|ImagesiftBot|Timpibot)" ai_bot
<RequireAll>
    Require all granted
    Require not env ai_bot
</RequireAll>

Грабли с User-Agent: UA тривиально подделать — это фильтр от «ленивых» ботов, а не криптографическая защита. Настоящие злоумышленники просто сменят UA.
Флаг [NC] в mod_rewrite обязателен (case-insensitive); SetEnvIfNoCase нечувствителен к регистру по умолчанию.
Не используйте слишком общие слова: bot, crawler, http, python целиком — случайно заблокируете Googlebot, Bingbot, соцсети-превью. Блокируйте по точным именам.
Длинные цепочки [OR] в mod_rewrite хуже читаются и могут упереться в ограничения; предпочтительнее SetEnvIfNoCase для больших списков.
Готовый список сканеров и AI-краулеров с чекбоксами — генератор (блок «Блокировка ботов»); подробнее о безопасности — центр безопасности → раздел «Боты».

4. Блокировка по Referer (хотлинк, спам-рефереры)

Хотлинк картинок (чужой сайт вставляет ваши изображения через прямую ссылку, пожирая ваш трафик) блокируется по заголовку Referer: разрешаем запросы без рефера (закладки, прямые переходы) и запросы с вашего домена, остальным — 403:

.htaccessкопировать

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com [NC]
RewriteRule \.(jpe?g|png|gif|webp|svg)$ - [F]
</IfModule>

Замените example\.com на ваш домен. При необходимости добавьте ещё один RewriteCond для поддомена (!^https?://cdn\.example\.com).

Блокировка конкретных «нежелательных» реферов (например, сайтов-спамеров, с которых приходит трафик, которого вы не хотите):

.htaccessкопировать

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} spam-domain\.ru [NC]
RewriteRule .* - [F]
</IfModule>

Грабли: пустой Referer бывает у легитимных переходов (закладки, переход по HTTPS→HTTP, некоторые браузеры при «режиме приватности») — условие !^$ в анти-хотлинке пропускает их.
Превью соцсетей (Telegram-бот, Twitter/X, Facebook, Discord, Slack) часто не шлют Referer или шлют свой домен — не блокируйте картинки слишком жёстко, иначе потеряете превью.
Ghost referrals (спам-рефереры в Google Analytics) — боты не заходят на ваш сайт, они напрямую подделывают запросы к GA Measurement Protocol. Блокировка в .htaccess тут не поможет — они не обращаются к вашему серверу.
Подробнее про блокировку по реферу — статья «Блокировка по Referer»; готовый блок с вашим доменом — генератор (блок «Защита от хотлинка»).

5. Блокировка по IP и подсети

Самый надёжный метод, если вы знаете IP или диапазон агрессора. Синтаксис Apache 2.4:

.htaccessкопировать

<RequireAll>
    Require all granted
    Require not ip 1.2.3.0/24
    Require not ip 5.6.7.8
</RequireAll>

Для Apache 2.2 — Order allow,deny / Deny from 1.2.3.0/24; сконвертировать — конвертер 2.2↔2.4.

Где взять список IP для блокировки: прогоните access.log через анализатор логов — он найдёт топ-IP по числу запросов и предложит готовый блок Require not ip …. Также существуют публичные базы «ферм» ботов и датацентров (AbuseIPDB, IPsum и др.). Блокировка по странам целиком — генератор гео-блокировки.

Грабли: IP меняются. Адрес, принадлежащий сегодня агрессору, завтра может перейти к легитимному пользователю или CDN.
Блокировка подсети /24 (256 адресов) — риск: можно отрезать целого провайдера, мобильного оператора или Tor-выходной узел вместе с обычными пользователями.
Если сайт за Cloudflare или другим прокси, %{REMOTE_ADDR} в Apache = IP прокси-сервера, а не клиента. Реальный IP — в заголовке CF-Connecting-IP (Cloudflare) или X-Forwarded-For. Подробнее — раздел «Cloudflare + .htaccess».

6. Псевдо-Googlebot и реверс-DNS

Распространённая атака: бот выставляет User-Agent Googlebot/2.1, чтобы обойти блоки по UA (многие сайты не блокируют «Googlebot») и получить «краулерскую» версию контента. Как проверить, настоящий ли это Googlebot:

Настоящий Googlebot: реверс-DNS для IP → должен быть *.googlebot.com или *.google.com; затем форвард-DNS обратно → тот же IP.
Для Bingbot: реверс-DNS должен указывать в *.search.msn.com.

В чистом .htaccess реверс-DNS-проверку сделать нельзя — такой директивы в Apache не существует. Для этого нужен либо mod_rewrite с внешним скриптом (RewriteMap prg:), либо mod_security, либо фильтрация на уровне приложения (PHP/Python/и т.д.), либо Cloudflare с опцией «Verified Bots».

Что можно сделать в .htaccess: НЕ блокировать User-Agent Googlebot и Bingbot вообще (они обычно добросовестны); при желании — IP-allowlist из официальных диапазонов Google (публикуются на https://developers.google.com/search/apis/ipranges/googlebot.json), но это десятки постоянно обновляемых подсетей, неудобно поддерживать вручную.

Вывод: реальную проверку подлинности Googlebot делайте не в .htaccess — только на уровне приложения или через CDN/WAF.

7. Кого НЕ надо блокировать

Блокируйте только по точным, известным именам вредителей. Следующих блокировать — значит навредить себе:

Поисковые краулеры: Googlebot, Bingbot, YandexBot (если нужен Яндекс), DuckDuckBot, Baiduspider (если нужен китайский рынок) — без них вы выпадаете из индексов поисковиков.
Превью в соцсетях и мессенджерах: facebookexternalhit, Twitterbot, Slackbot, TelegramBot, WhatsApp, Discordbot, LinkedInBot, Pinterest, vkShare — без них ссылки на ваш сайт в мессенджерах/соцсетях потеряют превью (картинку, заголовок, описание).
Applebot (Siri, Spotlight, Safari Reader) — полезный бот Apple. Не путайте с Applebot-Extended (обучение Apple AI — вот его можно заблокировать).
Сервисы мониторинга: UptimeRobot, Pingdom, StatusCake и т.п. — они следят за доступностью вашего сайта.
Валидаторы: W3C_Validator — нужен при разработке.

Правило: после изменений в блокировках по UA — проверяйте с помощью curl -A "Googlebot/2.1" https://yoursite.com/ и curl -A "facebookexternalhit/1.1" https://yoursite.com/, что они по-прежнему получают 200. Также — Google Search Console → «Проверка URL» с user-agent краулера.

8. Лимит запросов: что есть в .htaccess, а чего нет

В чистом .htaccess настоящего rate-limit'а по числу запросов НЕТ. Это важный момент, который многие упускают.

mod_ratelimit (SetOutputFilter RATE_LIMIT + SetEnv rate-limit 400) ограничивает скорость отдачи данных в КБ/с — это «противодействие Slowloris» и экономия канала, но не ограничение числа запросов в секунду:

.htaccessкопировать

<IfModule mod_ratelimit.c>
    SetOutputFilter RATE_LIMIT
    SetEnv rate-limit 400
</IfModule>

Значение 400 — лимит 400 КБ/с на соединение. Это замедляет скачивание больших файлов, но не помогает против флуда сотнями быстрых запросов.

Настоящий rate-limit по числу запросов реализуется:

mod_evasive — Apache-модуль для защиты от DoS/DDoS; требует root-доступа к серверу (не настраивается через .htaccess).
mod_security (WAF) — правила можно задавать в конфигах, но не в .htaccess на shared-хостинге.
fail2ban — читает логи Apache и банит IP через firewall. Нужен доступ к серверу.
Cloudflare Rate Limiting / CDN — рекомендуется: гибкие правила по IP, пути, методу запроса; не требует доступа к серверу; работает на уровне edge.

Что можно сделать в .htaccess при флуде: заблокировать уже известного агрессора по IP (см. раздел 5, IP найдите через анализатор логов) и ограничить размер запроса (LimitRequestBody).

9. Cloudflare/CDN + .htaccess

Cloudflare (и другие CDN/WAF) фильтрует ботов на edge ещё до того, как запрос попадает на ваш сервер: Bot Fight Mode, WAF-правила, «Verified Bots» (проверка настоящих Googlebot/Bingbot). Это первая линия обороны.

.htaccess на origin-сервере — вторая линия: на случай, если кто-то нашёл прямой IP вашего сервера в обход Cloudflare. Поэтому имеет смысл ограничить origin только IP-адресами Cloudflare:

.htaccessкопировать

# Разрешить только IP-диапазоны Cloudflare (пример — неполный список!)
# Полный актуальный список: https://www.cloudflare.com/ips/ (~22 подсети, обновляется)
<RequireAny>
    Require ip 173.245.48.0/20
    Require ip 103.21.244.0/22
    Require ip 103.22.200.0/22
    Require ip 103.31.4.0/22
    Require ip 141.101.64.0/18
    Require ip 108.162.192.0/18
    Require ip 190.93.240.0/20
    Require ip 188.114.96.0/20
    Require ip 197.234.240.0/22
    Require ip 198.41.128.0/17
    Require ip 162.158.0.0/15
    Require ip 104.16.0.0/13
    Require ip 104.24.0.0/14
    Require ip 172.64.0.0/13
    Require ip 131.0.72.0/22
</RequireAny>

Полный и актуальный список подсетей Cloudflare — на cloudflare.com/ips (около 22 подсетей IPv4 + IPv6, периодически обновляется). Используйте точный список оттуда, а не из этой страницы.

Реальный IP клиента за Cloudflare: %{REMOTE_ADDR} в Apache = IP ноды Cloudflare, а не клиента. Реальный IP клиента — в заголовке CF-Connecting-IP (добавляется Cloudflare). В .htaccess обращение к нему:

.htaccessкопировать

# Только если трафик идёт через Cloudflare — иначе CF-Connecting-IP легко подделать
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:CF-Connecting-IP} ^5\.6\.7\.8$
RewriteRule .* - [F]
</IfModule>

Важно: фильтр по CF-Connecting-IP надёжен только если вы уже ограничили origin IP-диапазонами Cloudflare (см. блок выше). Если кто-то обращается к серверу напрямую — он может подделать этот заголовок.

Восстановить реальный IP в Apache-логах — модуль mod_remoteip с директивой RemoteIPHeader CF-Connecting-IP в конфиге сервера (не в .htaccess).

10. Анти-бот за 10 минут: чеклист

robots.txt есть и настроен (Disallow: / для AI-краулеров, если не хотите в LLM)? — раздел 2
Известные сканеры (Nikto, sqlmap, masscan, zgrab…) заблокированы по UA в .htaccess? — раздел 3, генератор
AI-краулеры заблокированы по UA (GPTBot, ClaudeBot, CCBot, Bytespider…), если решили? — раздел 3
Хорошие боты не заблокированы: Googlebot, Bingbot, соцсети-превью — проверено curl -A "Googlebot/2.1"? — раздел 7
Хотлинк картинок закрыт (если нужно)? — раздел 4, генератор
Агрессивные IP из лога заблокированы? — раздел 5, анализатор логов
Для rate-limit'а используете Cloudflare или mod_evasive (а не рассчитываете на .htaccess)? — раздел 8
Синтаксис проверен, аудит пройден? — /check/, /audit/

11. Ссылки и инструменты

Генератор .htaccess — блоки «Блокировка ботов» и «Защита от хотлинка» с чекбоксами.
Анализатор access.log — найдёт топ-IP, подозрительные UA, предложит готовые блоки блокировки.
Центр безопасности → Боты — общий гид по безопасности через .htaccess.
Блокировка по Referer — подробная статья про хотлинк и спам-рефереры.
Линтер .htaccess — проверить синтаксис блокировок.
Аудит безопасности .htaccess — автоматически найти пробелы в защите.
Конвертер 2.2↔2.4 — перевести Order/Allow/Deny в Require.
Рецепты .htaccess → Блокировка ботов · Рецепты → Защита от хотлинка.
Справочник директив → mod_setenvif — подробно про SetEnvIfNoCase.