Rearrange: 380 переранжирований верхнего метапоиска - главный SEO-слой

[anna_seo]

Rearrange: 380 переранжирований верхнего метапоиска

Когда сеошник говорит "позиция документа", он чаще всего имеет в виду результат работы формулы ранжирования. Утечка исходников показывает, что это лишь половина картины. Поверх скоринга, на уровне верхнего метапоиска (то, что в коде называется upper search), сидит отдельный фреймворк правил - rearrange. Он берёт уже посчитанную и слитую выдачу и переписывает её: переставляет, склеивает дубли, режет хосты, бустит свежее, пессимизирует спам, выкидывает забаненное. Каталогов правил в web/rearrange/ ровно 380. Именно этот слой формирует то, что пользователь реально видит в топе - и именно поэтому он критичен для SEO не меньше, чем сама формула.

Скоринг считает "насколько документ хорош". Rearrange решает "что из хорошего показать и в каком порядке". Видимый топ - это выход 380 правил, наложенных поверх релевантности.

Срез данных - примерно 2022 год. Имена правил, пороги и веса с тех пор могли поменяться; приведённые формулы иллюстративны, реальные коэффициенты обучаемы и проприетарны.

Фреймворк: как устроено правило

Каждое правило rearrange регистрируется одним макросом и наследует общий контекст. Дальше движок прогоняет правило в одной из фаз конвейера.

Код: Выделить всё

Регистрация правила:
  REGISTER_REARRANGE_RULE(name, creator)   web/core/rule.h:21
  наследует IRearrangeRuleContext         web/core/rule.h:27

Фазы исполнения (web/core/rule_factory.h:42):
  RRP_AFTER_SEARCH    после поиска по шардам
  RRP_AFTER_MERGE     после слияния шардов в единую выдачу   <-- главная для SEO
  RRP_BEFORE_FETCH    до подтяжки тел документов
  RRP_AFTER_FETCH     после подтяжки (снова доступны дубли/тексты)
  + AFTER_META_FEATURES / RANK, ENRICH_DOCS

Главный хук: DoRearrangeAfterMerge   web/core/rule.h:98

Ключевой момент - фаза AFTER_MERGE. До неё выдача существует по кускам (по шардам индекса). После merge есть единый список документов, и правило видит топ целиком: сколько в нём доков с одного хоста, есть ли дубли, кто свежий, кто спам. Поэтому большинство SEO-значимых решений - разгруппировка, контроль хостов, антидуп, пессимизация спама - принимаются именно в DoRearrangeAfterMerge, когда правило может оценить выдачу как целое, а не отдельный документ.

Каждое правило управляемо извне через cgi-параметры: выключить - &rearr=Name_off (или all_off для всех), включить отладку - &rearr=Name_dbg=1. Это даёт инструмент изоляции: можно посмотреть, как менялась бы выдача без конкретного правила.

SEO-критичные правила AfterMerge

Ниже - разбор правил, существование каталогов которых подтверждено в web/rearrange/. Это не весь список из 380, а та его часть, которая прямо двигает коммерческий и информационный топ.

Код: Выделить всё

ПРАВИЛО              КАТАЛОГ web/rearrange/    ЧТО ДЕЛАЕТ С ВЫДАЧЕЙ
-----------------    ---------------------     --------------------------------------
AntiSeoResetFactors  antiseo_reset_factors/    Обнуляет блок ссылочных/SEO-факторов
                                               для коммерч. RU-запросов через
                                               pron=disablefactorsgroup:...
Antispam             antispam/                 ML-классификатор спама (SpamFormulaId),
                                               пессимизация скора; может слать в бан
AntiDup              antidup/                  Удаление/склейка дублей URL,
                                               пессимизация клонов; работает дважды
FilterBanned         filterbanned/ (+video/,   Жёсткое удаление доков из бан-листа
                     imgban/)
Fresh / FreshBoost   fresh/, fresh_boost/,     Детект свежих по _DateSource,
FreshFilterMiddle    ...                       группа d_fresh, буст новизны
UnGroupVital         ungroup_vital/            Разгруппировка ради разнообразия,
                                               доки с разных хостов, гео-фильтр
HostPresence /       host_presence/,           Лимит числа доков одного хоста в
HostClassifier       hostclassifier/           топе; классификация хостов по типу
Trash / NarcoPess /  trash/, narco_pess/,      Понижение мусора, тематические и
Porno / Family       porno/, family_filter/    возрастные фильтры
Authority /          authority_boost/,         Повышение авторитетных источников,
AdditiveBoost        additive_boost/           суммирование бустов
ITDITP*              itditp_diversity_exp.../  Разнообразие и персонализация
                     itditp_antidup/,          выдачи (эксперименты)
                     itditp_personalization/

AntiSeoResetFactors - самое говорящее для оптимизатора правило. Для коммерческих русскоязычных запросов оно обнуляет целый блок ссылочных и SEO-факторов командой pron=disablefactorsgroup:... То есть на части запросов накачанное ссылочное просто перестаёт участвовать в ранжировании на этом слое. Это прямой ответ на вопрос, почему ссылочные стратегии в коммерции работают нестабильно: их влияние может гаситься правилом до того, как пользователь увидит топ.

Antispam - не бинарный фильтр, а ML-классификатор с обучаемой формулой (SpamFormulaId). Документ получает spamRating, а итоговая пессимизация считается линейно.

Код: Выделить всё

penalty = -(PessFactor * spamRating + PessSummand)
   config.cpp:34   antispam.cpp:30

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

AntiDup закрывает классику: региональные клоны магазинов, репосты, карточки одного товара в каталоге. Важная деталь - правило работает дважды, в AfterMerge и снова в AfterFetch, когда подтянуты тела и сравнение точнее. Вместо удаления клон часто пессимизируется, то есть остаётся в индексе, но опускается.

UnGroupVital и HostPresence/HostClassifier - это разнообразие выдачи. Первое разгруппировывает результаты, вытягивая документы с разных хостов и применяя гео-фильтр; вторые ограничивают, сколько страниц одного хоста допустимо в топе, и классифицируют хосты по типу. Для SEO это потолок: даже идеально релевантный сайт не займёт топ целиком.

Fresh/FreshBoost детектят свежесть по _DateSource, формируют отдельную группу d_fresh и бустят новизну - механика, поднимающая новости и свежие посты. Trash/NarcoPess/Porno/Family - тематические и возрастные понижения; типичная форма пессимизации здесь:

Код: Выделить всё

SetRelevance(rel - pess * SCALE)

Authority/AdditiveBoost работают в обратную сторону - повышают авторитетные источники и суммируют бусты. Семейство ITDITP* (itditp_diversity_experiment, itditp_antidup, itditp_personalization) отвечает за разнообразие и персонализацию, то есть подстройку под конкретного пользователя поверх общего ранжирования.

Document filtering: почему документ выпал

Отдельный механизм инструментирует причины, по которым документ не дошёл до выдачи. Это enum состояний фильтрации - около 30 причин.

Код: Выделить всё

enum EFilteringState   document_filtering/document_filtering.h:22

  PASSED                                    прошёл
  FILTERED_BY_PRUNING                       отсечён прунингом (ранний обрез)
  FILTERED_BY_QUORUM                        не набрал кворум по словам запроса
  FILTERED_BY_ANTISPAM                      зарезан антиспамом
  FILTERED_BY_DYNAMIC_ANTISPAM             похоже на sandbox / временный бан
  FILTERED_BY_PORNO                         порно-фильтр
  FILTERED_BY_EMBEDDING_STORAGE_DOT_PRODUCT_TOP   отсев по близости эмбеддингов
  ... (~30 состояний всего)

Практическая ценность для оптимизатора - в дифференциации диагноза. "Документ не в топе" - это не одно состояние, а как минимум разные ветки: его обрезали прунингом на раннем этапе (не дошёл по производительности/порогу), он не набрал QUORUM (не хватило вхождений слов запроса), его срезал статический ANTISPAM, либо он попал в DYNAMIC_ANTISPAM - динамический антиспам, который выглядит как песочница или временный бан, то есть состояние, из которого документ со временем может выйти. Отдельная ветка - отсев по эмбеддингам (EMBEDDING_STORAGE_DOT_PRODUCT_TOP), то есть документ отрезан не по тексту, а по семантической близости в векторном пространстве.

Вывод

Формула ранжирования - необходимое, но не достаточное условие топа. Поверх неё 380 правил rearrange решают, что выживет в видимой выдаче. AfterMerge - главная фаза: именно там правятся дубли, хосты, свежесть, спам и SEO-факторы уже на слитом списке.

Для SEO из этого следует прямой вывод: оптимизировать только под скоринг недостаточно. Сайт может быть релевантным по формуле и при этом упираться в HostPresence (лимит на хост), терять ссылочный вес на AntiSeoResetFactors, склеиваться в AntiDup или пессимизироваться Antispam. Реальная работа идёт против двух слоёв сразу - ранжирующего и переранжирующего, причём второй переписывает результат первого последним. Ещё раз дисклеймер: срез примерно 2022 года, конкретные имена правил, пороги и веса могли смениться, формулы здесь иллюстративны.