Исследовательский вопрос и рынок

Этот выпуск рассматривает практическую ошибку «разрешить всех AI-ботов» или «запретить всех AI-ботов». В реальности публичный сайт может быть нужен поиску, answer-engine, обучающему сборщику, агенту, рекламной системе и мониторингу, причём у каждого класса свои цели и политика. Официальные документы OpenAI и Google дают названия и назначение части роботов, но не раскрывают полный путь от обхода к ответу. Поэтому результатом исследования является матрица решений, а не обещание индексации.

Источники раздела:[1] OpenAI[2] OpenAI Developers[3] Google Search Central

Классы доступа OpenAI

OpenAI отдельно описывает поисковые, пользовательские и обучающие сценарии. Это означает, что владелец сайта может принять разные решения: разрешать поисковому роботу для обнаружения страниц, не разрешать сборщик обучения, ограничивать агентный fetch или оставить его открытым для конкретного опыта. Название User-Agent само по себе недостаточно: проверяйте официальные диапазоны IP или reverse DNS там, где оператор их публикует, и не доверяйте произвольной строке заголовка. Политика должна быть версионированной и объяснять, зачем принято каждое правило.

Источники раздела:[1] OpenAI[2] OpenAI Developers

robots.txt и его пределы

Google определяет robots.txt как способ сообщить краулеру, какие пути можно обходить. Это не пароль, не удаление уже известного URL и не гарантия, что поисковая система не сохранит заголовок или ссылку. Закрытый путь также может быть доступен обычному пользователю, если нет авторизации. Для приватных материалов нужен контроль доступа на сервере. Для публичных страниц robots.txt следует проверять вместе с HTTP-ответом, canonical, sitemap, noindex и фактическим обходом. Иначе одна строка robots.txt будет неправильно описана как полная политика видимости.

Источники раздела:[3] Google Search Central[4] Google Search Central

Поиск, обучение, агент и реклама

Четыре решения нельзя объединять в один переключатель. Поисковый обход связан с обнаружением и индексными сигналами; обучение — с отдельной лицензией или политикой использования данных; пользовательский fetch — с конкретным запросом человека; рекламный бот — с оценкой рекламного размещения. Разрешение одного класса не означает, что сайт будет процитирован. Запрет другого класса не означает исчезновение домена из всех поверхностей. В публичной документации нужно показывать таблицу «цель → робот → разрешение → что это не доказывает».

Источники раздела:[1] OpenAI[2] OpenAI Developers[3] Google Search Central[4] Google Search Central

Как проверять на практике

Проверка начинается с inventory URL и ожидаемых статусов. Для каждого оператора сохраните User-Agent, дату, IP-проверку, URL, HTTP-код, redirect chain, размер ответа и наличие закрывающих директив. Отдельно проверьте страницу через обычный браузер и через авторизованный тестовый путь. Не отправляйте в публичный pipeline закрытые снимки или клиентские URL. Если CDN выдаёт challenge, это наблюдение о доступности, но не доказательство запрета со стороны оператора. Повторяйте тест после изменения правила и храните diff.

Источники раздела:[1] OpenAI[2] OpenAI Developers[3] Google Search Central[4] Google Search Central

Ошибки интерпретации

Самая опасная ошибка — назвать отсутствие визита доказательством отсутствия в AI-ответах. Другие ошибки: считать User-Agent подлинным без проверки IP, считать разрешение robots.txt гарантией crawl, смешивать OpenAI SearchBot и GPTBot, публиковать закрытый источник через sidecar, а также использовать общий score для технической доступности и фактической цитаты. Каждое утверждение должно иметь уровень: observed, inference или hypothesis. Если данных недостаточно, правильное значение — unknown, а не ноль.

Источники раздела:[1] OpenAI[2] OpenAI Developers[3] Google Search Central[4] Google Search Central

Вывод и пересмотр

Публичная политика GeoAeoAle должна быть адресной: перечислять классы доступа, цель, техническое правило и границу вывода. Контент можно разрешать поиску и пользователю, не открывая закрытые артефакты и не обещая цитирование. Следующий пересмотр нужен при изменении документации, IP-диапазонов, CDN-политики или появлении нового типа робота. Дата 11 октября 2026 года — контрольная точка, а не декоративная дата обновления.

Источники раздела:[1] OpenAI[2] OpenAI Developers[3] Google Search Central[4] Google Search Central

Решение для редакционного реестра

Реестр должен хранить не только allow или deny, но и цель правила, дату проверки и фактический результат. Для одного URL полезно иметь отдельные строки для поискового краулера, пользовательского fetch и обучающего сбора; рядом указывается, подтверждён ли оператор официальным диапазоном IP или reverse DNS. При изменении CDN, WAF или robots.txt старую запись нельзя перезаписывать без истории. Это позволяет сравнить обещанную политику с реальным HTTP-доступом и не публиковать громкий вывод по одному заголовку. В публичной статье такая схема превращает техническое решение в воспроизводимую процедуру: читатель видит, что проверялось, когда, каким способом и какой вывод всё ещё недоступен.

Источники раздела:[1] OpenAI[2] OpenAI Developers[3] Google Search Central[4] Google Search Central

Контрольный список перед публикацией

Перед публикацией редактор должен ответить на четыре вопроса. Какая именно цель доступа описывается: поиск, обучение, пользовательский запрос, агент или реклама? Какой оператор и какой путь подтверждены документом? Что реально наблюдалось в HTTP или в интерфейсе, а что осталось неизвестным? И какая дата следующего пересмотра нужна, если политика или инфраструктура изменятся? Ответы записываются рядом с claim, а не прячутся в техническом приложении. Такой контроль защищает читателя от распространённой ошибки: превратить разрешение robots.txt в обещание индексации или принять один неудачный запрос за полное отсутствие страницы. Он также делает еженедельный выпуск полезным для инженера: из текста можно сразу извлечь тест, ожидаемый результат и условие остановки.

Источники раздела:[1] OpenAI[2] OpenAI Developers[3] Google Search Central[4] Google Search Central

Редакционная репликация

Публичная документация описывает границы доступа, но не раскрывает весь внутренний путь выбора источника. Поэтому корректная публикация должна показывать конкретную формулировку документа, дату проверки и область, на которую она распространяется. Там, где документация молчит, мы используем метку unknown и предлагаем воспроизводимый тест. Это сохраняет пользу материала и не превращает предположение о поведении краулера в факт.

Что это не доказывает

  • Документация описывает заявленные правила доступа, но не раскрывает внутренний выбор источников; отсутствие наблюдения следует считать unknown, а не нулём.

Источники

  1. 1
    Publishers and developers FAQOpenAI · official · 11 сент. 2026 г.
  2. 2
    Overview of OpenAI crawlersOpenAI Developers · official · 11 сент. 2026 г.
  3. 3
    Introduction to robots.txtGoogle Search Central · official · 11 сент. 2026 г.
  4. 4
    Google Search technical requirementsGoogle Search Central · official · 11 сент. 2026 г.

История исправлений

Существенных исправлений пока нет.