Иногда сайт открывается в браузере и нормально индексируется поисковыми системами, а при обращении от AI-бота сервер отдаёт совсем другой ответ. В логах это может выглядеть как 403, 429, 503 или как успешный 200 OK, за которым скрывается страница Cloudflare Challenge, капча или экран Access Denied.
Для AI-поиска важен доступ к основному HTML страницы. Если поисковый агент получает техническую заглушку, тогда экспертные материалы, FAQ, таблицы, инструкции и коммерческие страницы не попадают в зону анализа ChatGPT, Claude, Perplexity, Gemini и других AI-систем. Пользователь видит страницу, поисковый агент получает другой документ, и материал выпадает из AI-цитирования.
AI-доступность сайта — это техническая возможность для поисковых и генеративных агентов получить HTML-страницу, пройти редиректы, избежать блокировки WAF, капчи или серверного запрета и извлечь основной текст для анализа.
Проверить доступ можно через консоль: отправить несколько curl-запросов, сравнить ответы для разных User-Agent и убедиться, что бот получает HTML с основным содержанием страницы.
Разница между HEAD и GET-запросами
Быстрая первичная проверка начинается с заголовков ответа сервера. Для этого в curl используют флаг -I, который выполняет HEAD-запрос. Сервер в таком случае отдаёт HTTP-заголовки без загрузки тела страницы.
Пример запроса:
curl -I -L -A ‘Mozilla/5.0 (compatible; ChatGPT-User/1.0; +https://openai.com/bot)’ “https://example.com”
Для бота Anthropic запрос может выглядеть так:
curl -I -L -A ‘Claude-SearchBot/1.0 (+https://www.anthropic.com/claude-search-bot)’ “https://example.com”
Флаг -L заставляет curl переходить по редиректам, а -A задаёт строку User-Agent. HEAD-запрос помогает быстро понять, отвечает ли сервер и куда ведёт цепочка перенаправлений.
Для полноценной диагностики нужен GET-запрос. Системы защиты вроде Cloudflare, Incapsula или WAF на базе Nginx могут по-разному реагировать на HTTP-методы. На HEAD-запрос сервер иногда возвращает HTTP/2 200 OK, а при GET-запросе отдаёт 403 Forbidden, 503 Service Unavailable или страницу проверки Cloudflare.
Поэтому HEAD используют как быстрый тест, а основную проверку проводят через GET: он позволяет увидеть заголовки и понять, какое содержимое получает бот.
Базовая проверка страницы через GET
- Сначала задайте адрес проверяемой страницы в переменную:
URL=’https://example.com’
- Замените https://example.com на реальный адрес. Проверять стоит не одну главную страницу, а все важные типы URL: услуги, статьи, FAQ, кейсы, карточки товаров, страницы категорий и коммерческие посадочные.
- Выполните GET-запрос с выводом заголовков:
curl -sS -o /dev/null -D – -L -A ‘Mozilla/5.0 (compatible; ChatGPT-User/1.0; +https://openai.com/bot)’ “$URL”
Разбор флагов:
-sS — скрывает прогресс-бар, сохраняя вывод ошибок при сбое подключения;
-o /dev/null — отправляет тело страницы в «пустоту», чтобы терминал не заполнялся HTML-кодом;
-D — выводит HTTP-заголовки в консоль;
-L — переходит по перенаправлениям: 301, 302, 307, 308;
-A — передаёт нужный User-Agent.
Корректный ответ сервера выглядит примерно так:
HTTP/2 200
date: Wed, 29 Jul 2026 22:05:41 GMT
content-type: text/html; charset=utf-8
document-policy: js-profiling
Если первой строкой идёт 301, 302 или 307, перед вами обычное перенаправление. Просмотрите всю цепочку до финального блока: в конце должен появиться код 200. Ответы 403 Forbidden, 429 Too Many Requests или 503 Service Unavailable указывают на блокировку агента, лимит запросов или срабатывание защитного слоя.
Что важно проверить в ответе сервера
После первого GET-запроса оценивают весь ответ: финальный URL, заголовки, HTML, признаки капчи и защитного экрана. Статус 200 OK означает успешный HTTP-ответ, при этом внутри может оказаться Cloudflare Challenge, пустой шаблон или Access Denied вместо текста страницы.
| Что проверяется | Зачем это нужно | Что считается нормой | Что указывает на проблему |
|---|---|---|---|
| HTTP-статус страницы | Понять, открыт ли URL для запроса | 200 OK после всех редиректов | 403, 401, 429, 503 |
| Цепочка редиректов | Проверить, куда попадает бот | Финальный URL открывается корректно | Редирект на капчу, ошибку или другой раздел |
| Тело HTML-страницы | Убедиться, что бот видит контент | В HTML есть основной текст страницы | Cloudflare Challenge, Access Denied, Verify you are human |
| User-Agent | Узнать реакцию сервера на разных ботов | Сервер отдаёт страницу без блокировки | Блокировка GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot |
| robots.txt | Проверить правила доступа | Важные разделы открыты | Disallow для нужных агентов или всего сайта |
| WAF и CDN | Найти скрытую антибот-защиту | Боты получают основной HTML | 403, 429, капча или JS-челлендж |
| Серверные логи | Подтвердить реальные обращения | Видны обращения и корректные коды ответа | Боты получают ошибки или не доходят до нужных URL |
Какие данные даёт curl
curl показывает реакцию сервера на запрос с заданным User-Agent. Он не подтверждает визит настоящего GPTBot, ClaudeBot или PerplexityBot: строку User-Agent можно подделать. Для подтверждения реального бота нужны серверные логи, IP-диапазоны, reverse DNS, события WAF и настройки CDN.
| Возможность curl | Что показывает | Ограничение |
|---|---|---|
| Подмена User-Agent | Как сервер реагирует на GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot и другие строки | User-Agent можно подделать |
| Проверка HTTP-статуса | Возвращает ли сервер 200, 301, 403, 429, 503 | Статус 200 не гарантирует полезный контент внутри ответа |
| Проверка редиректов | Куда попадает бот после 301, 302, 307 или 308 | Нужно смотреть финальный URL |
| Анализ HTML | Видит ли бот основной текст страницы | Контент, подгруженный JavaScript, может не попасть в вывод curl |
| Поиск капчи и WAF-экрана | Отдаёт ли сервер Cloudflare Challenge, Access Denied или Verify you are human | Вывод нужно подтверждать логами и WAF-событиями |
| Массовая проверка URL | Какие разделы сайта доступны или заблокированы | Главная страница не отражает состояние всего сайта |
Для первичной диагностики достаточно 3 ориентиров: финальный статус, наличие основного HTML и отсутствие защитной страницы вместо контента. Количество проверенных User-Agent имеет смысл после оценки этих базовых условий.
Пошаговый сценарий массовой проверки через curl
Чтобы проверить реакцию сервера на основных AI-ботов, удобно задать целевой адрес в переменную и последовательно выполнить серию команд.
Шаг 1. Настройка переменной в терминале
Откройте командную строку и укажите адрес сайта:
URL=’https://example.com’
Замените https://example.com на реальный адрес проверяемого ресурса.
Какие User-Agent стоит проверить
Перед запуском команд полезно понимать, зачем проверяется каждый тип агента. Одни User-Agent относятся к реальным краулерам, другие — к пользовательским запросам или контрольным строкам для диагностики WAF.
| Группа | User-Agent | Что помогает проверить | Как интерпретировать |
|---|---|---|---|
| OpenAI | ChatGPT-User | Доступность страницы при пользовательских действиях в ChatGPT | Ошибки 403, 429 или капча могут мешать получению страницы |
| OpenAI | GPTBot | Реакцию сервера на краулер OpenAI | Проверку нужно дополнять robots.txt и логами |
| OpenAI | OAI-SearchBot | Доступность сайта для поисковых функций OpenAI | Важен для попадания контента в поисковые ответы и сниппеты ChatGPT |
| Anthropic | ClaudeBot | Реакцию сервера на краулер Anthropic | Блокировки могут ограничивать использование сайта Claude |
| Anthropic | Claude-SearchBot | Доступность для поискового агента Claude | Важно проверять финальный HTML, а не статус в первой строке ответа |
| Perplexity | PerplexityBot | Доступность для краулера Perplexity | Желательно сверять с логами и IP-диапазонами |
| Meta | Meta-ExternalAgent | Реакцию сайта на внешнего агента Meta | Полезно для диагностики общего поведения защиты |
| Контрольная строка | AvailabilityCheck | Общую реакцию защиты на нестандартный User-Agent | Не доказывает доступность для конкретной AI-системы |
| Контрольная строка | Google-Extended | Реакцию WAF на название агента | Основная проверка Google-Extended проводится через robots.txt |
| Контрольная строка | AppleBot-Extended | Реакцию WAF на название агента | Основная проверка AppleBot-Extended проводится через robots.txt |
| Дополнительный агент | DeepSeekBot | Реакцию сервера на строку DeepSeekBot | Лучше подтверждать через логи и официальные данные, если они доступны |
Шаг 2. Запуск серии проверок для ключевых User-Agent
Команды лучше разделить по группам. Так проще увидеть, какой тип агента получает ошибку: OpenAI, Anthropic, Perplexity, внешний агент или контрольная строка.
OpenAI
curl -sS -o /dev/null -D – -L -A ‘Mozilla/5.0 (compatible; ChatGPT-User/1.0; +https://openai.com/bot)’ “$URL”
curl -sS -o /dev/null -D – -L -A ‘GPTBot/1.0 (+https://openai.com/gptbot)’ “$URL”
curl -sS -o /dev/null -D – -L -A ‘OAI-SearchBot/1.0 (+https://openai.com/searchbot)’ “$URL”
Anthropic
curl -sS -o /dev/null -D – -L -A ‘ClaudeBot/1.0 (+https://www.anthropic.com/claude-bot)’ “$URL”
curl -sS -o /dev/null -D – -L -A ‘Claude-SearchBot/1.0 (+https://www.anthropic.com/claude-search-bot)’ “$URL”
Perplexity
curl -sS -o /dev/null -D – -L -A ‘PerplexityBot/1.0 (+https://www.perplexity.ai/perplexitybot)’ “$URL”
Meta и другие внешние агенты
curl -sS -o /dev/null -D – -L -A ‘Meta-ExternalAgent/1.0 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)’ “$URL”
curl -sS -o /dev/null -D – -L -A ‘DeepSeekBot/1.0 (+https://www.deepseek.com/bot)’ “$URL”
Контрольные строки
curl -sS -o /dev/null -D – -L -A ‘Mozilla/5.0 (X11; Linux x86_64) AvailabilityCheck/1.0’ “$URL”
curl -sS -o /dev/null -D – -L -A ‘Google-Extended/1.0 (+https://developers.google.com/search/docs/crawling-indexing/overview/google-extended)’ “$URL”
curl -sS -o /dev/null -D – -L -A ‘AppleBot-Extended/1.0 (+https://support.apple.com/en-us/HT204683)’ “$URL”
Результаты этого блока работают как технический скрининг. Сервер пропускает запрос с таким User-Agent, блокирует его или отдаёт защитную страницу. Ответы 403, 429, 503 и страница проверки Cloudflare требуют проверки WAF, CDN, robots.txt и серверных логов. При ответе 200 OK следующий шаг — убедиться, что внутри есть реальный текст страницы.
Почему Google-Extended и AppleBot-Extended требуют отдельного пояснения
Google-Extended часто включают в списки AI-ботов, хотя его нельзя корректно проверять как отдельного HTTP-краулера. Google-Extended — это токен для robots.txt, который управляет использованием контента Google для Gemini и связанных функций. Он не является самостоятельным ботом, приходящим на сайт со своей HTTP-строкой.
AppleBot-Extended работает по похожей логике. Он не сканирует страницы самостоятельно, а служит дополнительным управляющим агентом для robots.txt. С его помощью издатели могут ограничивать использование уже просканированного Applebot контента для обучения моделей Apple.

Практическая логика такая:
Googlebot проверяют через curl;
Google-Extended проверяют в robots.txt и при необходимости используют в curl как контрольную строку;
Applebot проверяют через curl;
AppleBot-Extended проверяют в robots.txt и при необходимости используют в curl как контрольную строку.
Как быстро проверить robots.txt для AI-ботов
Доступность страницы зависит от ответа сервера и правил robots.txt. Проверить файл можно так:
curl -sS -L ‘https://example.com/robots.txt’
В robots.txt стоит отдельно посмотреть правила для нужных агентов:
User-agent: GPTBot
Allow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: Google-Extended
Allow: /
User-agent: AppleBot-Extended
Allow: /
Если в файле есть блоки вида:
User-agent: GPTBot
Disallow: /
или общий запрет:
User-agent: *
Disallow: /
бот может не получать доступ к важным разделам сайта. При этом robots.txt не заменяет проверку через curl: файл может разрешать доступ, а WAF, Cloudflare, Nginx, хостинг или модуль безопасности всё равно заблокируют запрос.
Что должно быть в ответе терминала
При анализе ответа смотрите на всю цепочку после редиректов.
Основные варианты:
- 200 OK с чистым HTML — страница доступна;
- 200 OK с капчей или challenge-страницей — код успешный, контент недоступен;
- 301 / 302 / 307 / 308 — редирект, нужно смотреть финальный статус;
- 401 Unauthorized — требуется авторизация;
- 403 Forbidden — доступ запрещён;
- 429 Too Many Requests — сработало ограничение частоты запросов;
- 503 Service Unavailable — часто встречается при WAF-челленджах, перегрузке или временной блокировке.
Сам по себе 200 OK ничего не гарантирует. Внутри может быть Cloudflare Challenge, пустой шаблон, капча или страница Access Denied.
Фильтрация скрытой антибот-защиты и капчи
Если сервер без защиты, статуса 200 часто достаточно. Современные площадки дополнительно оценивают User-Agent, TLS-отпечаток, IP-адрес, поведение клиента и выполнение JavaScript. Поэтому сервер может отдавать HTTP-код 200, а вместо полезной статьи присылать страницу с текстом Verify you are human или фреймом Cloudflare Turnstile.

Экспресс-тест на заблокированные страницы Cloudflare
Чтобы убедиться, что сервер отдал HTML с основным текстом страницы, пропустите тело ответа через текстовый фильтр grep:
curl -sS -L -A ‘GPTBot/1.0 (+https://openai.com/gptbot)’ “$URL” | grep -Ei ‘captcha|challenge|cloudflare|cf-error|attention required|verify you are human|just a moment|access denied|forbidden’
Если команда нашла фразы attention required, verify you are human, just a moment или access denied, AI-бот может получать защитную страницу вместо контента. Окончательный вывод стоит подтверждать логами, WAF-событиями и реальными обращениями.
Для PerplexityBot аналогичная проверка выглядит так:
curl -sS -L -A ‘PerplexityBot/1.0 (+https://www.perplexity.ai/perplexitybot)’ “$URL” | grep -Ei ‘captcha|challenge|cloudflare|cf-error|attention required|verify you are human|just a moment|access denied|forbidden’
Как проверить, что бот видит реальный контент страницы
- Ищите уникальную фразу с самой страницы. Например, если на странице есть заголовок «AI-аудит сайта девелопера», проверьте, отдаётся ли он боту:
curl -sS -L -A ‘OAI-SearchBot/1.0 (+https://openai.com/searchbot)’ “$URL” | grep -F ‘AI-аудит сайта девелопера’
- Если фраза найдена, сервер отдаёт реальное содержимое.
- Если фраза не найдена, возможны разные причины:
- текст подгружается JavaScript-ом;
- страница отдаёт другую версию HTML;
- контент скрыт за интерактивным блоком;
- сработала защита;
- на странице есть canonical или редирект на другой URL;
- текст находится в изображении, PDF или iframe.
Быстрый просмотр исходного кода для других систем защиты
Для сайтов с другими экранами блокировки стоит посмотреть первые 20–50 строк загруженного документа:
curl -sS -L -A ‘GPTBot/1.0 (+https://openai.com/gptbot)’ “$URL” | head -n 50
Этого объёма хватает, чтобы увидеть title и первичное содержимое. Если в заголовке страницы написано Just a moment, Access Denied или Attention Required, сканирование блокируется на уровне сетевого экрана.
Как сравнить ответ для браузера и AI-бота
Иногда сайт нормально открывается для браузера, а AI-бот получает ошибку или challenge-страницу. Чтобы это проверить, сравните два запроса.
Обычный браузер:
curl -sS -o /dev/null -D – -L -A ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36’ “$URL”
GPTBot:
curl -sS -o /dev/null -D – -L -A ‘GPTBot/1.0 (+https://openai.com/gptbot)’ “$URL”
Если браузер получает 200 OK, а GPTBot — 403, 429 или challenge-страницу, искать причину стоит в антибот-защите, WAF, CDN или серверных правилах.
Корректная интерпретация редиректов и статусов сервера
При анализе откликов важно различать несколько вариантов поведения сервера.
| Код ответа | Что происходит на самом деле | Поведение AI-бота |
|---|---|---|
| 200 OK с чистым HTML | Страница открыта, основной текст доступен в HTML | Бот может считать контент |
| 200 OK со скриптом проверки | Сработал WAF или Cloudflare Challenge | Бот не исполняет JS, считывает пустую заглушку и уходит |
| 301 / 302 / 307 / 308 | Перенаправление на другой URL | Бот идёт по ссылке и проверяет финальный адрес |
| 401 Unauthorized | Требуется авторизация | Бот не получает контент |
| 403 Forbidden | Прямой запрет доступа на уровне сервера, WAF или .htaccess | Сканирование прерывается |
| 429 Too Many Requests | Сработал rate limit | Бот может временно потерять доступ |
| 503 Service Unavailable | Ошибка сервера, защитный режим или временная блокировка | Контент недоступен или нестабилен |
Как проверить несколько страниц сразу
Главная страница не показывает состояние всего сайта. На практике бывает, что главная открыта, а статьи, услуги, фильтры каталога, карточки товаров или FAQ закрыты от ботов. Поэтому лучше проверять список URL.
- Создайте файл urls.txt:
https://example.com/
https://example.com/services/
https://example.com/blog/article/
https://example.com/faq/
- Проверьте их циклом:
while read URL; do
echo “=== $URL ===”
curl -sS -o /dev/null -D – -L -A ‘OAI-SearchBot/1.0 (+https://openai.com/searchbot)’ “$URL” | grep -Ei ‘HTTP/|content-type|location|server|cf-cache-status’
done < urls.txt
Так можно быстро увидеть, где сервер отдаёт 200, где есть редиректы, а где появляются ошибки.
Как проверить доступность только по статус-коду
- Если нужен короткий отчёт, можно вывести финальный код ответа:
curl -sS -o /dev/null -L -w ‘%{http_code} %{url_effective}\n’ -A ‘OAI-SearchBot/1.0 (+https://openai.com/searchbot)’ “$URL”
Пример результата:
200 https://example.com/blog/article/
- Для массовой проверки:
while read URL; do
code=$(curl -sS -o /dev/null -L -w ‘%{http_code}’ -A ‘OAI-SearchBot/1.0 (+https://openai.com/searchbot)’ “$URL”)
echo “$code $URL”
done < urls.txt
Статус-код не показывает, получил ли бот реальный текст. Для полной проверки нужно смотреть тело страницы или искать уникальную фразу из контента.
Как найти проблему: robots.txt, WAF или сервер
- Если бот получает ошибку, нужно понять, где возник блок.
- Проверьте robots.txt:
curl -sS -L ‘https://example.com/robots.txt’
- Проверьте ответ сервера с разными User-Agent:
curl -sS -o /dev/null -D – -L -A ‘Googlebot/2.1 (+http://www.google.com/bot.html)’ “$URL”
curl -sS -o /dev/null -D – -L -A ‘OAI-SearchBot/1.0 (+https://openai.com/searchbot)’ “$URL”
curl -sS -o /dev/null -D – -L -A ‘PerplexityBot/1.0 (+https://www.perplexity.ai/perplexitybot)’ “$URL”
- Проверьте тело страницы:
curl -sS -L -A ‘OAI-SearchBot/1.0 (+https://openai.com/searchbot)’ “$URL” | head -n 50
- Если robots.txt разрешает доступ, а curl получает 403, причина обычно находится на уровне WAF, CDN, хостинга или серверных правил.
Чаще всего блокировку вызывают:
- Cloudflare WAF;
- правила Security → WAF;
- Bot Fight Mode или AI crawler blocking;
- mod_security на хостинге;
- Nginx-правила по User-Agent;
- ограничения по географии;
- rate limits;
- защита от дата-центровых IP;
- капча или JavaScript challenge.
Почему важно проверять IP и логи
Подмена User-Agent через curl помогает найти очевидные проблемы, однако она не доказывает, что запрос пришёл от официального бота. Для точной диагностики нужны серверные логи, IP-диапазоны, reverse DNS, WAF-события и правила CDN.
После curl-проверки стоит посмотреть:
- какие User-Agent реально приходили;
- какие URL они запрашивали;
- какой код ответа получили;
- не было ли 403, 429 или 503;
- не сработали ли правила WAF;
- не попали ли боты в rate limit;
- не возвращался ли им другой HTML, чем обычным пользователям.
Для OpenAI, Perplexity и других систем также стоит сверяться с опубликованными IP-диапазонами, если нужно настраивать allowlist на уровне WAF или CDN.

Что не стоит делать
- Не открывайте весь сайт для подозрительных ботов без проверки. Среди реальных поисковых агентов есть поддельные или агрессивные скраперы.
- Не считайте строку User-Agent доказательством подлинности бота.
- Не закрывайте GPTBot, OAI-SearchBot, Claude-SearchBot, PerplexityBot и другие AI-агенты автоматически. Сначала определите задачу сайта: защита данных, SEO-видимость, AI-цитируемость, попадание в поисковые ответы или ограничение обучения моделей.
- Не тестируйте только главную страницу. В AI-ответы чаще попадают статьи, FAQ, инструкции, карточки товаров, страницы услуг, сравнения и кейсы.
- Не ориентируйтесь только на код 200. Всегда проверяйте, какой HTML получил бот.
Что проверить в первую очередь
Если времени мало, начинать лучше не с десятков User-Agent, а с пяти базовых проверок.
| Приоритет | Что проверить | Почему важно |
|---|---|---|
| 1 | Финальный HTTP-статус | Показывает, открывается ли страница после редиректов |
| 2 | Наличие основного текста в HTML | Подтверждает, что бот видит не пустую страницу |
| 3 | Признаки Cloudflare, капчи и WAF | Помогает найти скрытую блокировку при статусе 200 OK |
| 4 | robots.txt | Показывает, не закрыт ли бот правилами доступа |
| 5 | Логи и WAF-события | Подтверждают реальные обращения и причины блокировки |
Короткий чек-лист проверки
- Выбрать важные URL: главная, услуги, статьи, FAQ, кейсы, карточки товаров.
- Проверить robots.txt.
- Выполнить HEAD-запрос для быстрой диагностики.
- Выполнить GET-запрос с User-Agent нужного бота.
- Проверить финальный HTTP-статус после редиректов.
- Найти в HTML уникальную фразу со страницы.
- Проверить признаки Cloudflare, капчи, WAF и Access Denied.
- Сравнить ответ для браузера и AI-бота.
- Посмотреть серверные логи и события WAF.
- Настроить исключения только для тех ботов, которые действительно нужны проекту.
FAQ: отвечаем на частые вопросы
Кому нужна проверка доступности сайта для AI-ботов?
Проверка нужна SEO-специалистам, техническим маркетологам, разработчикам и командам, которые отвечают за AI-видимость сайта. Она полезна на стыке SEO и инфраструктуры: когда контент уже подготовлен, а доступность страниц для AI-ботов ещё не проверялась.
Когда стоит проверять доступность сайта для AI-ботов?
Проверку стоит проводить после подключения Cloudflare, WAF или CDN, миграции сайта, изменения robots.txt, внедрения антибот-защиты, запуска блога, FAQ, базы знаний или раздела услуг. Отдельный повод — ситуация, когда ChatGPT, Perplexity или другие AI-системы не видят сайт по целевым запросам, а стандартные SEO-инструменты не показывают явных проблем.
Что именно проверяет curl?
curl показывает, как сервер отвечает на запрос с заданным User-Agent: какой HTTP-статус возвращает, проходит ли редирект, отдаётся ли HTML-страница и не подменяется ли контент капчей или WAF-экраном. Он не подтверждает подлинность бота, поэтому результаты нужно сверять с логами, IP-диапазонами и событиями WAF.
Почему статус 200 OK не гарантирует доступность сайта для AI-бота?
Статус 200 OK означает успешный HTTP-ответ. Внутри ответа может быть Cloudflare Challenge, капча, пустой шаблон, Access Denied или другая техническая заглушка. Поэтому нужно проверять статус и тело HTML-страницы.
Чем HEAD-запрос отличается от GET-запроса?
HEAD-запрос возвращает только HTTP-заголовки. GET-запрос загружает тело страницы и показывает, какой HTML получает бот. Для быстрой проверки подходит HEAD, для диагностики AI-доступности — GET.
Как понять, что AI-бот видит реальный текст страницы?
Нужно проверить тело HTML и найти в нём уникальную фразу со страницы. Если команда grep находит заголовок или фрагмент основного текста, это хороший сигнал. Если вместо текста появляются слова captcha, challenge, cloudflare, access denied или verify you are human, бот может видеть защитную страницу.
Нужно ли проверять только главную страницу сайта?
Нет. Главная страница может быть открыта, а статьи, FAQ, страницы услуг, карточки товаров или разделы блога — заблокированы. Для AI-цитируемости чаще важны экспертные материалы, инструкции, сравнения и FAQ, поэтому проверять нужно несколько типов URL.
Можно ли через curl проверить настоящего AI-бота?
Нет. curl позволяет подставить User-Agent, но не делает запрос настоящим ботом. Для подтверждения реальных обращений нужны серверные логи, IP-диапазоны, reverse DNS, события WAF и настройки CDN.
Почему Google-Extended и AppleBot-Extended нельзя проверять как обычных краулеров?
Google-Extended и AppleBot-Extended работают как управляющие правила для robots.txt, а не как обычные самостоятельные HTTP-краулеры. В curl их можно использовать как контрольные строки, чтобы увидеть реакцию защиты на название агента. Основная проверка проводится через robots.txt.
Что делать, если AI-бот получает 403, 429 или 503?
Нужно проверить robots.txt, правила Cloudflare или WAF, настройки CDN, mod_security, Nginx, лимиты запросов, геоблокировки и серверные логи. Если сайт должен быть доступен для AI-поиска, для нужных ботов настраивают корректные правила доступа и исключения.
Что делать после проверки доступности сайта для AI-ботов
curl быстро показывает, что сервер отдаёт AI-боту: страницу, редирект, ошибку или защитный экран. Такая проверка помогает не тратить время на оптимизацию контента, который бот технически не может прочитать.
Для AI-цитируемости недостаточно написать хороший текст. Сначала нужно убедиться, что поисковый агент получает страницу, читает основной HTML и не упирается в WAF, капчу или редирект.
Если выявлены скрытые или прямые блокировки, стоит проверить правила Cloudflare, WAF, CDN, файл robots.txt, а также настройки mod_security или ngx_http_access_module на стороне хостинга. Устранение причин — отдельная задача. В этой статье мы разобрали


