Как правильно настроить lastmod и If-Modified-Since для карты сайта

В карте сайта настраивают элемент lastmod. Заголовок Last-Modified сервер отдаёт вместе со страницей, а If-Modified-Since присылает клиент при повторном запросе. Это три части двух разных механизмов. Корректная реализация сообщает поисковику о содержательных изменениях и позволяет не передавать неизменившийся ответ повторно.

Три похожих названия

lastmod — необязательный XML-элемент внутри записи url в sitemap.xml. Он содержит дату последнего существенного изменения страницы. Last-Modified — HTTP response header. If-Modified-Since — условный request header, с которым браузер или робот спрашивает, изменился ли ресурс после известной даты.

Поисковик может использовать sitemap lastmod как подсказку при планировании обхода, но не обязан доверять ему. HTTP-валидатор уменьшает передачу данных при повторном запросе. Ни один механизм не гарантирует индексирование или позиции.

Какие изменения считать существенными

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

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

• Новый или удалённый смысловой раздел.
• Изменение цены, наличия или условий.
• Обновление фактов и редакционной даты.
• Замена основного медиа.
• Не считать: счётчик, случайная реклама, время сборки, cookie-баннер.

Формат lastmod в sitemap.xml

Используйте W3C Datetime: YYYY-MM-DD или полную дату-время ISO 8601 с часовым поясом. Единая дата подходит, если точное время не важно. Не передавайте локальное время без зоны в полном timestamp. Все карты должны быть в UTF-8 и соблюдать лимиты протокола.

Google игнорирует priority и changefreq, но использует точный lastmod, если сайт последовательно сообщает реальные изменения. В качестве сигнала доверия он сравнивает заявленные даты с наблюдаемыми изменениями. Автоматическое значение today для каждого URL при каждом запуске обесценивает поле.

<url>
  <loc>https://example.ru/articles/http-caching</loc>
  <lastmod>2026-07-21T10:30:00+07:00</lastmod>
</url>

Как получить правильную дату

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

Не берите mtime сгенерированного HTML, если деплой пересоздаёт все файлы. В Git-проекте дата последнего коммита файла тоже не всегда равна изменению содержания: общий форматтер может коснуться всего. Лучше формировать дату в publishing-процессе и проверять её автоматическим тестом.

Last-Modified и If-Modified-Since

При первом GET сервер отдаёт 200, тело и Last-Modified. Клиент сохраняет значение и позже отправляет If-Modified-Since. Если выбранное представление не менялось, сервер отвечает 304 без тела; если изменилось — 200, новую версию и новый Last-Modified. Сравнение имеет секундную точность и уступает ETag там, где важна строгая идентичность байтов.

Динамическое приложение должно вычислить модификацию до тяжёлого рендеринга, иначе экономится только трафик. Учитывайте варианты по языку, авторизации и сжатию. Для персонализированной страницы публичный shared cache требует отдельной политики Cache-Control и Vary; не добавляйте Last-Modified без понимания кеширования приватных данных.

GET /article HTTP/1.1
If-Modified-Since: Tue, 21 Jul 2026 03:30:00 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Tue, 21 Jul 2026 03:30:00 GMT
Cache-Control: public, max-age=0, must-revalidate

Согласование sitemap и HTTP

Даты не обязаны совпадать побайтно, но не должны противоречить смыслу. sitemap lastmod относится к содержанию URL, Last-Modified — к передаваемому представлению. Если каждый HTTP-ответ заявляет текущее время, условный запрос никогда не получит 304, а робот не сможет использовать валидатор.

При смене URL или canonical обновляйте карту как набор: добавьте новый канонический адрес, удалите старый из sitemap и настройте редирект при переезде. lastmod старого редиректного URL не нужен. Для удаления отдавайте 404 или 410 и исключайте адрес из карты.

Как проверить настройку

Проверьте sitemap через Sitemap Intelligence: сервис помогает увидеть даты, структуру и подозрительные массовые обновления. Затем выберите URL разных шаблонов и сравните lastmod с реальным изменением в CMS. С помощью curl запросите headers, повторите GET с If-Modified-Since и проверьте 304.

После новой публикации тот же условный запрос со старой датой должен вернуть 200 и обновлённый Last-Modified. Убедитесь, что CDN и origin согласованы, а 304 не содержит старый статус после изменения. Наблюдайте серверные логи и отчёты панелей, но не ожидайте немедленного crawl каждой даты.

1. Проверить источник content_updated_at.
2. Проанализировать lastmod по всем картам.
3. Найти массовые одинаковые даты.
4. Сверить выборку с CMS.
5. Получить Last-Modified.
6. Повторить If-Modified-Since.
7. Изменить контрольную страницу.
8. Убедиться в 200 и новой дате.

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

Что читать дальше

• Sitemap Intelligence
• Генераторы карт сайта
• Переобход страниц
• Google Search Console