Чьи хостинги режут роботов нейросетей: проверили 19 провайдеров — может, там есть ваш?

Мы в IT Panda делаем сайты на 1С-Битрикс и внедряем Битрикс24. В сентябре решили всерьёз заняться тем, как нас видят нейросети: что о нас знают ChatGPT, Perplexity и Алиса и откуда они это берут. Прежде чем предлагать такую работу клиентам, решили пройти весь путь на своём сайте. Первый шаг очевидный: убедиться, что роботы нейросетей вообще доходят до сайта.

Оказалось, что не доходят.

Что мы увидели

Мы выгрузили журнал сервера за две недели сентября и стали искать роботов. Яндекс и Google ходили как обычно. От OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User) и от Bing не нашлось ни одного настоящего запроса. Строки с подписью «GPTBot» в журнале были, но все с чужих адресов.

Это не мелочь. ChatGPT, по данным самой OpenAI, пользуются 900 миллионов человек в неделю (февраль 2026 года). В России, по данным Mediascope за сентябрь 2026 года, нейросетями пользуется больше половины населения. Bing к тому же поставляет поисковую выдачу для части ответов ChatGPT. Для всех этих сервисов нашего сайта не существовало, и мы об этом не знали: в панели хостинга ничего не видно, Вебмастер Яндекса и Search Console спокойны.

Насколько велика эта часть трафика, стало видно потом. За первую неделю после того, как мы всё починили, настоящие роботы нейросетей сделали к сайту 3 745 запросов. Googlebot за ту же неделю сделал 1 856.

Как отличить настоящего робота от подделки

Первое, чему пришлось научиться. Подпись в User-Agent может поставить кто угодно: у нас за одну неделю набралось 17 поддельных «GPTBot» и 47 поддельных «Claude-User». OpenAI и Microsoft публикуют диапазоны адресов своих роботов в JSON:

• openai.com/gptbot.json
• openai.com/searchbot.json
• openai.com/chatgpt-user.json
• bing.com/toolbox/bingbot.json

Скрипт ниже считает настоящие и поддельные запросы в журнале доступа в формате combined (адрес клиента первым полем):

import ipaddress, json, sys, urllib.request

LISTS = {
    'GPTBot': 'https://openai.com/gptbot.json',
    'OAI-SearchBot': 'https://openai.com/searchbot.json',
    'ChatGPT-User': 'https://openai.com/chatgpt-user.json',
    'bingbot': 'https://www.bing.com/toolbox/bingbot.json',
}
nets = {}
for bot, url in LISTS.items():
    data = json.load(urllib.request.urlopen(url, timeout=30))
    nets[bot] = [ipaddress.ip_network(p.get('ipv4Prefix') or p.get('ipv6Prefix'))
                 for p in data['prefixes']]

stat = {bot: [0, 0] for bot in LISTS}
for line in open(sys.argv[1], errors='replace'):
    try:
        ip = ipaddress.ip_address(line.split(' ', 1)[0])
    except ValueError:
        continue
    low = line.lower()
    for bot in LISTS:
        if bot.lower() in low:
            real = any(ip in n for n in nets[bot])
            stat[bot][0 if real else 1] += 1

for bot, (real, fake) in stat.items():
    print(f'{bot}: настоящих {real}, поддельных {fake}')

Запуск: python3 bots_check.py access.log. У нас по OpenAI и Bing вышло ноль настоящих за 14 дней.

Начали разбираться

Наш сайт стоит на общем хостинге NetAngels. Первым делом проверили, как сайт отвечает на имена роботов:

curl -s -o /dev/null -w '%{http_code}\n' -A "bingbot/2.0" https://example.ru/robots.txt
curl -s -o /dev/null -w '%{http_code}\n' -A "Bingbot/2.0" https://example.ru/robots.txt

С подписью bingbot или GPTBot соединение обрывалось, а Bingbot или gptbot в другом регистре проходил. Значит, на входе стоит правило под точные имена роботов.

Написали в поддержку, правило сняли. Ждём сутки: роботов по-прежнему ноль, живая проверка страницы в Bing Webmaster падает с ошибкой.

Помогло сравнение. У нашего клиента сайт стоит у того же провайдера, в той же автономной системе, но на VDS. За те же 14 дней к нему пришли Bing с 6 595 запросами, GPTBot с 556 и OAI-SearchBot со 143. К нам на общий хостинг: 0, 0 и 0. Сеть одна, разница только в типе хостинга.

Переписка с поддержкой

Переписка заняла три письма.

Первое: ограничений для сетей bingbot и GPTBot нет, единственную блокировку по User-Agent сняли.

Мы отправили цифры соседнего VDS. Второй ответ объяснил разницу: на VDS трафик приходит напрямую, а на общий хостинг через систему защиты Mitigator. И добавили, что если трафик до их защиты режет РКН, они этого не увидят и повлиять не могут.

Тогда мы спросили, можно ли добавить в белый список Mitigator сети из официальных списков Bing и OpenAI. Ответ: адрес общий для многих клиентов, вывести его из-под защиты нельзя. Единственный вариант без переезда поддержка предложила сама: направить домен на свой VDS и пересылать запросы с него на хостинг.

Как решили через VDS

Взяли самый маленький VDS у того же провайдера за 403 ₽ в месяц, поставили Debian и nginx как обратный прокси, выпустили сертификат Let's Encrypt и переключили DNS на VDS. Сайт остался на хостинге, переносить ничего не пришлось. Основная часть конфига:

upstream hosting {
    server 203.0.113.10:443;   # адрес общего хостинга
    keepalive 16;
}

server {
    listen 443 ssl;
    http2 on;
    server_name example.ru;
    ssl_certificate     /etc/nginx/cert/fullchain.pem;
    ssl_certificate_key /etc/nginx/cert/privkey.pem;

    location / {
        proxy_pass https://hosting;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host example.ru;
        # заменяем заголовок целиком, чтобы клиент не мог подставить свой адрес
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
        proxy_ssl_server_name on;
        proxy_ssl_name example.ru;
        proxy_ssl_verify on;
        proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
        proxy_ssl_verify_depth 3;
    }
}

По дороге нашлись три подводных камня:

• X-Forwarded-For. Входной сервер хостинга берёт адрес посетителя из первого значения X-Forwarded-For от любого клиента. Любой мог бы подставить чужой адрес в обход лимитов и банов сайта. Поэтому на прокси заголовок заменяется целиком, а в коде сайта принимается только от адреса прокси.
• Фильтр по странам. Хостинг определял страну по адресу подключения, и через прокси все запросы стали «из России». Фильтр перенесли на прокси (GeoIP2 и бесплатная база db-ip Lite с обновлением раз в месяц).
• Сертификат. Проверка Let's Encrypt через хостинг не проходила по таймауту, поэтому первый сертификат выпустили через DNS-01, а продление идёт через webroot на прокси.

Скорость для посетителей из России не изменилась: 0,088 с до первого байта через прокси против 0,084 с напрямую.

Хэппи-энд

DNS переключили вечером 29 сентября. Дальше всё случилось быстро:

• Отправили адреса страниц в Bing по протоколу IndexNow. Через 8 секунд настоящий bingbot забрал файл ключа, хотя до этого Bing не мог даже его проверить.
• 2 октября GPTBot прочитал 366 страниц за три с половиной часа.
• За первую неделю октября настоящие роботы нейросетей сделали 3 745 запросов: GPTBot 2 117, ClaudeBot 1 015, PerplexityBot 473, OAI-SearchBot 123, ChatGPT-User 17. Googlebot за ту же неделю сделал 1 856.
• За неделю 13–19 октября ChatGPT-User открыл наши страницы 114 раз, Claude-User 73, Perplexity-User 21. Эти роботы приходят, когда живой человек задаёт нейросети вопрос и она идёт читать сайт.

Честно о том, чего пока нет. Всё это визиты роботов. Переходов людей из ответов нейросетей пока единицы. Замер 6 октября по девяти вопросам клиентов в ChatGPT, Алисе AI и GigaChat дал одно упоминание нашей компании на 15 ответов. Роботы сайт читают, но в ответах это отражается не сразу. Через месяц допишем сюда новые цифры.

А что у клиентов?

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

Как проверяли. Взяли сайты клиентов у разных провайдеров. С сервера в России запрашивали robots.txt под обычным браузером и под именами роботов, каждый по пять раз с паузой. Повторы оказались важны: у одного хостинга отказ приходит не каждый раз. Где видели отказ, смотрели журналы сайта и сверяли адреса со списками выше, затем писали в поддержку.

Рег.ру: обрыв соединения по имени

Два сайта клиента на двух разных серверах виртуального хостинга вели себя одинаково. Для GPTBot, ClaudeBot, Amazonbot, meta-externalagent, AhrefsBot, SemrushBot, MJ12bot и DotBot соединение закрывается без ответа на любой странице, включая robots.txt и sitemap.xml. curl отдаёт ошибку 52 по HTTP/1.1 и 92 по HTTP/2, так ведёт себя nginx с return 444. Правило учитывает регистр: gptbot строчными проходит.

В журнале сайта эти запросы записаны с кодом 499 и нулём байт, значит, обрывает сам nginx хостинга. В /etc/nginx/conf.d видны файлы 002_ddosguard_ip.conf, 002_stormwall_ip.conf, testcookie.conf, isplimitreq.conf, но сами правила клиенту не читаются.

По журналам за 02–12 октября у настоящего GPTBot оборваны все 325 запросов, у ClaudeBot все 451. Bingbot, OAI-SearchBot, ChatGPT-User и PerplexityBot проходят. Получается, поиск ChatGPT сайт видит, а обучающий робот OpenAI и робот Anthropic нет.

Что ответила поддержка. Открыли сайт всем восьми роботам на следующее утро. Подтвердили, что список стоит в глобальных настройках сервера и клиенту недоступен. Когда его включили, сказать не смогли. Второй сайт клиента открыли отдельной заявкой и только для GPTBot и ClaudeBot: роботов SEO-сервисов и Meta клиент решил оставить закрытыми.

Beget: 503 через раз

На двух сайтах клиентов SemrushBot, AhrefsBot и Amazonbot всегда получали 503. GPTBot получал 503 примерно в половине запросов на одном сайте и в 23 % на другом, ClaudeBot в 41 %. Браузер в те же секунды получал 200, пауза между запросами не помогала. Похоже на ограничение частоты по имени робота.

Отказы отдаёт входной сервер, в журнал сайта они не попадают. Журнал за три дня показывает только итог: OAI-SearchBot пришёл 131 раз, bingbot 262, а GPTBot 5 раз, и настоящих среди них 2.

Что ответила поддержка. Сняли ограничение сначала для GPTBot, по второй просьбе для ClaudeBot. На вопрос, стоят ли такие ограничения на всех сайтах и надо ли каждый раз писать в поддержку, ответили, что полный список сообщить не могут: конфигураций защиты много, обычных посетителей они обычно не затрагивают.

Timeweb и HT-Systems: всё открыто

На сайте у Timeweb все роботы нейросетей и поисковиков получили 200, отказ 403 был только у SemrushBot. На сайте у HT-Systems проходили все.

Итог по пяти хостингам

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

Проверка снаружи: остальные хостеры

После этого мы прошли по остальным хостерам, где есть сайты из нашей клиентской базы. Доступа к журналам этих сайтов у нас нет, поэтому проверяли только снаружи, от имени роботов. С нашего сервера в России запрашивали robots.txt под обычным браузером и под девятью роботами: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, bingbot, Amazonbot, SemrushBot и YandexBot. Каждого по пять раз с паузой, от одного до трёх сайтов на хостера, только сайты, которые браузеру отвечают 200.

Важная оговорка. Это проверка по имени: запросы шли с нашего адреса, а настоящие роботы приходят со своих. Поддельные bingbot и YandexBot с того же адреса проходили, значит, сверки адресов там нет и режут именно по имени. Но наверняка, как у NetAngels, Рег.ру и Beget, мы это подтвердить не можем: для этого нужен журнал сайта или ответ поддержки. Если ваш сайт стоит у одного из хостеров с признаками, это повод проверить журнал и написать в поддержку.

Как проверить свой сайт

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

for ua in "Mozilla/5.0" "GPTBot/1.3" "ClaudeBot/1.0" "OAI-SearchBot/1.3" "bingbot/2.0"; do
  printf '%-18s' "$ua"
  for i in $(seq 10); do
    curl -s -o /dev/null -w '%{http_code} ' -A "$ua" https://example.ru/robots.txt
    sleep 1
  done
  echo
done

Браузер получает 200, а робот 000 (обрыв), 403 или 503? Хостинг режет роботов по имени.

2. Журнал и списки адресов. Защиту по адресам, как у NetAngels, с вашего компьютера не увидеть: ваш запрос идёт с обычного адреса. Остаётся журнал и скрипт сверки из начала статьи.

3. Bing Webmaster Tools. Импорт сайта из Search Console занимает минуту. Живая проверка адреса с ошибкой при работающем сайте почти всегда значит, что робот Bing не доходит.

4. Вопрос нейросети. Попросите ChatGPT открыть конкретную страницу и назвать с неё факт, например ИНН из подвала, и посмотрите, появился ли ChatGPT-User в журнале. Верить нужно журналу: в первом ответе ChatGPT однажды выдумал нам ИНН, которого на сайте нет.

5. Заявка хостеру. Перечислите, каких роботов открыть. Рег.ру и Beget сделали это за день. Если исключение невозможно, остаются свой VDS, прокси перед хостингом или переезд.

Защиту целиком отключать не нужно. Сканеры из зарубежных облаков никуда не делись: у нас за неделю 4 854 запроса получили 403 по странам. Открывать стоит конкретных роботов, а роботов SEO-сервисов можно оставить закрытыми, если они нагружают сайт.

Почему хостеры так делают

Понять их можно: краулеры Meta, Amazon и SEO-сервисов дают ощутимую нагрузку на общие серверы, а подделок под известных роботов много. На одном из сайтов клиента за 02–12 октября было 5 831 запрос от meta-externalagent против 325 от GPTBot.

Плохо другое. Ограничение включено по умолчанию, в панели его не видно. Поддержка сначала может ответить, что блокировок нет. Было бы честнее показывать клиенту список закрытых роботов с переключателем и ограничивать частоту по проверенным адресам вместо запрета по имени.

Проверим ваш хостинг бесплатно

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

Проверить сайт

IT Panda, октябрь 2026. Мы разрабатываем сайты на 1С-Битрикс и внедряем Битрикс24.