Sitemap lastmod: когда действительно обновлять дату страницы

Почему дата сборки портит lastmod

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

Допустим, в релизе изменили описание услуги /services/b и общий CSS. Дату /services/b разумно обновить, а даты 299 неизменных материалов оставить прежними. В системе публикации отделите updated_at, который переписывается любым техническим сохранением, от даты содержательной редакции. Перед релизом сравните две версии sitemap: массовая смена дат без изменения ответов страниц указывает на ошибку генератора.

Сравните редакцию страницы и запись sitemap

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

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

Определите содержательное изменение

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

Храните дату на уровне URL

Храните время публикации и содержательного изменения отдельно. Генератор sitemap должен выводить дату реального изменения конкретного URL, а не глобальный timestamp релиза.

Глобальное изменение шапки сайта не обязательно означает содержательное обновление каждого URL. Не переписывайте даты всех статей из-за изменения дизайна.

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

Не обновляйте все статьи из-за CSS

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

Сравните два выпуска карты сайта

После сборки сравните sitemap до и после: неизменные URL сохраняют даты, обновленные меняют их. Проверьте формат даты, абсолютные адреса и отсутствие редиректных URL.

Сравните карты сайта до и после выпуска строка к строке. У неизменных материалов lastmod должен остаться прежним; у реально переработанных - соответствовать редакционному событию. Затем проверьте, что адрес в карте возвращает действующий ответ и канонизирован сам на себя.

Проверка результата

• Намерение страницы определено
• Сохранена выборка URL до исправления
• HTTP-ответ и содержимое сверены
• Внутренние ссылки проверены
• Исключения учтены
• Проверка после релиза записана

Скачать таблицу примера

Вопросы по теме

Читайте также