Разбираю одно из самых чистых наблюдений из утечки исходников поиска (срез примерно 2022): семейство датовых факторов. Чистое оно потому, что здесь сквозной путь робот-индексатор -> фактор ранжирования прослеживается с обоих концов, без поведенческой подмеси из логов Бара или Браузера. Там, где у хостовых и owner-факторов значения по факту приезжают из userdata, а робот лишь привязывает их к каноничному ключу, у датовых факторов и носитель, и само значение рождаются на этапе индексации. Это и делает группу Datetime (тег TG_DATE) удобным учебным примером того, как статика накапливается при обходе и упаковывается в ERF.
Почему группа Datetime выделяется
В матрице сопоставления робот -> семейства факторов строка Datetime единственная имеет уровень уверенности high без оговорок про поведенческую природу значений. Формально группа живая на 8 из 8 по узкому счёту тегов и 13 из 19 по расширенному набору слотов. Для сравнения, соседние семейства либо мёртвы целиком (Domain 0/10, LinkBM25 0/9, Catalog 0/2), либо живы лишь как механизм при мёртвых слотах (классические Xref-релевантности Гулина), либо тащат значения из логов (TG_OWNER, BrowserHost). Датовые факторы в этом смысле автономны: робот сам и измеряет, и фиксирует, и пакует.
Три источника даты и три производителяКлючевой тезис: дата валидности и дата добавления документа накапливаются именно при индексации, материализуются в статический Datetime-фактор и затем работают на свежестных (fresh) запросах. Это не рантайм-вычисление - к моменту формирования выдачи значения уже лежат в ERF канона.
У документа не одна дата, а несколько независимо добываемых временных меток, каждая со своим производителем в робот-конвейере. Разберу по факторам.
Код: Выделить всё
ФАКТОР СЛОТ ИСТОЧНИК ДАННЫХ
FI_DATER_AGE 380 датировщик: возраст документа
FI_FIRST_VALID_TS_10DAYS 442 samovar ValidState.FirstValiditySource
FI_DATER_ADDTIME_80HOURS 1861 samovar RobotAddTime + html_dater
FI_DATER_ADDTIME_10DAYS 1862 то же, окно 10 дней
FI_ADD_TIME 41 время добавления в индекс
FI_PAGE_DATE 345 rthub DateExtractor: дата на странице
FI_IS_OBSOLETE 198 признак устаревшего документа
2. Время добавления датировщиком (samovar + html_dater). Пара FI_DATER_ADDTIME_80HOURS[1861] и FI_DATER_ADDTIME_10DAYS[1862] использует данные датировщика RobotAddTime. В samovar это структура TRobotDate с полями DateTimestamp и Score - то есть не просто метка, а метка с оценкой достоверности. Score сюда приходит от датировщика quality/html_dater: это MatrixNet примерно на 150 признаках, нарезанных по сегментам HTML, meta и URL. Иными словами, html_dater - это обучаемый предиктор даты документа: он смотрит на структурные зоны страницы (заголовки, мета-теги, токены URL, текстовые блоки) и выдаёт оценку даты вместе с уверенностью, а samovar это консервирует в TRobotDate.
3. Дата, прописанная на странице (rthub DateExtractor). FI_PAGE_DATE[345] - это дата, которую сама страница декларирует (опубликовано такого-то числа, мета og, разметка). Её извлекает rthub DateExtractor (он же RobotDater в наборе rthub-экстракторов). Это самый прямолинейный из трёх источников: парсинг даты из контента и разметки, без обучаемой модели поверх.
Стоит развести два механизма, которые легко спутать. html_dater - это MatrixNet-предиктор, который оценивает дату по косвенным признакам и даёт Score, его результат идёт в RobotAddTime/TRobotDate. DateExtractor - это извлечение явной даты с самой страницы, его результат идёт в FI_PAGE_DATE. Первый отвечает на вопрос когда документ реально появился/обновился по совокупности сигналов, второй - что страница сама о себе пишет.
Упаковка: стадия dater_remap -> FinalErf
Добытые даты не остаются в samovar в сыром виде. Они проходят стадию упаковки dater_remap, которая живёт в library и в selectionrank, и сводятся в FinalErf - финальный erf-блоб документа, который рантайм базового поиска читает уже как статику.
Код: Выделить всё
КОНВЕЙЕР робот -> фактор (датовая ветка):
rthub DateExtractor / RobotDater
дата со страницы (FI_PAGE_DATE)
|
quality/html_dater (MatrixNet ~150 фич: HTML/meta/URL)
оценка даты + Score
|
samovar:
TRobotDate{DateTimestamp, Score} (RobotAddTime)
ValidState.FirstValiditySource (FirstValidTs)
|
jupiter / library: стадия dater_remap
ремап датовых полей в Datetime-факторы
|
selectionrank: DaterRemap
|
FinalErf -> читается рантаймом как статика
Что это значит для SEO
Практический смысл прямой. Возраст документа здесь не абстракция, а набор конкретных накапливающихся при индексации величин:
- время первой валидности (FirstValidTs) - с какого момента робот считает документ годным;
- время добавления датировщиком (RobotAddTime) с оценкой достоверности Score;
- дата, заявленная на самой странице (PageDate), извлечённая DateExtractor.
Ещё одно следствие: поскольку датовые факторы статические и привязаны к канону (упаковка идёт в FinalErf того URL, который выбран носителем после канонизации gemini/mirror), накопленная свежесть живёт на каноничном документе. Смена URL без переноса канона обнуляет накопленную датовую историю так же, как обнулила бы ссылочную.Вывод для практики: дата, которую страница декларирует в разметке (DateExtractor -> FI_PAGE_DATE), и дата, которую робот выводит сам (html_dater Score -> RobotAddTime), - разные сущности. Манипуляция датой в разметке не равна изменению реального возраста: html_dater как MatrixNet оценивает дату по совокупности HTML/meta/URL-признаков и присваивает Score, а samovar фиксирует FirstValidTs независимо. Согласованность всех трёх сигналов работает лучше, чем накрутка одного PageDate. FI_IS_OBSOLETE[198] напоминает, что у документа есть и обратная метка - признак устаревшего.
Дисклеймер
Срез исходников - примерно 2022 год. Конкретные имена структур (TRobotDate, ValidState.FirstValiditySource), пороги окон (80 часов, 10 дней) и состав примерно 150 признаков html_dater могли смениться. Веса факторов в формуле обучаемы и проприетарны; любые рассуждения о силе влияния иллюстративны. Зафиксирована здесь именно архитектура моста робот -> фактор, а не точные числовые коэффициенты.