Вопрос и статус

Вопрос: какую часть пути от обращения к странице до ответа AI видит владелец сайта? Мы используем цепочку: обращение к странице → сигнал индекса → поиск материала системой → упоминание → ссылка → переход. Это схема измерения, а не утверждение о закрытом устройстве платформ. Исследование обобщает публичные документы OpenAI, Perplexity и Google. Одинаковой выборки ответов во всех системах нет, поэтому здесь нет рейтинга, долей или причинного эффекта. Цель — не обещать видимость, а показать, какие данные нужны для каждого более сильного вывода.

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

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

Модель событий

Получение страницы — HTTP-запрос и ответ сервера. Сигнал индекса — наблюдаемое указание на обнаружение или пригодность страницы для поиска, например запись панели; лог сам по себе его не создаёт. Выбор документа для конкретного ответа обычно недоступен наблюдателю. Упоминание — сохранённый ответ называет страницу, бренд или организацию. Ссылка в ответе — ответ содержит проверяемую ссылку на этот источник. Переход — пользователь пришёл по ссылке. Эти события могут совпасть по времени, но не доказывают друг друга: визит робота автоматически не становится ссылкой в ответе.

Эти события лучше считать независимыми точками наблюдения, а не последовательной воронкой. Обращение к странице может предшествовать обновлению индекса; цитата может появиться без свежего видимого обращения; переход зависит от поведения человека после ответа. Это не означает, что связи нет, но запрещает причинный вывод без сопоставимого теста. В отчёте рядом с числом должны быть оператор, URL, период, способ сбора и определение события. Иначе слово «видимость» смешает техническую доступность и пользовательский результат.

Источники раздела:[2] Perplexity Docs

Матрица доказательств

Для обращения к странице нужна запись журнала доступа со временем, URL, статусом и размером ответа. Для подтверждённого бота нужны совпадающие User-Agent, официальный диапазон IP и сохранённая версия списка. Perplexity публикует раздельные роли PerplexityBot и Perplexity-User и отдельные точки доступа; OpenAI указывает официальный JSON для проверки диапазонов. Для цитирования нужен архив полного ответа или снимок экрана с видимой ссылкой, URL и временем. Для перехода нужна независимая аналитическая или серверная запись. Надёжного публичного доказательства поиска материала системой обычно нет: значение должно оставаться «неизвестно», а не выводиться из графика.

Матрица работает только при сохранении исходных материалов. Для лога нужны строка запрос, статус и версия классификатора; для панели — снимок или экспорт с датой; для ссылка в ответе — полный ответ и точный URL; для переход пользователя — независимая запись перехода. Связывайте каждый файл с идентификатор утверждения и версией страницы. Если артефакт нельзя открыть повторно, его сила уменьшается. Это особенно важно при исправлениях: новый текст не должен незаметно переписывать смысл старого наблюдения.

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

Проверка UA/IP/rDNS

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

Результат проверки должен быть воспроизводимым, а не просто ярлыком в аналитике. Сохраните исходный запрос, время DNS-проверки, используемый официальный список и итоговый статус. Для выборки посмотрите несколько запросов одного робота и несколько URL: единичное совпадение не показывает стабильность. При расхождении не повышайте уверенность вручную. Классификация неизвестно честнее, чем запись «бот» по одной строке User-Agent, и не создаёт ложной связи между техническим визитом и будущим ответом.

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

Пример и ложные срабатывания

Пример записи: `2026-09-11 10:14 UTC | /en/research/crawler-access-vs-citation/ | ответ 200 | робот PerplexityBot/1.0 | IP подтверждён | список адресов проверен 2026-09-11 | событие: страница получена`. Из неё следует только одно: PerplexityBot получил HTML-код страницы. Ошибка классификации возможна, если сторонний скрипт скопировал имя робота, запрос сети доставки контента принят за посетителя, страница отдана из кэша или AI-ответ ссылается лишь на домен, но не на эту страницу. OAI-SearchBot, GPTBot и Perplexity-User выполняют разные роли, поэтому объединять их нельзя.

Разберём допустимый вывод по шагам. Сначала подтверждаем личность робота; затем проверяем, что сервер отдал нужный адрес страницы и HTML; затем отдельно ищем совпадающий ответ в интерфейсе и проверяем, ведёт ли ссылка именно на эту страницу. Если второго подтверждения нет, итог — только получение страницы. Даже совпадение по времени остаётся совпадением: страницу мог получить робот, а ответ — сформироваться из другого индекса или уже сохранённого контекста.

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

Воспроизведение

Заранее определите адреса страниц и период наблюдения. Включите структурированные журналы сервера в формате JSON и ежедневно сохраняйте официальные списки IP-адресов роботов вместе с контрольной суммой файла. Присваивайте запросам понятный статус: «неизвестно», «заявленное имя робота» или «подтверждённый робот»; затем вручную проверьте случайную выборку. До начала теста зафиксируйте набор промптов, а для каждого запуска сохраняйте полный ответ, режим, регион и показанные ссылки. Отдельно считайте получение страницы роботом, упоминание бренда, показ ссылки в AI-ответе и переход человека. Рядом с каждой долей показывайте исходное количество. Следующий тест: десять одинаковых промптов, три повтора в каждом интерфейсе и 30 дней наблюдений. Если получение страницы и показ ссылки совпали по времени, называйте это связью, а не доказанной причиной.

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

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

Как читать результат без переобобщения

Записывайте результат как сочетание поверхности, вопроса, времени и артефакта. Затем отдельно отвечайте: был ли запрос, был ли доступен HTML, появилась ли страница в ответе и подтверждала ли ссылка конкретный тезис. Если последний ответ неизвестен, не используйте слово «цитирование».

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

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

Минимальный набор полей для аудита

Для каждого запуска сохраняйте идентификатор, основной адрес страницы, хэш страницы, интерфейс, запрос, язык и регион, режим, дату и время, полный ответ, извлечённые ссылки, подтверждение личности бота, статус HTTP, соответствие источника и итоговое решение. Пустое решение означает неизвестность, а не ноль.

Храните снимок решения вместе с входными данными: когда источник изменён, старый результат остаётся доступным для сравнения. Это превращает аудит в версионируемую процедуру, а не в разовую цифру.

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

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

  • Публичные документы не раскрывают внутренний поиск и отбор страниц и полный список кандидатов; прокси, кэши и поддельные UA искажают картину.

Источники

  1. 1
    Overview of OpenAI crawlersOpenAI Developers · official · 11 сент. 2026 г.
  2. 2
    Perplexity crawlersPerplexity Docs · official · 11 сент. 2026 г.

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

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