Регламент обновления evergreen-статей: факты, версии, даты и Schema

Редакция mevrica

SEO5 мин чтения

Обновлено 1 августа 2026 г.

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

Единица контроля

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

Реестр утверждений

Одна статья содержит факты с разной скоростью старения. Формула расчёта может быть стабильной годами, интерфейс кабинета — измениться завтра, а юридическое требование — вступить в силу в конкретную дату. Поэтому page_updated_at недостаточно: нужен claim ledger.

{
  "claim_id": "claim-status-window-01",
  "page_id": "article-123",
  "statement": "Статус pending созревает по условиям конкретного оффера",
  "source_url": "https://primary-source.example/terms",
  "source_version": "effective-2026-08-01",
  "scope": {"geo": "documented-geo", "channel": "affiliate"},
  "verified_at": "2026-08-01T00:00:00Z",
  "review_after": "2026-09-01T00:00:00Z",
  "owner": "editorial-analytics",
  "status": "verified"
}

Адрес example в шаблоне не публикуется как источник: при рабочем использовании его заменяют реальным первичным документом. source_version может быть номером редакции, датой действия или hash сохранённого снимка.

Триггеры вместо тотального ежемесячного переписывания

• Изменился первичный документ или его effective date
• Платформа объявила миграцию API или интерфейса
• Появились устойчивые запросы, на которые страница не отвечает
• Сломалась внутренняя или внешняя ссылка
• Фактический пример больше не воспроизводится
• Две страницы начали конкурировать за один интент
• Коммерческое условие расходится с текущим landing
• Изменился статус индексации, canonical или Schema

Календарный review остаётся страховкой для фактов без машинного источника. Частота задаётся риском: юридические и финансовые утверждения проверяются чаще общих определений, а не наоборот.

Очередь обновлений по риску

Приоритет полезно считать как impact × probability × exposure × age_of_evidence. Impact оценивает ущерб от ошибки, probability — вероятность изменения источника, exposure — просмотры и роль страницы в маршруте, age_of_evidence — время с последней проверки конкретного факта. Это внутренняя очередь, не поисковый ranking score.

SELECT c.claim_id,
       c.page_id,
       c.review_after,
       c.impact * c.change_probability * p.exposure AS priority
FROM content_claims AS c
JOIN content_pages AS p USING (page_id)
WHERE c.status = 'verified'
  AND c.review_after <= now()
ORDER BY priority DESC, c.review_after ASC;

Четыре класса изменений

Фактический patch

Меняется одно утверждение и связанное пояснение. Проверяются все места, где используется claim_id: основной текст, FAQ, description, Schema и связанные карточки. Замена только абзаца может оставить старый факт в сниппете.

Структурная переработка

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

Консолидация

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

Вывод из эксплуатации

Материал потерял назначение и не имеет эквивалентной замены. Коммерческие CTA и вводящие в заблуждение факты снимаются сразу. HTTP-решение выбирается по наличию реальной альтернативы, а не по желанию сохранить любой URL.

Diff, который должен увидеть редактор

• Изменённые утверждения и их claim_id
• Старая и новая версия источника
• Поля Schema и метаданные, зависящие от факта
• FAQ и внутренние ссылки с тем же обещанием
• Видимая дата и dateModified
• Причина: correction, source_change, expansion или consolidation
• Имя проверившего и дата следующего review

{
  "change_id": "chg-20260801-42",
  "page_id": "article-123",
  "change_type": "source_change",
  "claims": ["claim-status-window-01"],
  "source_before": "effective-2026-07-01",
  "source_after": "effective-2026-08-01",
  "content_hash_before": "sha256:...",
  "content_hash_after": "sha256:...",
  "reviewed_by": ["editor", "subject_owner"],
  "published_at": "2026-08-01T10:30:00Z"
}

Правила дат без фиктивной свежести

datePublished — момент первой публикации основного материала. dateModified — момент последнего содержательного изменения. Видимая дата обновления и JSON-LD должны совпадать по смыслу. Google отдельно указывает, что даты должны относиться к публикации или обновлению страницы, а не к описываемому событию.

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

Schema и метаданные

После изменения проверьте headline, description, author, publisher, mainEntityOfPage, url, datePublished и dateModified. Image добавляется только при реальном изображении. FAQ Schema не должна сохранять ответы, которые исчезли из видимой статьи. Canonical указывает на текущий основной URL после консолидации.

Тесты перед публикацией

1. Каждый изменённый факт имеет доступный первичный источник.
2. Область применимости не расширена за пределы источника.
3. Пример пересчитан, а не только переписан словами.
4. Старое утверждение не осталось в FAQ, title или description.
5. Внутренние ссылки ведут на живые canonical URL.
6. datePublished сохранена; dateModified и видимая дата правдивы.
7. JSON-LD разбирается и совпадает со страницей.
8. Sitemap содержит URL с фактическим lastmod.
9. Публичная страница отвечает 200 и не получила noindex.

Мониторинг после релиза

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

Не обновляйте дату ради вида

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

Источники и границы применимости

Google Search Central: publication dates · Google Search Central: Article structured data · Google Search Central: people-first content

Вывод

Evergreen-процесс держится на реестре утверждений, источниках и контролируемом diff. Триггеры находят изменение до того, как устареет вся статья; классы работ определяют судьбу URL; честные даты и Schema фиксируют результат. Такой регламент обновляет знание, а не косметическую отметку года.