Почему открытый robots.txt не гарантирует доступ AI-краулеров к сайту
Открытый robots.txt ещё не означает, что поисковый или AI-краулер действительно получил страницу. Между запросом робота и веб-приложением находятся CDN, WAF, ограничения частоты, кеширующие слои и правила маршрутизации. На любом из этих этапов запрос может быть заблокирован или получить не тот документ, который видит обычный пользователь.
Из-за этого обсуждение присутствия сайта в AI-поиске иногда сводится к контенту, который система фактически не смогла прочитать. Для корректной диагностики нужно разделять несколько независимых вопросов: кто отправил запрос, разрешён ли ему обход, какой HTTP-ответ вернулся и содержал ли он нужный материал.
Робот становится частью политики доступа
В документации Google появился отдельный практический контур для AI-агентов — Web Bot Auth, предназначенный для криптографической проверки запросов. Руководство было обновлено 13 октября 2026 года, однако механизм пока имеет экспериментальный статус. Он применяется только к части агентов на инфраструктуре Google, а подпись присутствует не в каждом запросе. Это не означает, что весь Googlebot перешёл на обязательную проверку подписей.
Для технического SEO этого достаточно, чтобы пересмотреть сам подход к настройкам обхода. Наличие строки Googlebot в заголовке User-Agent не доказывает происхождение запроса и не объясняет, какую функцию выполняет клиент. Политику доступа лучше вести как конфигурацию продукта: фиксировать владельца, назначение правила, дату изменения и результат проверки после релиза.
При этом доступность страницы не равна её видимости. Для появления ссылки в AI Overviews или AI Mode Google требует индексируемый документ, который допускается к показу со сниппетом. Отдельная обязательная AI-разметка для этого не нужна, но выполнение технических требований само по себе не гарантирует попадание страницы в конкретный ответ. На результат влияют robots.txt, CDN, хостинговая инфраструктура, индексация и другие условия.
Разделяйте назначение, идентификацию и разрешение
Перед аудитом стоит составить реестр потребителей контента и не переносить на сайт универсальный запрет для всех AI-систем без проверки назначения каждой записи. Для Google в таком реестре полезно различать несколько сущностей:
- Googlebot — поисковый краулер. Нужно проверить, доступны ли публичные страницы для поиска и не блокирует ли их инфраструктура.
- Google-InspectionTool — инструмент проверки, включая URL Inspection. Его доступ может отличаться от регулярного обхода.
- Google-Extended — токен управления использованием контента, а не отдельный HTTP User-Agent.
Google-Extended связан с обучением будущих моделей Gemini и grounding в отдельных продуктах Google. Он не управляет включением сайта в Google Search и не является сигналом ранжирования. Поэтому поиск строки Google-Extended в access.log не позволяет проверить, была ли соответствующая политика применена.
Для каждого потребителя контента удобно хранить четыре поля: функцию, ссылку на документацию внутри рабочей базы знаний, желаемую политику и способ проверки. Дополнительно стоит указывать дату последнего пересмотра. Это помогает обнаружить конфликт между задачей редакции сохранить поисковую доступность и общим запретом, который применяет инфраструктурная команда.
robots.txt — только один из уровней
Файл robots.txt сообщает добросовестным роботам правила обхода, но не является механизмом защиты данных. Клиент может проигнорировать его содержимое, а запрет обхода не служит надёжным способом удалить URL из индекса Google. Для исключения страницы из поиска Google рекомендует использовать noindex при сохранении доступности страницы для обхода либо другие подходящие механизмы.
Проверку следует строить как последовательность отдельных этапов: назначение клиента, подтверждение его происхождения, обработка robots.txt, прохождение через CDN и WAF, получение HTTP-ответа и проверка нужного контента. Для каждого перехода нужно сохранять свидетельства: версию политики, идентификатор запроса, сработавшее правило, статус и небольшой безопасный фрагмент ответа.
Важно не путать ответ самого документа с ответом robots.txt. В реализации Google ошибка 403 при запросе robots.txt трактуется как отсутствие действующего файла с ограничениями. Ответы класса 5xx запускают другой сценарий: обход может быть приостановлен, а система — использовать последнюю успешно полученную версию. Кроме того, robots.txt относится к конкретным протоколу, хосту и порту. Если контент размещён на поддомене, файла главного домена недостаточно для вывода о доступности этого ресурса.
User-Agent не подтверждает происхождение
Запрос с заголовком Googlebot, отправленный с ноутбука разработчика, остаётся запросом с ноутбука. Такой тест позволяет увидеть реакцию сайта на конкретное значение заголовка, но не показывает, как CDN обработает настоящий адрес робота, запрос из другого региона или обращение при ином состоянии лимитов.
Для проверки запросов Google используются два документированных подхода: сопоставление IP с опубликованными диапазонами нужной категории либо обратное DNS-разрешение с проверкой допустимого имени и последующим прямым разрешением обратно в исходный IP. Категории обычных краулеров и пользовательских fetcher различаются, поэтому их нельзя безоговорочно объединять в одну группу.
В журнале аудита лучше использовать три результата: «подтверждён», «не подтверждён» и «данных недостаточно». Последний вариант необходим, если IP отсутствует, источник лога неполон или актуальность диапазонов нельзя установить. Отсутствие доказательства не следует автоматически считать доказательством подделки.
Web Bot Auth добавляет ещё один способ проверки, но наличие заголовка Signature-Agent само по себе не подтверждает подпись. Верификатор должен проверить её по ключам и параметрам протокола. Из-за неполного покрытия механизма на практике следует сохранять и другие способы идентификации.
Сопоставляйте edge, приложение и полученный документ
Для первичной проверки достаточно небольшой выборки: главной страницы, категории, карточки товара, статьи, страницы с важными условиями и robots.txt. Для каждого URL нужно зафиксировать время, хост, тип клиента, способ идентификации и результат обработки.
- На edge возвращается 403, а приложение не видит обращения. Проверьте действие WAF, идентификатор правила и полноту логирования.
- На edge возвращается 200, но нужного текста нет. Изучите сохранённое тело ответа: это может быть пустой шаблон, ошибка, challenge или урезанная версия документа.
- Приложение ответило 200, но внешний ответ отличается. Сопоставьте кеш, преобразования и правила периметра.
- Локальная проверка успешна, а подтверждённые визиты получают ошибки. Сравните время запроса, регион, IP-категорию, лимиты и маршрут.
- URL Inspection показывает успешную проверку, но регулярный обход не подтверждён. Анализируйте фактические обращения Googlebot отдельно.
Это направления расследования, а не готовые диагнозы. Отсутствие записи на origin может быть связано с кешем или выборочным сбором логов. По одному пропущенному событию нельзя объявлять WAF причиной проблемы.
Успешный HTTP-ответ также не гарантирует индексацию. Ответы 429 и серверные ошибки способны снижать интенсивность обхода, поэтому полезнее анализировать сочетание статусов и содержимого, а не только долю ответов 200. Для быстрой проверки можно выбрать несколько смысловых маркеров: название продукта, условие тарифа или единицу измерения. Такой маркер не доказывает полноту документа, но помогает отобрать подозрительные ответы.
Как не превратить автоматическую проверку в ложный PASS
Для массового аудита можно использовать небольшой офлайн-разборщик наблюдений. Он не должен сам считать запрос достоверным только на основании User-Agent, а также не обязан самостоятельно разбирать robots.txt или верифицировать ботов. Поле verified должно приходить из отдельного доверенного процесса.
Логика классификации может быть последовательной: сначала проверяется идентичность клиента, затем разрешение в robots.txt, после этого — статус edge, и только затем — содержимое ответа. Неподтверждённый клиент получает статус IDENTITY_UNKNOWN. Запрещённый обход — POLICY_BLOCK, неопределённое правило — POLICY_UNKNOWN. Ответы 401, 403 и 429 требуют ACCESS_REVIEW, серверные ошибки — SERVER_ERROR, а отсутствие ожидаемого текста — CONTENT_REVIEW.
Если подтверждённый клиент получил разрешённый ответ 200 с ожидаемым содержимым, результат можно назвать FETCH_OBSERVED. Но даже он означает только успешное получение конкретного документа в конкретном наблюдении. Такой статус не устанавливает факт индексации, причины проблем в прошлом или вероятность цитирования в AI-ответах. Поэтому в отчёте не должно быть универсального статуса вроде «GEO готов».
В исходных наблюдениях полезно сохранять URL, время в UTC, request ID, версию политики, способ проверки идентичности и ссылку на внутреннее свидетельство. При агрегации данные лучше группировать по шаблону страниц и проверенному типу клиента, чтобы единичный успешный запрос не скрывал системную проблему.
Как принимать исправления
Работу над ошибкой стоит начинать с фиксации конкретного препятствия и согласования изменения с владельцем инфраструктуры. После этого нужно повторить проверку на той же выборке и сохранить новые свидетельства. Полностью отключать защиту сайта ради исчезновения одной ошибки в отчёте не следует.
На уровне политики достаточным результатом будет подтверждённое правило для нужного клиента и URL, но это ещё не доказывает, что реальный запрос дошёл до приложения. На уровне доставки требуется показать, что подтверждённый клиент получил ожидаемый ответ и контент, однако индексация по-прежнему остаётся неизвестной. Для проверки индексации нужны актуальные данные о странице в Google, а для GEO-наблюдения — сохранённые запрос, ответ, источник, дата и условия проверки.
Для Google разумно сопоставлять отчёт об индексированной версии страницы, текущую проверку и реальные обращения в логах. Свежий тест не переписывает историю последнего обхода. Кроме того, между устранением технического препятствия и изменением видимости могут пройти повторный обход, переобработка страницы и изменение состава поисковых ответов.
Рабочий итог такого аудита — не обещание цитирования, а набор проверяемых утверждений: какой клиент пришёл, чем подтверждена его идентичность, какое правило применилось и какой документ он получил. Только после этого имеет смысл отдельно обсуждать качество контента, индексацию и присутствие сайта в AI-поиске.
