AI-краулеры и GEO: почему robots.txt разрешает обход, а сайт остаётся недоступным

Открытый 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-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 зафиксируйте время, хост, тип клиента, способ идентификации и результат.

Это направления проверки, а не автоматические диагнозы. Отсутствие записи на 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. Как принять исправление

Предлагаю следующий порядок приёмки. Сначала зафиксировать конкретную неисправность и согласовать изменение с владельцем инфраструктуры. Затем повторить проверки на той же выборке и сохранить новые свидетельства. Не отключать защиту сайта целиком ради исчезновения одной ошибки в отчёте.

Технические требования Google разделяют доступность, успешный HTTP-ответ и индексируемое содержание; даже их выполнение не гарантирует индексацию. Первоисточник: Google Search technical requirements.

Для Google сначала сопоставляйте отчёт об индексированной версии страницы и текущую проверку, а затем реальные обращения в логах. Свежий тест не переписывает историю последнего обхода. Возможность посмотреть полученный HTML и ресурсы описана в документации инструмента, на которую ссылается руководство Google по AI-функциям.

В отчёте разделяйте два результата: «устранили препятствие для получения документа» и «наблюдаем изменение видимости». Между ними могут быть повторный обход, переобработка и изменение состава ответов. Если после исправления выросло число цитирований, это повод для дальнейшего сравнения, а не готовое доказательство причинности.

Рабочий результат такого аудита — набор проверяемых утверждений: какой клиент пришёл, чем подтверждена его идентичность, какое правило применилось и какой документ он получил. С этого основания уже можно обсуждать качество источника и его присутствие в AI-поиске.