Отбор в индекс и тиры (selectionrank): почему страница не попадает в базу

[anna_seo]

Отбор в индекс и тиры (selectionrank): почему страница не попадает в базу

Перед тем как страница вообще получит шанс ранжироваться по запросу, она проходит этап, о котором в SEO почти не говорят: отбор в индекс и присвоение тира. Это не выдачный фактор - это фильтр на входе. Совмещение двух утечек (робот Яндекса, отвечающий за краулинг и индексацию, и рантайм формирования выдачи в search/) показывает, что поиск двухслоен. Робот отвечает за индексную правду - ЧТО попадёт в базу, какой URL станет каноном-носителем, с какой статикой/датой/тематикой и в каком тире. Ранжирование (вес в выдаче) - это уже преимущественно поведение, нейро-рантайм и запрос, которые в роботе не считаются.

Сам факт тира - сильный статический сигнал качества. И он же определяет, для каких документов вообще существуют индексные факторы. Тонкая или некачественная страница не проигрывает в выдаче - её там просто нет.

Дисклеймер. Робот - срез примерно 2022 года, факторы - web_production 2026. За годы слоты добавлялись и умирали, имена proto-полей и пайплайнов могли смениться. Веса формулы иллюстративны - реальные обучаемы (GBDT плюс NN) и проприетарны. Соответствия имён установлены по семантике сигнала, а не по точному совпадению cpp_name.

Где живёт отбор: selectionrank над TFactorStorage

Ключевой компонент - selectionrank. Он не порождает ни одного выдачного FI_-фактора, но решает судьбу документа: попадёт ли он в верхний тир или будет вытеснен в нижний. Механика - MatrixNet-формула над TFactorStorage, который наполняется стадией PrepareWebFactors. На вход идёт статика, накопленная роботом:

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

PrepareWebFactors -> TFactorStorage:
  DocErf       статические документные ERF-факторы
  DocLinkErf   ссылочные ERF (Link-Ann, lerf2)
  PageRank     классическая ссылочная статика
  MaxFreq      частотная статика документа
  USLP-static  USLongPeriod поведенческая статика (окна до 1600 дней)

selectionrank (MatrixNet) -> назначение тира:
  Platinum / WebTier0   верхние тиры (полный набор факторов)
  RobotTier             нижний тир (усечённый/отсутствующий набор)

Логика двусторонняя. С одной стороны, тир - это выход модели качества: документ с сильным DocErf, нормальным PageRank, реальной поведенческой историей USLP попадает в Platinum/WebTier0. С другой - попадание в тир определяет, для каких документов вообще существуют индексные use_artifact-факторы. То есть нижний тир - это не просто слабая позиция, это отсутствие части факторного аппарата. Документ в RobotTier физически беднее по сигналам, чем документ в Platinum, ещё до всякого запроса.

Жёсткие исключения: fast_ban и robots_txt

Параллельно с тирингом работает операционная фильтрация, которая выкидывает документ из индекса полностью, минуя MatrixNet:

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

robots_txt   запрет краулинга/индексации на уровне директив
fast_ban     операционное исключение из индекса (анти-спам, санкции)

Это важно отделять от слотов спам-классификаторов в формуле. Исторические whois- и контентные классификаторы - FI_SPAM_KARMA[107] (вероятность что хост спам, основан на whois), FI_SPAM2[99] (классификатор Алексеева), FI_NO_SPAM[52] - робот честно вычисляет: jupiter TAntispamErfs и Memorandum, rthub Antispam.sql (TmuCalc/DeduceCalc), lemur BanDetector, quality dns_spam_detector. Но слоты в формуле выдачи мертвы. Живёт FI_IS_FAKE[133] и именно операционная ветка: фильтрация ссылок и fast_ban-исключение из индекса. То есть антиспам сместился из выдачного веса в гейткипинг на входе.

Что определяет носителя факторов: канонизация

Прежде чем считать статику, робот должен выбрать ОДИН индексируемый документ. Этот слой - gemini/mirror/superdups/kwyt - не даёт ни одного FI_, но определяет носителя ВСЕХ остальных факторов:

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

gemini      CanonizedUrl / MainUrl / Owner (MIRROR/CANONIZE/OWNER/CASE_HOST)
mirror      выбор главного зеркала (composite rating: Shows/Clicks/IKS/CY)
superdups   карта супердубль -> main по simhash
kwyt        выбор IsLast-версии документа
jupiter     canonized_factors / TCanonizedFactors переносит факторы на канон

Без этого слоя owner-rollup, host-size, ссылочные веса и накопленное поведение размазались бы по дублям. Если зеркала не склеены (http/https/www живут раздельно), FI_HOST_SIZE[113] дробится, ссылочная масса распыляется, поведение не накапливается на одном URL. Это нулевой фактор, от которого зависят все прочие - и самый недооценённый вклад робота в ранжирование.

Какая статика реально питает тиринг

Даты. Самый чистый сквозной мост, группа Datetime жива на 8/8. FI_FIRST_VALID_TS_10DAYS[442] - возраст относительно времени валидности документа в самоваре (поле ValidState.FirstValiditySource). FI_DATER_ADDTIME_80HOURS[1861]/_10DAYS[1862] - данные датировщика RobotAddTime (samovar TRobotDate плюс quality/html_dater, MatrixNet на ~150 фич по сегментам HTML/meta/URL). FI_PAGE_DATE[345] извлекает rthub DateExtractor. Упаковка - стадия dater_remap в library/selectionrank в FinalErf.

Хостовая статика. FI_HOST_SIZE[113] (имени Расковалова) - размер хоста в документах без дублей. Требует и склейки зеркал, и owner-rollup. jupiter host/flows.cpp регистрирует THostRank/TOwnerReqsPopularity/TRegRegionalHostRank, мапит TExternalHostdat в THostErfInfoProto. lemur host/combine считает host-counters и тИЦ-подобные Cy/Acy. Оговорка: соседние FI_YABAR_HOST_*[249-255] и FI_BROWSER_HOST_CNT_DWELL_TIME_LOG[847] - это поведение хоста из Бара/Браузера, робот лишь привязывает значения к каноничному хосту.

Ссылочный граф. Строится полноценно: samovar экспортирует incoming_outgoing_links_export с IncomingLinksAggregations (Total/Hosts/Owners/Spam%/TextLenSum), lemur preparatprocessor собирает преparat входящих ссылок с анкорами, algo/links/seomark.h гоняет MatrixNet (105 фич) плюс CatBoost cb_venality (424 фичи), помечает GoodLink/SeoMark и отсекает накрутку - это классификатор за FI_LINK_QUALITY_FIXED[405]/FI_NEW_LINK_QUALITY_FIXED[407]. jupiter links.cpp строит Link-Ann (lerf2, TDocLinkErfInfoProto). Но классические XLR-факторы Гулина и вся LinkBM25 (0/9) мертвы. Вывод для SEO: покупка ссылок и анкорная накрутка бьют по мёртвым слотам, а живой сигнал DocLinkErf проходит через анти-SEO-фильтр SeoMark.

Что это значит для индексируемости

Тонкие и некачественные страницы уходят в нижний тир и фактически невидимы. Они не проигрывают конкуренту на пол-позиции - для них не формируется полный факторный аппарат, и в верхней выдаче они не появляются в принципе.

Практические следствия из устройства selectionrank:

• Тир назначается на статике - дата (свежесть/валидность по самовару), хостовая масса, PageRank, частотность и поведенческая история USLP. Документ без истории и без хостовой поддержки стартует в слабом тире.
• Канонизация первична. Расщеплённые зеркала и дубли дробят host-size, ссылки и поведение - и просаживают тир без видимой причины. Сначала чистая каноникализация, потом всё остальное.
• robots_txt и fast_ban - это бинарный гейт мимо MatrixNet. Если страница закрыта или попала под санкции, никакая статика не помогает.
• Ссылочная накрутка неэффективна по двум причинам: SeoMark/cb_venality отсекают плохие ссылки на входе, а классические ссылочные слоты в формуле мертвы.
• Поведенческая статика (USLongPeriod, окна до 1600 дней) - сильный вход в тиринг, но она копится на каноне годами. Молодой документ её просто не имеет.

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