Длинный перечень источников у одной нейросети ещё не означает, что она чаще подтверждает бренд ссылками. Ноябрьский индекс Dopbot показывает конкретную причину: разные API возвращают списки с разным смыслом и объёмом.
Что видно в категории матрасов
В американском срезе Dopbot за неделю 2 ноября 2026 года списки OpenAI содержали в среднем 2,4 домена на ответ, Perplexity 14,8. Это 40 ответов по пяти вопросам, двум системам и четырём повторам. В колонках каждой системы по 20 ответов.
Домен Forbes попал в список у Perplexity в 19 из 20 ответов, а у OpenAI ни разу. Эти числа описывают исходные списки данной категории, а не преимущество издателя во всех ИИ-системах.

Ключевое уточнение дано в методике Dopbot: для OpenAI сохраняются страницы, на которые ответ ссылается, а для Perplexity почти всегда все найденные поиском страницы; API не сообщает, на какие из них опирается ответ. Поэтому общий список называется найденными источниками, а не единым рейтингом текстовых цитат.
Почему общий итог может обмануть команду
Наш вывод: если сложить такие списки, система с более широким возвращаемым полем может определять общий состав доменов. Это свойство наблюдаемых данных. Оно не устанавливает, что её модель больше доверяет каждому источнику.
Здесь важно не только число ответов в знаменателе. Даже равные 20 ответов не делают одинаковым событие в числителе: ссылка ответа и страница среди поисковых находок требуют разных подписей. Увеличение размера списка тоже не показывает, что компания получила рекомендацию.
| Поле | Что можно сказать |
|---|---|
| Домен в возвращённом списке | Зафиксировано присутствие в этом поле API |
| Ссылка привязана к утверждению ответа | Зафиксирована обозначенная связь с фрагментом |
| Компания предложена покупателю | Зафиксирована рекомендация при условиях вопроса |
Сам индекс коммерческий, собран через API, а не потребительские приложения. Его небольшая категория и набор вопросов не представляют рынок матрасов целиком. Вопрос о наличии конкретной марки в выборе клиента остаётся отдельным.
Как проверить собственное объединение
Процедура нужна команде, которая объединяет выгрузки нескольких систем. Возьмите один действующий отчёт, где домены сведены в общий рейтинг, и найдите описание исходного поля для каждой системы. Понадобятся сохранённые ответы, списки URL и сведения о сборщике. Если смысл поля не документирован, поставьте «не установлен» и запросите его описание у владельца сбора.
Заведите паспорт колонок: система, версия сборщика, точное название поля, какие URL оно содержит, число пригодных ответов и способ удаления повторов. Проверьте описание на одном полном ответе каждой системы: какие ссылки видны в тексте, какие присутствуют только в возвращённом списке. Этот разбор устанавливает наблюдаемое различие, а не скрытую логику модели.
Если события различаются, разделите таблицу по системам и переименуйте показатели по фактически наблюдаемому событию. Не восстанавливайте неизвестные цитаты из поискового списка. Общий итог допустимо оставить только с ясной подписью о смешанном составе; для решения о контенте используйте сопоставимые поля.
Результат: паспорт источников данных и исправленная таблица, из которой понятно, какой этап участия страницы измеряется. Только после этого выбирайте конкретную страницу для содержательного разбора: вопрос покупателя, факт ответа и подтверждение по точному URL. Длина списка сама по себе не обосновывает размещение у издателя или переписывание сайта.