Кратко о механике: когда пользователь задаёт вопрос, LLM-система может вызвать web search tool или внутренний поиск по индексу. Дальше retrieval (ретривел) собирает кандидатов: URL, сниппеты и фрагменты страниц. Затем rerank (реранк) пересортировывает кандидатов по релевантности, качеству и доступности. Лучшие фрагменты попадают в контекст модели как RAG — retrieval augmented generation, и уже на их основе формируется ответ. Если crawler видит captcha, гео-заглушку, пустой SPA-shell или запрет robots.txt, ресурс выпадает из этой цепочки или попадает в неё как некачественный источник.

Для каждого домена отправляются запросы с конкретными User-Agent строками, документированными или массово наблюдаемыми у каждого провайдера. Мы меняем идентификатор бота, но держим одинаковый HTTP-контекст: Accept для HTML/XML, Accept-Language: en-US,en;q=0.9, Accept-Encoding: gzip, deflate и Connection: keep-alive. Так видна разница между реакцией сайта на конкретного AI-краулера и на обычный запрос.

• OpenAI — GPTBot, OAI-SearchBot, ChatGPT-User. GPTBot собирает контент для обучения; OAI-SearchBot ходит в момент пользовательского вопроса с поиском; ChatGPT-User — действия пользователя ChatGPT при открытии конкретного URL.
• Anthropic — ClaudeBot, anthropic-ai, Claude-Web. ClaudeBot — обучающий аналог GPTBot; anthropic-ai — историческое имя, до сих пор активно в block-листах; Claude-Web — веб-поиск во время ответа.
• Perplexity — PerplexityBot, Perplexity-User. Первый индексирует, второй активируется в момент запроса.
• DeepSeek — DeepSeekBot, DeepSeek-User. Идентифицированы по наблюдениям сообщества и block-листам сайтов: официальной спецификации краулеров у DeepSeek нет, но имена массово встречаются в WAF-конфигах.
• Google — экосистема: Googlebot (поиск и AI Overviews), GoogleOther (внутренние задачи), Google-Agent и Google-NotebookLM (user-triggered AI), Google-CloudVertexBot (enterprise RAG).

Для каждой пробы сохраняются HTTP-статус, цепочка редиректов, TLS-результат, response headers, размер тела, sample HTML, признаки WAF/captcha/interstitial и объём текста, который можно извлечь без выполнения JavaScript. Это позволяет отличить формально-открытый ответ (200) от функционально-пустого (SPA-shell без контента) и опубликовать первичные сигналы рядом с интерпретацией LLM-отчёта.

• HTTP-статус и redirects — 200, 4xx, 5xx, цепочка переходов вплоть до финального URL.
• Response headers — server, content-type, cache, security-сигналы, маркеры WAF-вендоров.
• Body sample и extractable text — первые килобайты, объём текста после очистки без JS.
• Timings — TTFB и total time, чтобы понять, не отдаётся ли пустая страница быстро.
• TLS и proxy — успешность handshake и через какой выходной IP ушёл запрос.

Chrome-control имитирует обычный браузерный User-Agent, а empty-ua отправляет запрос без User-Agent. Если AI-бот получает отказ, а Chrome-control получает контент — это похоже на anti-AI фильтр. Если отказ получают все — это чаще WAF, TLS, гео- или инфраструктурное ограничение. Контрольные пробы — это ось, относительно которой интерпретируются результаты AI-краулеров.

Проверка идёт с серверной точки вне российской пользовательской сети. Российские WAF, блокировки зарубежных IP, гео-заглушки и сертификатные проблемы попадают в результат, потому что глобальные LLM чаще ходят за источниками не с IP конечного пользователя в РФ. Поэтому для AI visibility важна именно эта vantage-точка, а не дефолтный домашний IP в России.

Оценка строится на воспроизводимой матрице запросов: один домен, одинаковые сетевые условия, разные bot fingerprints и контрольные отпечатки. LLM-отчёт только интерпретирует эти измерения; первичные технические сигналы остаются в таблицах пробы, и их можно перепроверить вручную. Каждая проба содержит сырое тело ответа, заголовки и тайминги — это позволяет третьей стороне реконструировать вывод без обращения к нашей версии.