Открытый robots.txt ещё не означает, что робот получил страницу. Между ним и приложением стоят CDN, WAF, ограничения частоты и кеш. Ошибка на этом участке превращает обсуждение цитируемости в AI-поиске в спор о контенте, который система могла вообще не прочитать.
Разберём проверку доступа по слоям: назначение робота, подтверждение его происхождения, HTTP-ответ и содержимое документа. Отдельно — экспериментальный Web Bot Auth и небольшой Python-разборщик наблюдений, который не выдаёт подмену User-Agent за настоящий визит поисковика.
1. Что изменилось: робот становится субъектом политики доступа
В документации Google появился отдельный практический контур для AI-агентов: криптографическая проверка запросов через Web Bot Auth. Руководство обновлено 13 октября 2026 года. Важно его ограничение: механизм экспериментальный, используется для части агентов на инфраструктуре Google, причём подписывается не каждый запрос. Это не объявление о переводе всего Googlebot на обязательные подписи. Первоисточник: Google, Web Bot Auth.
Для технического SEO здесь интересна смена вопроса. Недостаточно спросить, есть ли слово Googlebot в заголовке запроса. Нужно понимать, кто пришёл, какую функцию выполняет и каким правилом получил доступ. Мой практический вывод: настройки обхода стоит учитывать как конфигурацию продукта, с владельцем, журналом изменений и проверкой после релиза.
При этом доступность не равна видимости. Для ссылки в AI Overviews или AI Mode Google требует индексируемую страницу, допущенную к показу со сниппетом. Отдельной обязательной AI-разметки нет; выполнение требований не гарантирует включения. В рекомендациях прямо упомянуты robots.txt, CDN и хостинговая инфраструктура. Первоисточник: AI features and your website.
Поэтому ниже — протокол диагностики доступа. Он не предсказывает вероятность цитирования и не распространяет поведение Google на все генеративные системы.
2. Разделите назначение, идентификацию и разрешение
Сначала заполните реестр потребителей контента. Не переносите готовый список «запретить все AI» на рабочий сайт без проверки назначения каждой записи.
Объект | Что документировано Google | Что проверять в проекте |
|---|---|---|
Googlebot | Поисковый обход | Нужны ли публичные страницы в поиске; не перекрыт ли доступ инфраструктурой |
Google-InspectionTool | Инструменты проверки, включая URL Inspection; отдельный токен | Не отличается ли доступ тестового инструмента от регулярного обхода |
Google-Extended | Токен управления использованием контента; отдельного HTTP User-Agent нет | Соответствует ли настройка политике использования контента |
Google-Extended управляет обучением будущих моделей Gemini и grounding в указанных Google продуктах. Он не влияет на включение сайта в Google Search и не является сигналом ранжирования. Поэтому поиск строки Google-Extended в access.log не проверяет применение этой политики. Первоисточник: каталог Google common crawlers.
Для каждого потребителя я рекомендую хранить четыре поля: функция, источник документации, желаемая политика и способ проверки. Отдельно — дату последнего пересмотра. Это позволяет заметить ситуацию, когда редакция хочет сохранить поисковую доступность, а инфраструктурная команда применяет общий запрет по категории трафика.
3. robots.txt — только один слой
robots.txt сообщает правила обхода, но не обеспечивает защиту закрытых данных. Добросовестный робот соблюдает инструкции; сам файл не принуждает клиента к этому поведению. Запрет обхода также не является надёжным способом удалить URL из Google. Для исключения из индекса Google документирует noindex при доступности страницы для обхода либо другие подходящие механизмы. Первоисточник: введение в robots.txt.
Диагностику удобно представить как цепочку независимых вопросов:
Назначение клиента → подтверждение происхождения ↓ robots.txt → CDN / WAF → HTTP-ответ → нужный контент ↓ отдельная проверка индексации и видимости
Это рабочая схема аудита, а не описание внутренней архитектуры поисковой системы. На каждом переходе сохраняйте свидетельство: версию политики, идентификатор запроса, действие правила, статус и небольшой безопасный фрагмент ответа.
Особенно легко перепутать ответ самой страницы и ответ robots.txt. Для Google ошибка 403 у robots.txt трактуется как отсутствие действующего файла с ограничениями; 5xx запускает другой сценарий с остановкой обхода и использованием последней успешной версии. Файл также привязан к конкретным протоколу, хосту и порту. Первоисточник: спецификация robots.txt в реализации Google.
Практическая проверка: включите в выборку robots.txt каждого используемого публичного хоста. Если каталог живёт на поддомене, одного файла главного домена недостаточно для заключения о нём.
4. User-Agent не доказывает происхождение
Запрос с заголовком Googlebot, отправленный с ноутбука, остаётся запросом с ноутбука. Такой тест полезен, чтобы обнаружить ветку обработки по заголовку. Он не показывает, как CDN обработает реальный адрес робота, другой регион или другое состояние лимита.
Для Google есть два документированных пути: сопоставление IP с опубликованными диапазонами соответствующей категории либо обратное DNS-разрешение с проверкой допустимого имени и последующим прямым разрешением обратно в исходный IP. Категории обычных краулеров и пользовательских fetcher различаются. Первоисточник: Verify requests from Google crawlers and fetchers.
В реестре аудита стоит различать три результата: подтверждён, не подтверждён, данных недостаточно. Последний нужен, когда IP отсутствует, источник лога ненадёжен или актуальность диапазонов неизвестна. Не превращайте отсутствие доказательства в доказанную подделку.
Web Bot Auth добавляет ещё один способ подтверждения, но не отменяет эту дисциплину. Наличие заголовка Signature-Agent само по себе не означает проверенную подпись: верификатор должен проверить её по ключам и параметрам протокола. Из-за неполного покрытия Google рекомендует сохранять установленные способы проверки. Первоисточник: экспериментальный Web Bot Auth.
5. Сопоставьте edge и приложение
Начните с небольшой выборки: главная, категория, карточка, статья, страница с важными условиями и robots.txt. Для каждого URL зафиксируйте время, хост, тип клиента, способ идентификации и результат.
Наблюдение | Следующий шаг расследования |
|---|---|
На edge 403, обращения к приложению не видно | Проверить действие WAF и идентификатор сработавшего правила; учесть полноту логирования |
На edge 200, нужного текста нет | Открыть сохранённое тело: это документ, пустой шаблон, ошибка или challenge? |
Приложение ответило 200, внешний ответ отличается | Сопоставить кеш, преобразования и правила на периметре |
Локальный тест успешен, подтверждённые визиты дают ошибки | Сравнить время, регион, IP-категорию, лимиты и маршрут |
URL Inspection успешен, регулярный обход не подтверждён | Проверять фактические визиты Googlebot отдельно |
Это направления проверки, а не автоматические диагнозы. Отсутствие записи на origin бывает связано с кешем или выборочным сбором логов. Не объявляйте WAF причиной по одному пропущенному событию.
Google отдельно описывает обработку HTTP-кодов: успешный ответ сам по себе не гарантирует индексацию, а 429 и серверные ошибки могут снижать интенсивность обхода. Поэтому полезнее сопоставлять типы ответов и их содержимое, чем считать общий процент 200. Первоисточник: HTTP status codes and network errors.
Для контентной проверки задайте несколько смысловых маркеров: название продукта, условие тарифа, единицу измерения. Полный хеш HTML может меняться из-за персонализации и служебных токенов. Маркер тоже не доказывает полноту документа, но помогает быстро отобрать подозрительные ответы.
6. Небольшой разборщик наблюдений без ложного PASS
Ниже — офлайн-пример. Он не делает сетевых запросов, не разбирает robots.txt и не верифицирует ботов. Поля заполняются после проверки логов и ответов. Значение verified должно приходить из доверенного процесса, а не из имени User-Agent.
from collections import Counter def classify(row): if row.get("identity") != "verified": return "IDENTITY_UNKNOWN" if row.get("robots_allowed") is False: return "POLICY_BLOCK" if row.get("robots_allowed") is not True: return "POLICY_UNKNOWN" status = row.get("edge_status") if status in (401, 403, 429): return "ACCESS_REVIEW" if isinstance(status, int) and 500 <= status <= 599: return "SERVER_ERROR" if status != 200: return "HTTP_REVIEW" if row.get("content_ok") is False: return "CONTENT_REVIEW" if row.get("content_ok") is not True: return "CONTENT_UNKNOWN" return "FETCH_OBSERVED" observations = [ {"identity": "verified", "robots_allowed": True, "edge_status": 403}, {"identity": "verified", "robots_allowed": True, "edge_status": 200, "content_ok": False}, {"identity": "ua_only", "robots_allowed": True, "edge_status": 200, "content_ok": True}, {"identity": "verified", "robots_allowed": True, "edge_status": 200, "content_ok": True}, ] for result, count in sorted(Counter(map(classify, observations)).items()): print(result, count)
Результат на этой синтетической выборке:
ACCESS_REVIEW 1 CONTENT_REVIEW 1 FETCH_OBSERVED 1 IDENTITY_UNKNOWN 1
Здесь намеренно нет статуса GEO_READY. Даже FETCH_OBSERVED означает только подтверждённое получение проверенного содержания в конкретном наблюдении. Скрипт не устанавливает причину 403, факт индексации или попадание в ответ. Для массовой обработки добавьте к исходным строкам URL, UTC-время, request ID, версию политики и ссылку на свидетельство; агрегируйте по шаблону страниц и проверенному клиенту.
7. Как принять исправление
Предлагаю следующий порядок приёмки. Сначала зафиксировать конкретную неисправность и согласовать изменение с владельцем инфраструктуры. Затем повторить проверки на той же выборке и сохранить новые свидетельства. Не отключать защиту сайта целиком ради исчезновения одной ошибки в отчёте.
Уровень | Достаточное свидетельство для этого этапа | Что остаётся неизвестным |
|---|---|---|
Политика | Правило для нужного клиента и URL соответствует решению владельца | Дошёл ли реальный запрос |
Доставка | Подтверждённый клиент получил ожидаемый ответ и контент | Будет ли документ индексироваться |
Индексация | Проверены актуальные данные о странице в Google | Будет ли она выбрана для конкретного ответа |
GEO-наблюдение | Сохранены запрос, ответ, источник, дата и условия проверки | Стабильность результата на других запросах |
Технические требования Google разделяют доступность, успешный HTTP-ответ и индексируемое содержание; даже их выполнение не гарантирует индексацию. Первоисточник: Google Search technical requirements.
Для Google сначала сопоставляйте отчёт об индексированной версии страницы и текущую проверку, а затем реальные обращения в логах. Свежий тест не переписывает историю последнего обхода. Возможность посмотреть полученный HTML и ресурсы описана в документации инструмента, на которую ссылается руководство Google по AI-функциям.
В отчёте разделяйте два результата: «устранили препятствие для получения документа» и «наблюдаем изменение видимости». Между ними могут быть повторный обход, переобработка и изменение состава ответов. Если после исправления выросло число цитирований, это повод для дальнейшего сравнения, а не готовое доказательство причинности.
Рабочий результат такого аудита — набор проверяемых утверждений: какой клиент пришёл, чем подтверждена его идентичность, какое правило применилось и какой документ он получил. С этого основания уже можно обсуждать качество источника и его присутствие в AI-поиске.
