Почему визит AI-бота не равен цитированию

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

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

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

Fetch — HTTP-запрос и ответ сервера. Index signal — наблюдаемое указание на обнаружение или поисковую пригодность, например запись панели; лог сам по себе его не создаёт. Retrieval — внутренний отбор документа для конкретного ответа и обычно недоступен. Mention — сохранённый текст ответа называет страницу, бренд или сущность. Citation — ответ содержит проверяемую ссылку или атрибуцию именно этого источника. Referral — пользователь пришёл по ссылке или referrer. Соседние события могут совпасть по времени, но не доказывают друг друга: визит робота не становится цитатой автоматически.

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

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

Для fetch нужен access-log event с временем, URL, status и размером ответа. Для verified bot нужны совпадающие User-Agent, официальный диапазон IP и сохранённая версия списка. Perplexity публикует раздельные роли PerplexityBot и Perplexity-User и отдельные endpoints; OpenAI указывает официальный JSON для проверки диапазонов. Для citation нужен архив полного ответа или скриншот с видимой ссылкой, URL и временем. Для referral нужен независимый аналитический или серверный переход. Для retrieval пригодного публичного доказательства обычно нет: значение должно оставаться unknown, а не выводиться из графика.

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

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

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

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

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

Пример: `2026-09-11T10:14:02Z | /en/research/crawler-access-vs-citation/ | 200 | UA=PerplexityBot/1.0 | IP=verified | list=perplexitybot.json@2026-09-11 | event=fetch`. Он допускает только вывод «PerplexityBot получил HTML». Ложное срабатывание возникает, если скрипт копирует UA, CDN-запрос принят за посетителя, fetch повторён из кэша или ответ ссылается на домен, но не на эту страницу. Нельзя считать OAI-SearchBot, GPTBot и Perplexity-User взаимозаменяемыми.

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

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

Зафиксируйте URL и окно; включите JSON-логи; ежедневно сохраняйте официальные IP endpoints с хэшем; классифицируйте unknown → claimed → verified; проверьте случайную выборку; заранее зарегистрируйте набор вопросов; сохраняйте полный ответ, режим, регион и ссылки; отдельно считайте fetch, mention, citation и referral; публикуйте агрегаты с ясным знаменателем. Следующий тест: десять одинаковых вопросов, три повтора на поверхность и 30 дней наблюдений. Совпадение fetch и citation обозначайте как корреляцию, не причинность.

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

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

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

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

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

Для каждого запуска сохраняйте run_id, canonical URL, hash страницы, surface, prompt, locale, region, mode, timestamp, raw response, parsed links, bot identity, HTTP status, source match и decision. Пустое decision означает unknown, а не ноль.

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

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