Почему нейросети предпочитают свежий контент — и как это проверить

Когда речь заходит о GEO, разговор почти всегда крутится вокруг структуры контента, разметки и технической доступности сайта для краулеров. Свежесть публикации — дата, когда материал в последний раз реально обновлялся, — обсуждается реже, хотя влияет на то, процитирует ли модель именно вас, не меньше, чем удачный заголовок или FAQ-блок. Разберём, почему это работает именно так, и заодно честно покажем, что нашли, когда проверили этим свои же статьи.

Почему свежесть вообще имеет значение для генеративного поиска

Генеративные поисковые системы — будь то AI Overview, Perplexity или встроенный поиск ChatGPT — обычно устроены не как «спроси модель и жди ответа из памяти», а как связка поиска и генерации: система сначала находит несколько релевантных документов, а затем формулирует ответ на их основе. На этапе отбора документов дата обновления — такой же сигнал, как релевантность текста запросу. Для тем, где факты меняются (цены, законодательство, версии продуктов, рыночная статистика), устаревший, но формально релевантный документ рискует быть отклонён в пользу менее полного, но более свежего источника.

Это не значит, что старый контент бесполезен. Значит это другое: если факты в статье изменились, а дата в разметке — нет, вы посылаете противоречивый сигнал. Текст может быть отличным, но система не может отличить «актуально и просто давно не менялось» от «устарело и забыто».

datePublished и dateModified — это два разных сигнала, а не один

В структурированных данных статьи (Schema.org Article/BlogPosting) для этого предусмотрены два отдельных поля:

• datePublished — момент, когда материал впервые вышел. Не должен меняться никогда, даже если статью правят.
• dateModified — момент последнего реального изменения содержания. Должен обновляться каждый раз, когда в тексте меняются факты, а не только орфография.

Разница важна: если обе даты всегда совпадают на каждой статье сайта, это почти наверняка означает, что dateModified не отслеживает реальные правки, а просто дублирует дату публикации — то есть поле формально есть, а сигнала в нём нет.

Ошибка, которую мы нашли у самих себя

Мы не хотим писать очередной гайд «как надо», не проверив себя тем же инструментом, которым проверяем чужие сайты. Прогнали через наш собственный инструмент проверки свежести контента несколько статей этого блога — и у всех проверенных материалов dateModified оказался в точности равен datePublished, при том что часть из них старше месяца. Формально в разметке дата обновления есть. По факту она никогда не менялась ни разу, даже при добавлении новых внутренних ссылок.

Это ровно тот случай, который мы описали выше: поле не врёт напрямую, но и не несёт полезного сигнала. Причина обычная — шаблон блога изначально не был написан так, чтобы отличать «дата публикации» от «дата последнего изменения» на уровне вывода в разметку. Мы фиксируем это как открытую задачу и планируем поправить в шаблоне, а не тихо забыть — статья, которая рекомендует проверять свежесть, обязана применять это правило и к себе.

Как проверить свежесть у себя

Не обязательно верить нам на слово — можно проверить конкретную страницу за несколько секунд: инструмент ищет datePublished и dateModified в meta-тегах и JSON-LD, сравнивает их между собой и показывает возраст публикации. Если инструмент говорит «даты совпадают» на статье, которую вы точно правили за последний месяц, — разметка не отражает реальность, и это стоит починить раньше, чем переписывать сам текст.

Как именно инструмент оценивает возраст и статус даты

Чтобы не быть голословными, опишем точную логику нашего инструмента проверки свежести — без упрощений и без «магии». Она полностью детерминирована и построена на трёх независимых проверках.

1. Поиск дат. Инструмент ищет дату публикации в meta-теге article:published_time или в поле datePublished внутри JSON-LD (включая структуры внутри @graph). Дата обновления ищется так же — по article:modified_time и dateModified. Если ни один из источников не даёт валидную дату публикации, это статус fail: без датировки модель не может оценить, насколько материал актуален. Отсутствие даты обновления — это уже не fail, а warn, потому что формально страница может быть неизменной с момента публикации, и это не всегда плохо.

2. Возраст публикации — три порога. Если дата публикации найдена, инструмент считает разницу в днях между ней и сегодняшним днём и присваивает один из трёх статусов: до 365 дней — pass, от 365 до 730 дней — warn с пометкой «старше года — стоит проверить актуальность фактов», больше 730 дней — fail с пометкой «старше двух лет без признаков обновления — для многих тем модели предпочтут более свежий источник». Это простое пороговое правило, а не оценка того, устарели ли факты на самом деле — инструмент не читает и не понимает содержание статьи, он оценивает только дату.

3. Признак реального обновления. Если найдены обе даты, инструмент сравнивает их численно: если dateModified строго позже datePublished — pass («дата изменилась после публикации»). Если даты совпадают — warn с честной формулировкой «dateModified равен datePublished — вероятно, проставлен автоматически при первой публикации, а не при реальном обновлении». Именно эта проверка и поймала ошибку в разметке наших собственных статей, о которой мы написали выше.

Важная оговорка: инструмент не умеет проверять, действительно ли изменился текст — он работает только с датами в разметке. Если вы вручную поменяете dateModified на сегодняшнюю дату, ничего не редактируя в тексте, инструмент покажет pass, хотя по сути это манипуляция сигналом, а не полезное обновление. Технической защиты от этого нет — честность разметки остаётся на стороне того, кто её выставляет.

Что делать, если контент реально устарел

• Проверяйте факты, а не только формулировки. Цифры, цены, версии продуктов, ссылки на актуальные источники — то, что физически может устареть.
• Обновляйте dateModified только при реальном пересмотре содержания. Не превращайте поле в способ искусственно «поднять» статью — противоречие между заявленной свежестью и содержанием подрывает доверие сильнее, чем честно старая дата.
• Показывайте факт обновления не только в разметке, но и на странице — строка «обновлено: дата» рядом с заголовком работает и для читателя, и как дополнительный сигнал для модели.
• Приоритизируйте темы с быстро меняющимися фактами — статьи о ценах, регуляторике или конкретных версиях сервисов стоит пересматривать чаще, чем объясняющие общие принципы.

Частые вопросы

Нужно ли обновлять дату, если поправили только опечатку?

Нет — dateModified должен отражать смысловые изменения контента, а не косметическую правку. Обновление даты без реального изменения фактов — это манипуляция сигналом, а не полезная информация для модели.

Как часто нужно пересматривать старые статьи?

Универсального срока нет — ориентируйтесь на то, как быстро меняются факты в теме. Для changing-facts тематик разумно закладывать пересмотр раз в квартал-полгода, для объясняющих принципы материалов — реже.

Влияет ли устаревшая дата на обычные позиции в поиске, а не только на ИИ-ответы?

Да, дата публикации часто отображается прямо в сниппете поисковой выдачи и влияет на решение пользователя кликнуть — эффект не специфичен только для генеративного поиска.