Дата обновления веб-статьи: когда менять её и как показать правки

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

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

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

Google рекомендует передавать datePublished и, когда это применимо, dateModified в структурированных данных статьи и отмечает, что алгоритмы могут использовать разные сигналы для определения даты страницы. Это рекомендация по описанию материала, а не обещание особого сниппета или роста позиций. Дата на странице должна оставаться видимой и совпадать со смыслом разметки. См. руководство Google по датам публикации и справку по Article.

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

Обычно дату обновления стоит менять, если:

Опечатка, исправление пунктуации, замена сломанной внутренней ссылки или небольшая правка стиля сами по себе не означают, что статья заново проверена. Такие изменения можно записывать во внутреннем журнале редакции, если история изменений нужна команде, но не обязательно выносить наверх страницы как обновление. Важна не величина diff в системе управления контентом, а изменение полезности и точности для человека.

Для спорных случаев задайте себе три вопроса: изменится ли действие, которое читатель выберет после правки; стала ли статья точнее в ответе на главный вопрос; пришлось ли повторно проверить существенные утверждения? Если на все вопросы ответ «нет», новое публичное время обычно создаст более сильное обещание, чем выполненная работа.

Если материал действительно обновлялся, разместите под заголовком дату первой публикации и дату последней существенной проверки. Формулировки должны быть простыми: «Опубликовано 12 мая 2024 года» и «Обновлено 8 сентября 2026 года». Если автору важна краткость, можно оставить одну строку: «Опубликовано 12 мая 2024 года · обновлено 8 сентября 2026 года». Не называйте редакционную проверку «обновлением», если команда только переместила блоки или поправила пару запятых.

HTML-элемент <time> связывает читаемое человеком представление с машинно-читаемым значением в datetime:

<p class="article-dates">
  <span>Опубликовано
    <time datetime="2024-05-12">12 мая 2024 года</time>
  </span>
  <span>Обновлено
    <time datetime="2026-09-08">8 сентября 2026 года</time>
  </span>
</p>

Человек видит привычную русскую запись даты, а браузер и инструменты могут разобрать стандартизированное значение. Если публикуется точное время, включите его в значение datetime в подходящем формате и укажите часовой пояс там, где это необходимо. В большинстве редакционных статей достаточно календарной даты. MDN описывает допустимые варианты значения и назначение элемента в справке `<time>`.

Семантика не заменяет ясный текст. Не выводите только 2026-09-08T14:30:00+05:00: это формат для машин, не удобная подпись для читателя. И наоборот, не кладите значение даты в декоративную картинку, которую нельзя выделить или прочитать вспомогательным технологиям.

В разметке типа Article или BlogPosting указывают datePublished для первой публикации и dateModified для последнего существенного изменения. Оба значения передают в формате ISO 8601; для даты и времени указывают часовой пояс. Например:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Как подготовить веб-статью к публикации",
  "datePublished": "2024-05-12T09:00:00+05:00",
  "dateModified": "2026-09-08T14:30:00+05:00"
}

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

Установите для каждого поля один источник истины в CMS: дата публикации хранится отдельно и не перезаписывается при редактировании, а дата изменения меняется только по редакционному правилу. Рендер страницы, Open Graph или другие метаданные и JSON-LD должны получать значения из этих полей, а не вычислять даты самостоятельно. Иначе пользователь может увидеть «обновлено 8 сентября», а в разметке поисковый робот — дату вчерашней технической сборки.

Если сайт не меняет материал после публикации, не нужно выводить искусственную пару одинаковых дат. Можно показывать только публикацию. Заполнять dateModified имеет смысл, когда дата действительно отражает изменение контента, а не любое автоматическое сохранение записи в базе.

Короткая заметка помогает отличить содержательное обновление от косметического. Одной строки достаточно: «Обновлено 8 сентября 2026 года: перепроверили порядок настройки и добавили шаг для новой версии интерфейса». Такая формулировка конкретнее, чем «актуализировано» или «материал обновлён». Она не должна перечислять каждую опечатку; цель — обозначить характер работы.

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

Не обещайте «проверено экспертами», «актуально на сегодня» или «обновляется регулярно», если нет процесса, который это подтверждает. Лучше описать конкретную область проверки: «повторно проверили шаги для версии 4.2» или «пересмотрели дату и условия лицензии». Чем точнее формулировка, тем понятнее пределы актуальности.

Чтобы дата не зависела от случайного клика в CMS, заведите простой процесс:

Для потока контента назначьте ответственного за актуальность или задайте срок следующей проверки для материалов, которые зависят от быстро меняющихся условий. Это не означает, что любую статью нужно освежать по календарю: срок — повод проверить, нужна ли правка, а не команда автоматически менять дату. Руководство Google также предостерегает от искусственного обновления без существенной причины.

**Перезаписывать дату публикации.** Так теряется возраст материала и становится непонятно, впервые ли статья появилась сегодня. Сохраняйте первую дату, а позднюю работу обозначайте отдельно.

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

**Показывать будущую дату или разные значения.** Часовой пояс, планировщик публикаций и серверное время иногда расходятся. Храните временные значения в единой системе и показывайте пользователю календарную дату в принятой локали.

**Добавлять разметку, которой нет на странице.** Машинные данные должны описывать видимое содержание. Если JSON-LD заявляет дату обновления, но страница не объясняет, что обновилось, доверие к странице ниже.

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

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

Нет. datePublished описывает первую публикацию и остаётся прежним. Для более позднего существенного пересмотра используют dateModified, а на странице показывают две даты или ясную подпись с датой последней проверки.

Для понимания читателем даты — нет: разметка не заменяет видимую подпись. Google рекомендует согласовывать структурированные данные с информацией на странице; поисковая система при этом не гарантирует показ даты в сниппете.

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

Да. Например: «Опубликовано 12 мая 2024 года · обновлено 8 сентября 2026 года». Подписи должны ясно различать первую публикацию и последнюю содержательную правку, а значения в HTML и разметке — совпадать.

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

Коротко — полезно, если читатель может по этой информации оценить применимость статьи. Назовите изменённый раздел или проверенные условия. Полный перечень внутренних редакционных действий нужен только тогда, когда он помогает понять историю материала.

Разделяйте дату первой публикации и дату последней содержательной редакции, а новую отметку связывайте с проверяемой работой над материалом. Покажите её понятным текстом, используйте <time> для машинно-читаемого значения и синхронизируйте CMS с разметкой. Такой порядок сохраняет историю статьи и не обещает читателю того, чего редакция не проверяла. Если вы готовите собственный шрифт для авторского сайта или блога, его можно создать и проверить на Fontgenerator.ru.