В современном мире, где AI-агенты становятся важными участниками в процессе индексации и поиска информации, понимание механизмов их работы и проверки доступа к контенту становится критически важным. Открытый файл robots.txt не всегда гарантирует, что робот сможет получить доступ к странице. Между ним и приложением могут находиться такие элементы, как CDN, WAF, ограничения по частоте запросов и кеширование. Ошибки на этих уровнях могут привести к тому, что обсуждение цитируемости в AI-поиске будет превращаться в спор о контенте, который система могла и не прочитать. Рассмотрим, как правильно проверять доступ к контенту по слоям: назначение робота, подтверждение его происхождения, HTTP-ответ и содержимое документа.
Изменения в политике доступа для роботов
С недавнего времени в документации Google появился новый механизм для AI-агентов — криптографическая проверка запросов через Web Bot Auth. Это обновление было внесено 13 октября 2026 года. Важно отметить, что данный механизм является экспериментальным и используется только для части агентов на инфраструктуре Google. Не каждый запрос подписывается, что означает, что не все Googlebot'ы переходят на обязательные подписи. Это изменение подчеркивает необходимость более глубокого понимания того, кто именно обращается к вашему контенту и какие функции он выполняет.
Проверка доступа по слоям
Для эффективной проверки доступа к контенту необходимо разделить три ключевых аспекта: назначение, идентификацию и разрешение. Важно создать реестр потребителей контента, который будет включать:
- Объект: тип робота (например, Googlebot).
- Документация: ссылки на официальные источники.
- Политика: желаемая политика доступа к контенту.
- Способ проверки: методы, используемые для подтверждения доступа.
robots.txt — не единственный слой защиты
Файл robots.txt определяет правила обхода, но не обеспечивает защиту закрытых данных. Хотя добросовестные роботы соблюдают инструкции, сам файл не может принудить клиента следовать этим правилам. Запрет на обход не является надежным способом удаления URL из индекса Google. Для этого Google рекомендует использовать директиву noindex, даже если страница доступна для обхода. Диагностика доступа должна представлять собой цепочку вопросов, начиная с назначения клиента и заканчивая проверкой индексации и видимости.
Идентификация робота
Запрос с заголовком Googlebot, отправленный с обычного ноутбука, не является доказательством того, что это действительно Googlebot. Для подтверждения идентичности робота Google использует два метода: сопоставление IP с опубликованными диапазонами и обратное DNS-разрешение. Важно различать три результата в реестре аудита: подтвержден, не подтвержден и недостаточно данных. Наличие заголовка Signature-Agent не отменяет необходимость проверки.
Сопоставление edge и приложения
Для проверки доступа необходимо начать с небольшой выборки URL, включая главную страницу, страницы категорий и карточки товаров. Для каждого URL следует зафиксировать время, хост, тип клиента и результат. Если на уровне edge возвращается ошибка 403, необходимо проверить действие WAF и идентификатор сработавшего правила. Если ответ 200, но нужный текст отсутствует, следует открыть сохраненное тело ответа и выяснить, что именно было возвращено.
Небольшой разборщик наблюдений
Для анализа полученных данных можно использовать простой Python-скрипт, который классифицирует результаты на основе проверок логов и ответов. Этот скрипт не делает сетевых запросов и не разбирает robots.txt, а лишь заполняет поля на основе проверенных данных. Он позволяет выявить проблемы с доступом и содержимым, не полагаясь на ложные данные.
Как принять исправления
При внесении изменений в инфраструктуру важно зафиксировать конкретную неисправность и согласовать изменения с владельцем. Необходимо повторить проверки на той же выборке и сохранить новые свидетельства. Уровень достаточных доказательств должен быть четко определен для каждого этапа, включая политику, доставку и индексацию. Важно помнить, что даже успешный HTTP-ответ не гарантирует индексацию, и необходимо сопоставлять отчеты об индексированных версиях страниц с текущими проверками.
Рабочий результат такого аудита — это набор проверяемых утверждений о том, какой клиент пришел, чем подтверждена его идентичность, какое правило применялось и какой документ он получил. На этой основе можно уже обсуждать качество источника и его присутствие в AI-поиске.