Один из самых вредных мифов в SEO звучит так: поставь на статью сегодняшнюю дату - и Google решит, что она свежая. Реальность сложнее и интереснее. Свежесть у Google это не один общий буст за новизну, а связка из трёх независимых механизмов: извлечение и проверка дат документа, планирование переобхода и выборочное применение свежести в ранжировании в зависимости от типа запроса. Ниже разбор по факторам с их ID, уровнями подтверждения и источниками.
Ядро свежести: Last Significant UpdateДисклеймер. Это реконструкция по утечке Content Warehouse API (май 2024), материалам суда DOJ против Google, патентам и Quality Rater Guidelines. Это не официальная формула ранжирования. Часть сигналов лишь документирована в утечке без подтверждения их веса, часть прямо спорна. Имена полей реальны, их фактический вклад - нет.
Главный сигнал свежести самой страницы - не дата публикации, а LSU.
Last Significant Update (LSU) - подтверждён (official-confirms-unofficial), F-FRESHNESS-001
Это дата последнего значимого обновления страницы в виде UNIX-таймстампа. Вычисляет её отдельный компонент LSU Selector, и не из одной разметки, а из множества сигналов сразу: таймстампы пассажей, byline, сам контент, аннотации. В утечке это всплыло в полях lastSignificantUpdate (PerDocData), QualityTimebasedLastSignificantUpdate.date и NlpSaftDocument.lastSignificantUpdate. После публикации утечки именно это поле запустило массовую волну refresh-инициатив у издателей.
LSU Upper Bound from Passage Timestamps - документирован, F-FRESHNESS-003
Тут самое важное для тех, кто любит играть с датами. Существует верхняя граница допустимой LSU, выведенная из временных меток пассажей контента. LSU физически не может быть выше неё. То есть если текст внутри страницы старый, выставить дату обновления вперёд не получится - потолок задают сами пассажи.
Код: Выделить всё
СИГНАЛ ЧТО ДЕЛАЕТ ID
--------------- -------------------------------------- --------------
LSU дата последнего значимого обновления FRESHNESS-001
LSU Upper Bound потолок для LSU из таймстампов пассажей FRESHNESS-003
Change Signif. значимость правок 0..1 (avg и last) FRESHNESS-021
Prominent Sect. засчитываются правки только в гл. блоке FRESHNESS-038
Значимость изменений по шкале 0 до 1, средняя и последняя (поля averageChangeSignificance и lastChangeSignificance в CrawlerChangerateUrlChangerate). Высокая значимость поднимает приоритет переобхода. Считается она по содержательным правкам в основной зоне контента, а не по ротации баннеров и не по новым комментариям.
Prominent Section Change Detection - документирован, PATENT5
Краулер выделяет важный раздел страницы по визуальным размерам при рендеринге и фиксирует как интересные только изменения внутри него. Правки в сайдбаре, футере, навигации при расчёте частоты изменений практически игнорируются. Отсюда прямой вывод: хочешь, чтобы правка засчиталась - меняй H2/H3, ключевые абзацы, таблицы с данными в основном видимом блоке.
Объявленные и синтаксические даты
Byline Date - подтверждён, F-FRESHNESS-005
Это та дата, что показывается в сниппете веб-поиска. Формируется преимущественно из синтаксической даты, но вебмастер влияет на неё через разметку (поля bylineDate, snippetBylineDate). Практика: размечайте datePublished по schema.org в ISO-формате, а для обновлённого контента добавляйте dateModified.
Syntactic Publication Date - подтверждён, F-FRESHNESS-007
Дата, явно прописанная в URL, заголовке или тексте. Базовый источник для byline и для freshness-логики. Дата в пути URL вида /2024/03/ считывается напрямую, поэтому устаревшая дата в URL вечнозелёного материала будет старить его в глазах системы.
Syntactic Date Precision Mark - документирован, F-FRESHNESS-058
Метка точности извлечённой даты: до дня, месяца, года или диапазон (precisionMark). Чем точнее дата, тем агрессивнее она используется. Формат 2024-03-15 машинно интерпретируется лучше, чем March 2024. Но точность не должна быть фальшивой - об этом ниже.
Свежие наблюдения SEO-сообщества по утечке добавляют сюда важный нюанс. Аналитики разделяют syntacticDate (где и когда формально проставлена дата) и semanticDate - попытку оценить актуальность по самому содержанию: насколько свежи приведённые данные, ссылки и факты. Граница тут: semanticDate как отдельное работающее поле - это интерпретация комьюнити, а не строго подтверждённый механизм. Относимся как к гипотезе, а не как к факту.
Краул-планирование: когда Google переобходит страницу
Crawl Period примерно равен половине Change Period - подтверждён, PATENT6 + COURT (p.93)
Период краула ставится примерно вдвое чаще оценённого периода изменений. Меняется раз в 2 дня - обходят примерно раз в день. Это патентная логика и показания суда, а не публичное расписание Google для каждого URL, так что не переносите цифру буквально.
Crawl Rate обратно пропорционален популярности - подтверждён, PATENT5 + COURT (p.137)
Чем популярнее страница (входящие ссылки, спрос, подписчики), тем чаще её краулят и быстрее индексируют обновления. Для важных, но редко обходимых страниц помогает корректный lastmod в sitemap, внутренние ссылки со свежих разделов и реальные правки.
Change-Frequency Underestimation Bias - документирован, PATENT6
Ловушка-петля: если страница меняется чаще, чем краулится, система структурно недооценивает частоту её изменений. Редкий краул ведёт к заниженной оценке, а та - к ещё более редкому краулу. Разрывают петлю свежие входящие и внутренние ссылки, обновлённый sitemap, чистые ответы сервера.
Код: Выделить всё
ПЕТЛЯ НЕДООЦЕНКИ ЧАСТОТЫ ИЗМЕНЕНИЙ
редкий краул ---> заниженная оценка частоты
^ |
| v
ещё реже краулят <--- низкий приоритет URL
ВЫХОД: свежие ссылки + sitemap lastmod + реальные правки
Это блок, который делает игру в даты бессмысленной на масштабе.
Unreliable Dates Score (per Petacat) - документирован, F-FRESHNESS-023
Итоговый счёт ненадёжности дат, считается на уровне вертикального кластера (petacat), поле unreliableDatesScore. Высокое значение снижает доверие к заявленным датам ВСЕХ страниц вертикали. То есть в нишах, где массово перебивают даты без обновления текста, страдают даже честные.
Date vs ContentAge Distribution Skew - документирован, F-FRESHNESS-056
Вспомогательный компонент того же счёта: расхождение между заявленными датами и фактическим возрастом контента (ContentAge). Большой перекос - паттерн манипуляции. Риск создаёт именно системность: не разовая правка даты, а регулярная простановка свежих дат на больших массивах старого текста.
Host Age (Fresh Spam Sandbox) - документирован, F-FRESHNESS-053
Самая ранняя дата обнаружения страниц на хосте (поле hostAge, в днях с 31.12.2005). Используется твиддлером как песочница для свежего спама: молодые домены с агрессивным ростом получают ограниченную и менее предсказуемую видимость. Это не самостоятельный буст и не приговор - это сигнал контекста и риска, который надо закладывать в ожидания по новым доменам.
Применение свежести по типу запроса (QDF и QRG)Здесь же подтверждение от самого Google вне утечки: публично заявлено, что попытка обмануть систему фейковой датой может стоить вам показа date byline в сниппете. То есть санкция за манипуляцию датами существует и на видимом уровне, а не только в скрытых сигналах.
Ключевая мысль: свежесть применяется ВЫБОРОЧНО. Это и есть знаменитый QDF - Query Deserves Freshness.
Freshness as Search-Quality Factor (QDF) - подтверждён, COURT (p.93)
Свежесть - важный фактор качества поиска, но включается по типу запроса. Для одних результатов выдача стабильна, для других (fresh-запросов) меняется быстро. По наблюдениям комьюнити, триггер QDF - одновременный всплеск: много новых публикаций по теме плюс рост числа запросов. Это сигнал, что тема разогрета, и Google поднимает свежее.
Код: Выделить всё
КЛАССИФИКАЦИЯ ЗАПРОСА ПЕРЕД ОБНОВЛЕНИЕМ СТРАНИЦЫ
ТИП ЗАПРОСА НУЖНА СВЕЖЕСТЬ? ПРИМЕР ID
---------------- ---------------- --------------------- -------------
QDF / fresh да, критично курс доллара, новости FRESHNESS-042
recurring-event да, текущий год декларация 2026 FRESHNESS-044
stale-sensitive да, демоушен прошлогодние цены FRESHNESS-047
timeless нет, нейтрально дата рождения, формула FRESHNESS-049
Для запросов, требующих свежести, страницы о прошлых событиях, старых моделях и устаревших ценах оцениваются как stale и получают низкий Needs Met вплоть до FailsM - независимо от качества текста. Отлично написанная страница о прошлогодних ценах проиграет более свежей просто потому, что запрос требует текущих данных.
Recurring-Event Queries (гейт) - документирован, QRG (p.158)
Для повторяющихся событий (Олимпиада, выборы, налоговые формы, расписания) пользователь по умолчанию хочет текущую итерацию. Страница про прошлый год - слабый кандидат. Решение: ежегодно обновлять или заводить новые URL под актуальный год и сезон, а старое архивировать с явной маркировкой периода.
Timeless Queries - нейтральный/мета, QRG (p.158)
Для стабильных фактов (историческая дата, математическая формула) свежесть нейтральна. Тратить ресурс на искусственную свежесть вечнозелёного контента смысла мало - там сильнее работают точность, полнота и авторитетность.
Новостной и realtime слой
Freshbox Article Scores + IsHotdoc Flag - документирован, F-FRESHNESS-027 и F-FRESHNESS-052
Набор ML-классификаторов (freshbox article score, live blog score, host-level article score) оценивает, насколько документ похож на свежую статью или лайв-блог (поля freshboxArticleScores, isHotdoc). Флаг hotdoc запускает приоритетный пайплайн мгновенной индексации через FreshDocs. Для новостных тем работают статейный формат, чёткая структура заголовок плюс дата плюс byline и регулярный выпуск материалов на хосте.
Realtime Boost / Seismograph Event Annotations - документирован, F-FRESHNESS-028
Seismograph детектирует всплески интереса к разворачивающимся событиям и запускает realtime-буст для свежего релевантного контента (поле qualityRealtimeBoostSeismographEventAnnotations). Быстрая публикация по горячему событию открывает окно повышенной видимости, пока тема горячая. Но скорость не отменяет фактчекинг и базовое качество.
Что это значит на практике в 2025-2026
Свежие данные сообщества подтверждают и осовременивают картину утечки. Несколько ориентиров (это эмпирика индустрии, не подтверждённые пороги Google)
Код: Выделить всё
ЭМПИРИЧЕСКИЕ ОРИЕНТИРЫ ПО RE-FRESH (мнение индустрии, не Google)
ТИП КОНТЕНТА ЦИКЛ ОБНОВЛЕНИЯ РИСК БЕЗ ОБНОВЛЕНИЯ
------------------ ----------------- ---------------------------
технологии ~ ежемесячно быстрый выход из топа
финансы ~ ежеквартально устаревшие цифры
вечнозелёный ~ раз в год медленный decay
ИсточникиГраница вывода. Доказано: LSU и его потолок по пассажам, byline и синтаксическая дата, связь краула с частотой изменений и популярностью, выборочный QDF, демоушен stale-контента для freshness-запросов. Спорно или лишь документировано: точный вес каждого сигнала, существование рабочего semanticDate, конкретные цифры циклов обновления. Нельзя обещать: что обновление даты ускорит рост, что свежесть поможет вечнозелёному интенту, что новый домен быстро наберёт видимость. Свежесть - это про реальное обновление основного контента под реальный спрос на свежесть, а не про подмену таймстампа.