GPTBot и другие AI-краулеры: кто ходит на ваш сайт и как этим управлять

AI-краулер это не одна сущность, а три разных механизма, которые часто носят имя одного владельца и различаются только строкой User-Agent. Разница между ними определяет, что именно вы потеряете, закрыв доступ.

Роль 1: сбор данных для обучения. Бот обходит сайт массово, складывает текст в корпус, на котором позже обучают или дообучают модель. Эффект отложенный и непрозрачный: вы не увидите ни перехода, ни ссылки. Ваши тексты могут повлиять на то, что модель "знает" о вашей категории, но проверить это по логам нельзя.

Роль 2: индексация для ответа с поиском. Когда ассистент отвечает на вопрос и подтягивает свежие источники, он берёт их из собственного поискового индекса. Индекс наполняет отдельный бот. Если вас нет в этом индексе, вас не будет в ответах со ссылками, даже если модель обучалась на ваших текстах год назад.

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

У OpenAI этим трём ролям соответствуют GPTBot, OAI-SearchBot и ChatGPT-User. Отсюда главный практический вывод: запрет GPTBot не убирает вас из ответов с поиском, потому что за эти ответы отвечает другой бот с другим именем и с отдельной группой правил в robots.txt. А вот запрет OAI-SearchBot убирает: закрыв индексирующего бота, вы выпадаете из выдачи, на которую ассистент опирается при ответе.

Ниже сырые данные из access-логов visiobrand.io за окно с 11 по 20 августа 2026 года. Считаем строки журнала по подстроке в User-Agent, без верификации происхождения (о ней ниже).

Три наблюдения из этой таблицы.

Поисковых обращений больше, чем обучающих. OAI-SearchBot опережает GPTBot в 2,5 раза. Логика понятна: обучающий корпус собирают волнами, а поисковый индекс поддерживают в свежем состоянии постоянно. Для сайта, которому нужны ссылки в ответах, важнее второй бот.

Applebot и YandexBot никуда не делись. Applebot старше нынешней волны ассистентов, он собирает данные для Siri и Spotlight. Отдельный токен Applebot-Extended управляет только использованием контента для обучения и не влияет на выдачу в поиске Apple. YandexBot это классический поисковый краулер, и ответы с поиском в экосистеме Яндекса строятся на том же индексе, поэтому его запрет бьёт сразу по двум сценариям.

Google-Extended в логах это аномалия. Google-Extended задуман как управляющий токен в robots.txt, а не как отдельный краулер, который представляется этим именем. Восемнадцать строк с таким User-Agent почти наверняка либо сканеры, проверяющие реакцию сайта, либо подделки. Это первый повод не доверять счётчику по строке.

Разберём тройку подробнее, потому что именно вокруг неё больше всего путаницы.

GPTBot обходит сайт для сбора обучающих данных. Он уважает robots.txt, слушает группу User-agent: GPTBot, ходит планово и большими сериями. Никакого трафика он не приносит и не может принести: у обучающего обхода нет обратной ссылки.

OAI-SearchBot наполняет индекс, из которого берутся источники для ответа с поиском. Это тот бот, от которого зависит, попадёте ли вы в список ссылок под ответом. У него своя группа правил и свой набор адресов.

ChatGPT-User приходит в момент, когда пользователь в диалоге просит открыть страницу. Один запрос, никакого обхода. Важная деталь: такой запрос забирает HTML, который отдал сервер. Если содержимое собирается только на клиенте скриптами, бот увидит пустой каркас.

Отсюда рабочая схема для большинства сайтов: закрыть GPTBot, если вы принципиально против использования текстов в обучении, и оставить открытыми OAI-SearchBot и ChatGPT-User, чтобы не терять ссылки и переходы. Обратная комбинация (открыть обучающего, закрыть поискового) не имеет практического смысла почти никогда.

У Google логика похожая, но названия сбивают с толку.

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

GoogleOther это универсальный краулер для внутренних задач и разовых обходов, не связанных с наполнением основного поискового индекса. В нашем журнале он на втором месте с 1 952 обращениями. Запрет GoogleOther не выбивает сайт из поисковой выдачи, но и заметной пользы от запрета обычно нет, кроме экономии трафика.

Google-Extended это не бот, а управляющий токен. Он не ходит по сайту сам. Он говорит Google, можно ли использовать уже полученный Googlebot контент для обучения и для генеративных ответов Gemini. Ключевое следствие: Disallow для Google-Extended не влияет на обычную индексацию и на ранжирование в поиске, потому что страницы всё равно забирает Googlebot по своим правилам. Это единственный безопасный способ отказаться от обучения на своих текстах у Google, не жертвуя поиском.

Отдельно про AI Overviews и AI Mode: эти поверхности строятся поверх обычного поискового индекса. Управлять их присутствием отдельным токеном нельзя, отказ от Google-Extended на них не распространяется.

Четыре имени, которые регулярно попадают в списки "разрешить, вдруг пригодится".

Bytespider (ByteDance). Третье место в нашем журнале, 1 335 обращений. Это обучающий краулер, у него нет пользовательской поверхности, которая вернула бы вам ссылку или переход. Он даёт нагрузку и не даёт видимости. Если решите закрывать, обязательно проверьте по логам через неделю, снизилась ли активность: обучающие боты сторонних компаний соблюдают robots.txt не всегда, и тогда запрет придётся переносить на уровень сервера.

meta-externalagent (Meta). 1 124 обращения. Собирает данные для обучения и продуктов компании. Обратной ссылки в ответе российскому пользователю ждать не приходится, ценность обмена низкая.

Amazonbot (Amazon). 166 обращений. Обслуживает сервисы Amazon, включая ответы голосового ассистента. Для магазина, продающего на площадках Amazon, смысл есть. Для российского B2B-сайта эффект близок к нулю.

CCBot (Common Crawl). 176 обращений. Особый случай: это не модель и не поисковик, а некоммерческий проект, который собирает открытый корпус веб-страниц. На этом корпусе учатся многие модели, а также его используют исследователи и SEO-инструменты. Запрет CCBot закрывает вас сразу от всех, кто берёт данные оттуда, но только для будущих обходов: уже собранные архивы остаются доступными и никуда не исчезают. Быстрого эффекта от запрета не будет.

Файл лежит строго в корне домена и отдаётся с типом text/plain и кодом 200. Правило действует на схему, хост и порт, для поддомена нужен свой файл.

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

# Обучающие краулеры и управляющие токены обучения
User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: meta-externalagent
Disallow: /

# Индексация для ответов с поиском и переходы пользователей
User-agent: OAI-SearchBot
Allow: /
Disallow: /app/
Disallow: /admin/

User-agent: ChatGPT-User
Allow: /

User-agent: PerplexityBot
Allow: /
Disallow: /app/
Disallow: /admin/

User-agent: DuckAssistBot
Allow: /

# Все остальные
User-agent: *
Disallow: /app/
Disallow: /admin/
Disallow: /*?utm_
Allow: /

Sitemap: https://example.ru/sitemap.xml

Если задача обратная и вы хотите отдавать всё всем, кроме личного кабинета, достаточно одной группы User-agent: * с перечислением закрытых каталогов. Плодить группы под каждого бота имеет смысл только тогда, когда правила для них действительно разные.

Правило выбора группы. Бот читает файл сверху вниз и выбирает ровно одну группу: ту, где его имя указано явно. Группа User-agent: * применяется только к тем, для кого именной группы нет. Это самая дорогая ошибка в теме.

Смотрите, что происходит здесь:

User-agent: *
Disallow: /app/
Disallow: /admin/

User-agent: GPTBot
Crawl-delay: 5

Автор хотел просто притормозить GPTBot. Фактически он открыл ему /app/ и /admin/, потому что теперь у GPTBot есть своя группа и правила из * к нему не применяются вообще. Если создаёте именную группу, дублируйте в ней все запреты.

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

User-agent: *
Disallow: /files/
Allow: /files/public/

Другие частые ошибки.

Запрет по звёздочке. Строка User-agent: * с Disallow: / закрывает не только AI-ботов, но и Googlebot с YandexBot. Массовый способ выстрелить себе в ногу при попытке "закрыться от нейросетей".

Каталог со статьями под запретом. Если блог живёт на /blog/ и попал в Disallow, вы одновременно вычеркнули себя из поиска и из ответов ассистентов. Проверяйте, что закрыты именно служебные разделы.

Staging-файл, уехавший в прод. Классика: на тестовом контуре лежит User-agent: * и Disallow: /, при выкатке файл попадает на боевой домен. Поставьте внешнюю проверку, которая раз в час дёргает https://ваш-домен/robots.txt и поднимает алерт, если в ответе встречается Disallow: / без уточнения пути.

robots.txt, который отдаёт SPA. Если фронтенд перехватывает все маршруты, по адресу /robots.txt может прилетать HTML страницы с кодом 200. Для бота это невалидный файл.

Расчёт на то, что robots.txt что-то запрещает технически. Это рекомендация, а не защита. Всё, что не должно уходить наружу, закрывается авторизацией и правилами на сервере.

Все примеры для комбинированного формата логов nginx.

Сводка по всем известным AI-ботам за период:

zcat -f /var/log/nginx/access.log* \
  | grep -Eo 'GPTBot|OAI-SearchBot|ChatGPT-User|PerplexityBot|Perplexity-User|ClaudeBot|Claude-User|CCBot|Bytespider|GoogleOther|Google-Extended|Amazonbot|Applebot|meta-externalagent|YandexBot|DuckAssistBot' \
  | sort | uniq -c | sort -rn

Динамика по дням для одного бота (видно, растёт интерес или падает):

zcat -f /var/log/nginx/access.log* | grep -F 'OAI-SearchBot' \
  | awk '{print substr($4,2,11)}' | sort | uniq -c

Частота внутри суток, по часам:

grep -F 'GPTBot' /var/log/nginx/access.log \
  | awk '{print substr($4,2,14)}' | sort | uniq -c | sort -k2

Какие страницы забирают ассистентские боты:

zcat -f /var/log/nginx/access.log* \
  | grep -E 'GPTBot|OAI-SearchBot|ChatGPT-User|PerplexityBot' \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Коды ответов: если у ботов много 404 и 5xx, вы кормите их ошибками, а не контентом:

zcat -f /var/log/nginx/access.log* | grep -F 'OAI-SearchBot' \
  | awk '{print $9}' | sort | uniq -c | sort -rn

Сколько трафика съедает конкретный бот:

grep -F 'Bytespider' /var/log/nginx/access.log \
  | awk '{s+=$10} END {printf "%.1f MB\n", s/1048576}'

Сколько раз читали robots.txt и кто именно:

grep ' /robots.txt ' /var/log/nginx/access.log | wc -l
grep ' /robots.txt ' /var/log/nginx/access.log \
  | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head

На нашем сайте robots.txt за 10 дней запросили 1 778 раз, из них 260 раз это были перечисленные выше AI-боты. То есть примерно каждый пятидесятый их запрос уходит на проверку правил. Это хороший знак: файл читают регулярно, изменения в нём подхватываются быстро.

Строка User-Agent задаётся клиентом и не проверяется никем. Любой скрипт может назваться GPTBot, и в логах это будет неотличимо от настоящего бота. Практический вывод: все цифры, посчитанные по подстроке, это верхняя граница, а не факт. Наши восемнадцать обращений от Google-Extended, который в принципе не должен появляться в логах как краулер, хорошая иллюстрация.

Проверка по обратному DNS. Работает для Google, Яндекса, Apple и Bing. Берём IP, делаем обратный запрос, получаем имя хоста, затем делаем прямой запрос по этому имени и убеждаемся, что он возвращает исходный IP. Совпало и домен принадлежит владельцу бота, значит бот настоящий.

for ip in $(grep -F 'GoogleOther' /var/log/nginx/access.log | awk '{print $1}' | sort -u); do
  ptr=$(dig +short -x "$ip" | sed 's/\.$//')
  fwd=$(dig +short "$ptr" | tr '\n' ' ')
  printf '%-16s %-45s %s\n' "$ip" "${ptr:-нет PTR}" "$fwd"
done

Для Google валидные суффиксы это googlebot.com и google.com, для Яндекса yandex.ru, yandex.net и yandex.com, для Apple applebot.apple.com.

Проверка по официальным диапазонам. OpenAI публикует списки подсетей отдельными файлами для каждого бота. Скрипт ниже забирает их и помечает строки журнала, чей IP в диапазоны не попадает.

python3 - <<'PY'
import ipaddress, json, re, urllib.request

SRC = {
    "GPTBot":        "https://openai.com/gptbot.json",
    "OAI-SearchBot": "https://openai.com/searchbot.json",
    "ChatGPT-User":  "https://openai.com/chatgpt-user.json",
}
nets = {}
for name, url in SRC.items():
    data = json.load(urllib.request.urlopen(url))
    nets[name] = [ipaddress.ip_network(p[k]) for p in data["prefixes"]
                  for k in ("ipv4Prefix", "ipv6Prefix") if k in p]

ok, fake = 0, 0
with open("/var/log/nginx/access.log", encoding="utf-8", errors="ignore") as f:
    for line in f:
        for name, cidrs in nets.items():
            if name not in line:
                continue
            m = re.match(r"(\S+) ", line)
            if not m:
                break
            ip = ipaddress.ip_address(m.group(1))
            if any(ip in n for n in cidrs):
                ok += 1
            else:
                fake += 1
                print("не из диапазона:", ip, name)
            break
print("подтверждено:", ok, "подозрительных:", fake)
PY

Что делать с подделками: блокировать по IP или отдавать им 403 на уровне сервера. Обратите внимание, robots.txt тут бесполезен, поддельный бот его и так игнорирует.

1 230 запросов в сутки для среднего сайта не проблема. Проблемой это становится, когда бот попадает в раздел с фильтрами и параметрами и начинает генерировать десятки тысяч уникальных адресов, каждый из которых бьёт по базе.

Crawl-delay. Директива не входит в исходный стандарт. Google её игнорирует, Яндекс перевёл управление скоростью в Вебмастер, часть краулеров соблюдает. Ставить можно, но рассчитывать на неё нельзя:

User-agent: Amazonbot
Crawl-delay: 10

Лимит на уровне nginx. Надёжнее и работает против всех, включая подделки:

map $http_user_agent $ai_bot {
    default            "";
    "~*GPTBot"         ai;
    "~*OAI-SearchBot"  ai;
    "~*PerplexityBot"  ai;
    "~*ClaudeBot"      ai;
    "~*Bytespider"     ai;
    "~*CCBot"          ai;
    "~*meta-external"  ai;
}

limit_req_zone $ai_bot zone=aibots:10m rate=30r/m;
limit_req_status 429;

server {
    location / {
        limit_req zone=aibots burst=20 nodelay;
    }
}

Запросы с пустым ключом nginx не учитывает, поэтому обычные посетители под лимит не попадают. Отдавайте именно 429, а не 403: код 429 читается как "приходи позже", а 403 как "сюда нельзя никогда", и вторая формулировка может стоить вам места в индексе.

Почему полный запрет обычно вреднее. Закрыв всё, вы экономите проценты трафика и теряете присутствие в ответах целиком. Масштаб потери видно по нашим замерам цитирования: за 30 дней по 150 отслеживаемым вопросам девять платформ дали 317 045 цитат из 7 978 доменов, при этом на топ-20 доменов приходится 42,2% всех цитат. Ниша, в которую попадают источники, узкая, и добровольный выход из неё конкуренты заметят раньше вас.

Вторая причина в инерции. По нашим замерам срок до первой цитаты нового материала составил 7 дней в Поиске с Алисой, 13 дней в Perplexity, 18 дней в ChatGPT и 79 дней в Gemini, а DeepSeek за период наблюдения не процитировал ни разу. Если вы закрылись и через месяц передумали, возвращаться придётся столько же, и это в лучшем случае.

Здесь данные оказались контринтуитивными. Вот двенадцать самых частых путей у ботов OpenAI и Perplexity за 10 дней.

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

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

Тот же смысл имеют структурированные данные. Разметка Schema.org не заменяет текст, но снимает неоднозначность в фактах, которые модель иначе будет угадывать:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Название компании",
  "url": "https://example.ru/",
  "foundingDate": "2024",
  "areaServed": "RU",
  "description": "Одно предложение о том, что делает компания.",
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "email": "sales@example.ru",
    "availableLanguage": ["ru"]
  }
}
</script>

Держите разметку согласованной с видимым текстом. Расхождение между JSON-LD и содержимым страницы модель разрешает не в вашу пользу.

Идея файла llms.txt звучит логично: положить в корень краткую выжимку для языковых моделей, и они будут читать её вместо того, чтобы разбирать вёрстку. Мы положили такой файл и посмотрели журнал.

Итого 14 обращений за 10 дней. Ни одного от OAI-SearchBot, GPTBot, ChatGPT-User, PerplexityBot и других ассистентских ботов. Для сравнения: robots.txt за тот же период запросили 1 778 раз.

Состав говорит сам за себя. llms.txt читают аудиторские сканеры, которые проверяют наличие файла, сервисы сбора данных о сайтах и люди, которые пришли посмотреть глазами. То есть спрос на файл создаёт индустрия проверок наличия файла, а не сами ассистенты. Никаких публичных подтверждений того, что ассистенты используют llms.txt при ответе, тоже нет.

Что делать: не тратить время. Файл ничего не ломает, но и не даёт ничего. Тот же час работы, вложенный в серверный рендеринг страницы тарифов или в приведение фактов о компании к однозначному виду, окупается измеримо.

1. Откройте свой robots.txt и проверьте, что для каждого именного бота продублированы все запреты из группы User-agent: *.
2. Убедитесь, что файл отдаётся кодом 200 с типом text/plain, а не подменяется страницей SPA.
3. Разведите роли: обучающих ботов закрывайте осознанно, индексирующих для ответов с поиском оставляйте открытыми.
4. Проверьте, что каталоги со статьями и продуктовыми страницами не попали под Disallow.
5. Поставьте внешний мониторинг robots.txt с алертом на строку Disallow: / без пути, чтобы staging-файл не доехал до прода незамеченным.
6. Посчитайте ботов по логам за последние 30 дней, зафиксируйте базовый уровень.
7. Проверьте хотя бы один бот по обратному DNS и один по официальным диапазонам, чтобы понять долю подделок.
8. Посмотрите коды ответов для ботов: доля 404 и 5xx выше нескольких процентов означает, что вы кормите их ошибками.
9. Ограничьте скорость на уровне сервера с отдачей 429, а не полным запретом.
10. Убедитесь, что ключевые страницы отдаются готовым HTML на сервере: ассистентские загрузчики не выполняют клиентские скрипты надёжно.
11. Соберите страницу фактов о бренде и продублируйте ключевые факты разметкой Schema.org.
12. Приведите тарифы, контакты и юридические реквизиты в актуальный вид: по нашим логам это ровно то, за чем боты приходят.
13. Через 30 дней повторите замер по логам и сравните с базовым уровнем.

Проверить, как всё это выглядит со стороны ассистентов, можно на живом мониторинге ответов. Visiobrand снимает ответы девяти платформ: ChatGPT, Gemini, DeepSeek, Perplexity, Google AI Overviews, Google AI Mode, Поиск с Алисой, Алиса AI и GigaChat. Демонстрация доступна по адресу /demo.