Claude тянет выдачу из Brave в 86.7% случаев — и там...

Claude тянет выдачу из Brave в 86.7% случаев — и там решают поведенческие, а не бэклинки

Корреляционный анализ Profound фиксирует 86.7% пересечения между ссылками Claude и топом органики Brave.

Документация Anthropic по субпроцессорам прямо называет Brave провайдером; функция веб-поиска содержит параметр BraveSearchParams; интеграция Claude в Google Cloud Vertex AI указывает Brave открытым текстом.

Полевые тесты подтверждают: Claude вытягивает страницы из топа Brave, даже если Google их еще не проиндексировал, и игнорирует топ Bing вне индекса Brave.

Perplexity и ChatGPT показывают слабую корреляцию с Brave — оптимизировать нужно именно связку Brave/Claude.

Brave Search опирается на два инпута: BraveBot для классического краулинга и Web Discovery Project (WDP) — поток opt-in сигналов из браузера Brave.

WDP лежит в опенсорсе (github.com/brave/web-discovery-project) и читается как алгоритм ранжирования на JavaScript.

До того как сигнал уйдет из браузера, WDP прогоняет фильтр validDoubleFetch().

Страницы отбрасываются, если совпадает хоть что-то: нет тайтла хотя бы в одном фетче, стоит noindex, несовпадение каноникала, разница длины HTML между авторизованным и анонимным фетчем ниже 10% или выше 90%, поле пароля только в анонимном фетче, форма только в анонимном.

Страница, которая отдает каноникал залогиненным юзерам, но скрывает его от анонимных краулеров, генерирует ноль WDP-сигналов.

Закрытые логином, персонализированные страницы с расхождением HTML в пайплайн не попадают.

Стек сигналов WDP по убыванию силы:

1. Корреляция запроса (qr.q) — запрос в Brave, который привел к клику, плюс глубина (максимум 2). Эквивалент связки запрос→страница, которую Google держит в GSC, только собирается на стороне клиента. Самый сильный сигнал в системе.

2. Активное время (a) — инкрементируется каждую секунду только если за последние 5 секунд зафиксировано взаимодействие (движение мыши, скролл, нажатие клавиши, копирование, клик). Фоновые вкладки отдают почти нулевой a независимо от времени жизни.

3. События копирования (e.cp) — пассивный сигнал с самым высоким интентом. Требует накопленного активного времени, целенаправленного выделения текста и явного копирования. Контент, из которого можно вытащить пользу (данные, определения, код, фреймворки), генерирует больше e.cp, чем размытый текст — так задумано алгоритмом.

4. Глубина скролла (x.lt) и события скролла (e.sc) — схлопываются до одного в секунду; e.sc = 12 означает 12 уникальных секунд скролла, а не 12 сырых событий.

5. Клики по внутренней перелинковке (массив c) — фиксируется каждый внутренний клик, отдавая Brave навигационный граф на основе реальных юзеров в отрыве от графа краулинга. Мощная перелинковка бустит сигнал для вложенных страниц.

Каждое событие вовлеченности проходит двойной гейт: оно засчитывается, только если уже накопилось a > 1 секунды, а каждый тип события троттлится до одного инкремента в секунду — учитываются уникальные секунды взаимодействия, а не количество действий.

Синтетические высокочастотные клики сигнал не раздувают.

PAGE_WAIT_TIME = 5000ms — WDP собирает структурные данные строго через 5 секунд после загрузки.

Страницы, которые не успели отрендериться к этому моменту, отдают урезанный пейлоад.

Сессии дольше deadTwentyMts = 20 minutes капятся и отправляют частичные данные.

Сигналы шифруются через протокол STAR — Brave читает агрегированные данные только после того, как 20 уникальных /24 подсетей отправят один и тот же URL (поле oc форсирует разнообразие подсетей).

WDP не учитывает: бэклинки, социальные сигналы, возраст домена, микроразметку.

Бэклинки всё ещё управляют приоритизацией краулинга BraveBot, но слой ранжирования по ПФ, который кормит Claude, читает поведение, а не графы.

@MikeBlazerX

⚠️ Закрытый канал: @MikeBlazerPRO