Lastmod Sitemap: как настроить карту сайта и проверить её обработку

В XML Sitemap тег <lastmod> нужен не для того, чтобы показать поисковику «свежесть сайта вообще». Он относится к конкретному URL и должен сообщать дату последнего существенного изменения этой страницы. Если статья была переработана 12 октября, логично передать эту дату. Если страница не менялась полгода, ежедневная подстановка сегодняшнего числа делает сигнал недостоверным.

Для Google точность здесь принципиальна: поисковик прямо указывает, что использует <lastmod>, когда значения последовательно и проверяемо соответствуют реальным изменениям страниц. Обновление основного текста, структурированных данных или существенных ссылок может считаться значимым; автоматическая смена даты в футере — нет.

Сам Sitemap при этом остаётся подсказкой поисковому роботу. Наличие URL в файле, корректный <lastmod> или успешный статус обработки не означают, что страница обязательно будет просканирована, включена в индекс или получит более высокую позицию.

Что именно означает <lastmod> и почему здесь часто ошибаются

У <lastmod> есть два похожих, но разных применения.

В обычном XML Sitemap он находится внутри элемента <url> и описывает изменение страницы:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <url>
        <loc>https://example.com/articles/example-page/</loc>
        <lastmod>2026-10-12T18:40:00+03:00</lastmod>
    </url>
</urlset>

Дата может содержать только день:

<lastmod>2026-10-12</lastmod>

или дату, время и часовой пояс. Оба варианта укладываются в формат W3C Datetime. Важно другое: это дата изменения документа по <loc>, а не дата создания XML Sitemap.

В индексе Sitemap тот же тег относится уже не к странице, а к вложенному файлу Sitemap:

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <sitemap>
        <loc>https://example.com/post-sitemap1.xml</loc>
        <lastmod>2026-10-12</lastmod>
    </sitemap>
</sitemapindex>

Здесь значение показывает изменение самого файла post-sitemap1.xml. Google указывает, что такая информация может помогать планировать загрузку вложенных карт. Яндекс также рекомендует отмечать через <lastmod> часто обновляющиеся Sitemap внутри файла индекса.

Когда поисковику можно доверять дату изменения

Самая опасная реализация выглядит правдоподобно: генератор Sitemap запускается каждую ночь и присваивает всем URL текущую дату.

Например, страница реально редактировалась 2 марта:

<loc>https://example.com/service/</loc>
<lastmod>2026-10-14</lastmod>

Если контент 14 октября не менялся, такая запись неверна. Sitemap сообщает поисковику о событии, которого не было.

Google отдельно предупреждал, что при систематическом расхождении <lastmod> с реальностью поисковик со временем может перестать полагаться на этот сигнал. Поэтому отсутствие тега лучше, чем заведомо фиктивная дата.

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

Не стоит менять дату только из-за:

• очередной генерации XML-файла;
• обновления copyright в футере;
• технической очистки кеша;
• изменения несущественного глобального элемента, одинакового на тысячах URL;
• запуска cron без изменения самой страницы.

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

Как проверить lastmod Sitemap на реальном сайте

Проверка должна отвечать не на вопрос «тег присутствует?», а на вопрос «можно ли доверять его значениям?».

Начните с трёх групп URL:

Контрольный URL	Что произошло	Какой <lastmod> ожидается
новая страница	опубликована сегодня	сегодняшняя дата публикации/изменения
обновлённая статья	существенно изменён контент	дата последнего значимого обновления
старая страница	несколько месяцев без изменений	старая дата, а не сегодняшний день

Сначала откройте Sitemap непосредственно в браузере и найдите эти URL. XML должен загружаться с HTTP 200, а значения даты — соответствовать реальным изменениям.

После этого полезно повторить запрос независимо от браузерного кеша:

curl -I https://example.com/sitemap.xml

Нормальная базовая проверка — успешный HTTP-ответ и отсутствие редиректной цепочки к неожиданному адресу.

Для конкретной записи можно получить XML и найти URL:

curl -s https://example.com/sitemap.xml | grep -A 2 -B 1 "example-page"

Если Sitemap разбит на дочерние файлы, сначала найдите нужный XML в Sitemap Index, а затем проверяйте запись внутри него.

Google Search Console в отчёте Sitemaps показывает, смог ли Google получить и разобрать отправленный файл, когда он был прочитан и обнаружены ли ошибки обработки. Статус «Успешно» подтверждает обработку Sitemap, но не подтверждает индексацию каждого URL.

В Яндекс Вебмастере для этого используются раздел с файлами Sitemap и инструмент анализа Sitemap. Яндекс отдельно сообщает об ошибках XML, включая неверное значение <lastmod>; дата должна соответствовать W3C Datetime.

Где чаще всего ломается <lastmod>

Всем URL присваивается дата генерации Sitemap

Это наиболее серьёзная логическая ошибка. Поисковик видит массовое «обновление» сайта, хотя страницы не менялись.

Исправление — брать время изменения конкретного объекта либо не выводить <lastmod>, когда такую дату невозможно определить надёжно.

Дата публикации выдаётся за дату последнего изменения

Для никогда не редактировавшейся страницы эти значения действительно могут совпасть. После серьёзного обновления старой статьи <lastmod> должен отражать уже обновление, а не первоначальную публикацию.

Любое сохранение записи считается значимым обновлением

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

Если такие процессы регулярны, источник <lastmod> необходимо проектировать отдельно от простого «последний UPDATE строки в базе».

Sitemap закеширован дольше контента

Страница уже обновлена, а XML продолжает возвращать старое значение. Обратная ситуация тоже возможна: Sitemap обновился, но HTML обслуживается устаревшим кешем.

При диагностике поэтому следует сравнивать одновременно опубликованную страницу, источник даты в CMS и фактически отдаваемый XML.

Используется неверный формат

Пример корректной даты:

<lastmod>2026-10-14</lastmod>

Корректный вариант со временем:

<lastmod>2026-10-14T05:35:00+03:00</lastmod>

Произвольные локальные записи вроде 14.10.2026 для Sitemap использовать не следует.

Особенность WordPress: Core Sitemap не равен Sitemap SEO-плагина

В WordPress XML Sitemaps появились в ядре начиная с версии 5.5 и по умолчанию доступны через /wp-sitemap.xml. При этом WordPress Core сознательно не добавляет <lastmod> в стандартные записи: поле протокола необязательное, а корректный расчёт дат для разных типов объектов создаёт дополнительную сложность и нагрузку.

Поэтому отсутствие <lastmod> в стандартном wp-sitemap.xml само по себе не является ошибкой.

Другая ситуация — когда Sitemap создаёт SEO-плагин или собственный код. Такой генератор может добавлять даты для записей, страниц, товаров и других объектов. Проверять тогда нужно именно его логику: откуда берётся значение и меняется ли оно вместе с реальным документом.

WordPress позволяет разработчику расширять записи Core Sitemap через фильтры. Концептуально для записей это может выглядеть так:

add_filter(
    'wp_sitemaps_posts_entry',
    function ( $entry, $post ) {
        if ( ! empty( $post->post_modified_gmt ) ) {
            $entry['lastmod'] = get_post_modified_time(
                DATE_W3C,
                true,
                $post
            );
        }

        return $entry;
    },
    10,
    2
);

Но сам факт получения post_modified_gmt ещё не решает задачу качества. Если другой процесс массово пересохраняет записи и меняет post_modified, Sitemap честно покажет эти новые значения, хотя для поискового робота содержание могло фактически не измениться.

Практический сценарий: тысячи страниц получили сегодняшнюю дату

Представим интернет-магазин или большой информационный сайт. В 03:00 cron пересобирает Sitemap. После запуска все 20 000 URL получают:

<lastmod>2026-10-14</lastmod>

При этом за сутки действительно изменились только 120 страниц.

Первое действие — не отправлять Sitemap повторно вручную, а найти источник даты. Если генератор использует current_time(), time() или время сборки XML, причина уже понятна.

Далее берётся контрольная выборка:

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

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

Если сайт крупный, полезно сопоставить Sitemap с журналами обращений Googlebot и YandexBot. Это уже позволяет ответить на более важный вопрос: заметили ли поисковые роботы обновлённые URL после появления достоверного сигнала.

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

Что считать успешным исправлением

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

• Sitemap доступен поисковым роботам и возвращает ожидаемый HTTP-ответ;
• XML разбирается без ошибок;
• <lastmod> имеет корректный формат;
• у давно неизменённых страниц дата не прыгает после каждой генерации файла;
• после существенного обновления страницы дата действительно меняется;
• Sitemap не содержит URL, которые сайт сознательно не хочет продвигать в поиске;
• Google Search Console и Яндекс Вебмастер способны получить и обработать файл.

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

Главный критерий качества <lastmod> — не максимальная «свежесть» дат, а их достоверность. Если сайт способен надёжно сообщать поисковику, какие документы действительно изменились, тег выполняет свою задачу. Если такой информации нет, безопаснее опустить необязательный <lastmod>, чем ежедневно генерировать красивый, но ложный сигнал.