Свежесть страницы-донора: что проверять в дате публикации и истории обновлений

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

Поэтому свежесть полезно оценивать не как возраст URL, а как состояние конкретного документа: когда он появился → что в нём действительно менялось → соответствует ли текущий текст сегодняшней теме → поддерживаются ли источники и внешние переходы. Дата здесь только один из следов.

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

Свежая дата не делает страницу сильным донором автоматически

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

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

Нуждается ли сама тема в регулярном обновлении?
Есть ли доказательства, что страница действительно поддерживается, а не просто получила новую дату?

Google прямо описывает системы ранжирования по актуальности как зависимые от запроса: более свежие результаты особенно важны там, где пользователь ожидает последние сведения. Это не универсальное правило «новое всегда лучше старого».

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

Сначала разделите дату публикации и дату изменения

На одной странице могут существовать как минимум две разные даты:

дата публикации — когда материал появился впервые;
дата изменения — когда его содержимое обновили позднее.

В разметке Article этим ролям соответствуют datePublished и dateModified. Google также рекомендует показывать дату пользователю заметно и согласовывать видимую дату со структурированными данными.

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

Например:

Опубликовано: 14.03.2023
Обновлено: 22.08.2026

Такая пара дат создаёт проверяемый вопрос: между мартом 2023 и августом 2026 текст получил содержательные изменения или только новую метку времени?

У свежести страницы есть несколько независимых следов

Один timestamp легко прочитать неправильно. Лучше сравнивать несколько источников даты и состояния страницы.

След	Что показывает	Чего не доказывает сам по себе
Видимая дата	Как редакция сообщает читателю время публикации или обновления	Что содержимое действительно изменилось существенно
`datePublished` / `dateModified`	Какие даты страница передаёт в структурированных данных	Что разметка соответствует реальной истории текста
`<lastmod>` в Sitemap	Как сайт сообщает время последнего значительного изменения URL	Что каждое обновление CMS было содержательным
Архивные версии страницы	Как выглядел документ в доступных прошлых снимках	Полную непрерывную историю: архив может иметь пропуски
Сам контент	Актуальность цифр, ссылок, версий, примеров и выводов	Точную дату каждого изменения без дополнительной истории

Google указывает, что при определении даты страницы не полагается на один фактор. Для аудита донора логика та же: чем сильнее вывод о свежести, тем полезнее подтверждать его несколькими следами.

lastmod полезен только тогда, когда ему можно доверять

В XML Sitemap страница может иметь поле <lastmod>:

<url>
  <loc>https://example.com/article/</loc>
  <lastmod>2026-08-22</lastmod>
</url>

Google использует lastmod, если значение стабильно и проверяемо отражает последнее значительное изменение страницы. В документации к значимым изменениям относятся, например, обновление основного контента, структурированных данных или ссылок. Простая смена даты копирайта значительным обновлением не считается.

Это делает lastmod полезным диагностическим сигналом, но не сертификатом качества. Некоторые CMS меняют его после технического сохранения страницы, перестройки шаблона или другого действия, которое почти не затронуло материал.

Поэтому схема проверки должна идти в обе стороны:

lastmod изменился
→ что изменилось в документе?

документ заметно изменился
→ отражено ли это в видимой дате / dateModified / lastmod?

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

Что считать содержательным обновлением

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

Примеры реальных изменений:

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

Косметические признаки выглядят иначе:

изменился только год в заголовке;
дата «Обновлено» стала новой, а основной текст остался прежним;
переставлены абзацы без изменения смысла;
добавлена одна общая фраза ради новой даты;
обновлён шаблон сайта, но не содержимое статьи.

Google в рекомендациях по people-first content отдельно предлагает насторожиться, если дата страницы меняется только для создания ощущения свежести без существенного изменения материала.

Проверяйте свежесть относительно темы, а не календаря

Один из самых полезных шагов — до просмотра даты определить скорость старения самой информации.

Тип материала	Что стареет быстрее всего	Что проверить
Тарифы, цены, условия сервиса	Цифры и правила	Совпадают ли значения с текущей версией источника
Обзор инструмента	Интерфейс, функции, тарифные планы, версии	Не описывает ли статья уже снятые функции
Закон, стандарт, регламент	Редакция документа и дата действия	Есть ли ссылка на актуальную версию
Статистика и рынок	Период данных	Не выдаётся ли старый срез за текущее состояние
Базовый технический принцип	Терминология и конкретные реализации	Остаётся ли основной механизм верным
Исторический материал	Не обязательно должен «освежаться»	Ясно ли обозначен исторический контекст

Такой подход защищает от механического правила «старше N месяцев = плохая страница». Для одной темы полгода действительно много, для другой пять лет могут почти не менять основной ответ.

Свежесть — один слой page-level аудита

Даже идеально поддерживаемый материал может не подходить для конкретного размещения. Нужно отдельно оценить самостоятельную ценность страницы, её задачу, качество ответа и наличие естественного места для перехода. Эти проверки собраны в материале о page-level аудите страницы-донора.

Свежесть добавляет к этому аудиту временную ось. Мы уже знаем, что страница существует и отвечает на понятную задачу. Теперь нужно понять, поддерживается ли это состояние во времени.

Условно:

страница хороша сейчас
+
история показывает содержательные обновления
+
актуальные источники и переходы
=
есть признаки поддерживаемого документа

Но это всё ещё не математический score и не гарантия силы будущей ссылки.

Архив страницы помогает отличить обновление от смены даты

Если текущая версия утверждает, что материал обновлялся, полезно сравнить несколько снимков одного и того же URL в Wayback Machine или другом доступном веб-архиве.

Смотреть лучше не на пиксельную разницу, а на смысловые узлы:

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

Важно не переоценивать отсутствие снимка. Internet Archive прямо предупреждает, что страница может не попасть в архив из-за ограничений обхода, robots.txt, JavaScript, отсутствия обнаруживаемых ссылок и других причин. Поэтому «нет снимка» не равно «страницы тогда не существовало».

И здесь проходит граница с аудитом истории домена: в T9 архив нужен для сравнения версий конкретного URL, а не для восстановления всей биографии площадки.

Источники страницы стареют отдельно от её текста

Статья может выглядеть аккуратно и иметь свежий dateModified, но ссылаться на устаревшие документы, удалённые исследования или версии продукта, которые уже не используются.

Поэтому у старой страницы полезно пройти исходящие источники:

открывается ли целевой URL;
не ведёт ли он через длинную цепочку перенаправлений;
соответствует ли источник утверждению, которое он поддерживает;
есть ли более новая официальная версия документа;
не изменилось ли содержание страницы назначения;
не остался ли в тексте вывод, основанный на старой версии источника.

Если задача шире и нужно понять не один материал, а привычки сайта по внешним ссылкам в целом, полезно перейти к разбору редакционного профиля исходящих ссылок донора. Там объектом становится уже выборка публикаций, а не история одного URL.

Дата обновления и свежесть самой ссылки — тоже не одно и то же

Иногда внешний переход добавляют в старую статью спустя годы после публикации. Это не обязательно плохо: редактор мог действительно пересобрать материал и добавить новый релевантный источник. Но новая ссылка сама по себе не доказывает, что обновлена вся страница.

В таком случае полезно проверить:

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

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

Несогласованные даты — повод разбираться, а не автоматически отбраковывать страницу

У одного URL можно встретить несколько значений:

на странице:        Обновлено 18.08.2026
dateModified:       2026-08-18
sitemap lastmod:    2026-09-02
архивный снимок:    заметные изменения 18.08.2026

Разница между dateModified и lastmod может возникнуть из-за технического изменения после редакционного обновления. В другом случае sitemap может обновляться при любом сохранении записи. Без знания CMS нельзя из одной разницы вывести причину.

Полезнее фиксировать статус:

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

Так мы не превращаем технический timestamp в обвинение и одновременно не принимаем его на веру.

Не путайте поддерживаемую старую страницу с автоматически «освежённой»

У поддерживаемого документа обычно есть связная картина. Текущие данные не конфликтуют со ссылками, версии источников актуальны, изменения можно объяснить задачей материала, а дата обновления соответствует хотя бы части видимых изменений.

Автоматическая свежесть чаще выглядит иначе: новый год или дата появляются массово, но старые цифры, скриншоты, названия функций и ссылки остаются прежними.

Признак	Поддерживаемая страница	Косметическое обновление
Дата	Связана с понятным изменением	Изменилась сама по себе
Факты	Проверены относительно текущих источников	Сохраняют старые значения
Ссылки	Работают и соответствуют тезисам	Есть старые или битые переходы
Версии и интерфейсы	Соответствуют текущему состоянию темы	Описывают уже устаревшую реализацию
История	Показывает осмысленное развитие	Видимых изменений почти нет

Практический порядок проверки страницы-донора

Для рабочего аудита не нужен отдельный «freshness score». Достаточно пройти последовательность и сохранить наблюдения.

Определить тип темы. Насколько быстро здесь устаревают факты?
Зафиксировать видимые даты. Есть публикация, обновление или только одна дата без подписи?
Проверить структурированные данные. Что указано в datePublished и dateModified?
Посмотреть sitemap. Есть ли lastmod и согласуется ли он с другими следами?
Проверить содержание. Актуальны ли цифры, версии, условия, скриншоты и выводы?
Открыть источники и внешние ссылки. Работают ли они и ведут ли на актуальные документы?
Сравнить доступные архивные снимки. Что реально менялось в тексте?
Отделить страницу от домена. Не переносить вывод о freshness одного URL на весь сайт и наоборот.
Зафиксировать неопределённость. Если история неполна, так и записать вместо придуманной оценки.

После этого свежесть становится не декоративной датой, а проверяемой характеристикой сопровождения конкретной страницы.

Что записать в карточку донора

Чтобы потом не восстанавливать логику решения по памяти, удобно хранить минимум полей:

Поле	Пример значения
URL	Фактический адрес страницы
Published	Дата первой публикации, если доступна
Modified	Дата последнего заявленного обновления
Sitemap lastmod	Дата из sitemap или «нет данных»
Тип темы	Быстро устаревающая / умеренно / evergreen
Подтверждённые изменения	Что именно обновлялось
Источники	Актуальны / частично устарели / не проверены
Архив	Есть сравнимые снимки / данных недостаточно
Вывод	Поддерживается / есть вопросы / косметическая свежесть / данных мало

Такой формат полезнее отметки «свежая / старая», потому что сохраняет причины решения.

Красные флаги, которые требуют дополнительной проверки

дата обновления очень новая, а в тексте остаются явно старые версии и цифры;
dateModified, видимая дата и lastmod систематически расходятся без понятной причины;
год в Title/H1 изменён, а основной материал не изменился;
ссылки ведут на удалённые или давно перенесённые документы;
последний блок с внешней ссылкой появился недавно, но остальная статья не поддерживалась;
архив показывает резкую смену задачи самого URL;
страница называет старые данные текущими без указания периода;
редакция не показывает ни дату публикации, ни историю изменений там, где время критично для понимания.

Ни один пункт не является самостоятельным доказательством «плохого донора». Это сигналы, после которых требуется более глубокая page-level проверка.

Итог

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

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

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