Sitemap lastmod по хэшу: как не врать Google датами

Sitemap lastmod для SEO — это дата последнего существенного изменения конкретной страницы, а не дата деплоя, пересборки шаблона или ночного cron. 6 июля 2026 года я проверил sitemap-контур Solar и увидел типовую проблему автоматизированных сайтов: 60 из 126 ключевых URL были без lastmod, а после массового деплоя 131 страница могла выглядеть как обновлённая в один день. Для Google такой сигнал быстро становится шумом.

На 4bos.ru это важно не как отдельная SEO-галочка, а как часть операционной дисциплины. Блог, лендинг клуба, кейсы и технические страницы живут в автоматической сборке. Если генератор sitemap ставит сегодняшнюю дату всем URL при каждом rebuild, поисковик получает плохую телеметрию: робот видит обещание свежего контента, открывает страницу, сравнивает HTML и не находит значимого изменения. Один раз это неприятно, десятки раз подряд — уже репутационная проблема для sitemap.

Почему lastmod нельзя брать из mtime файла

Самый ленивый генератор sitemap берёт дату из файловой системы: когда изменился index.html, такую дату и ставим в <lastmod>. На статическом сайте это выглядит разумно ровно до первого нормального деплоя. Обновили общий header, пересобрали шаблон, почистили CSS, прогнали красивый rebuild — и все страницы получили новую дату, хотя основной текст на них не менялся.

Для человека это мелочь. Для поискового робота это обещание: «на этой странице есть новое содержимое». Google в своей документации по sitemap пишет, что игнорирует <priority> и <changefreq>, но может использовать <lastmod>, если значение стабильно и проверяемо точное. Там же указано, что дата должна отражать существенное изменение страницы: основной контент, структурированные данные или ссылки, а не косметику вроде года в footer. Документация лежит в Google Search Central: Build and submit a sitemap.

Проблема mtime в том, что он честно отвечает на неправильный вопрос. Он говорит, когда файл был записан на диск. SEO спрашивает другое: когда изменилось содержимое, ради которого страницу стоит заново читать. Это разные события. Если их смешать, sitemap превращается из карты изменений в журнал деплоев.

На 4bos.ru деплой может быть техническим: добавили canonical, поправили JSON-LD, обновили шаблон блога, пересобрали листинг, прогнали IndexNow. Часть этих изменений значима для конкретной страницы, часть нет. Слепой mtime не различает эти случаи. Он одинаково реагирует на переписанный абзац статьи и на каскадную пересборку всех файлов после мелкой правки шаблона.

Отсюда правило: <lastmod> должен жить ближе к контенту, чем к файловой операции. Если страница генерируется из markdown, JSON или базы, дата должна вычисляться по содержательному источнику. Если сайт уже хранит только готовый HTML, можно считать хэш нормализованного HTML и двигать дату только при изменении этого хэша.

Что произошло в Solar 6 июля 2026 года

6 июля 2026 года в ежедневной зачистке SEO-инфраструктуры всплыло две связанные проблемы. Первая: у одного из сайтов Solar 60 из 126 URL были без lastmod, причём среди них были важные страницы. Вторая: старые sitemap-генераторы на нескольких проектах ставили дату по времени файла, поэтому после массового деплоя 131 URL на atomi.id выглядел как обновлённый в один день. Для 4bos.ru это был хороший момент не ждать своей версии такой же комедии, а привести sitemap-контур к нормальной модели.

Я сделал общий модуль стабильного lastmod, который смотрит не на mtime, а на хэш HTML. По 460 URL проверка дала 0 ложных изменений. Это не публичная метрика роста и не повод рисовать графики успеха. Это технический sanity-check: генератор перестал выдавать сегодняшнюю дату там, где контент не изменился.

Смысл не в том, что sitemap сразу поднимет позиции. Такой причинно-следственной сказки нет, и она пахнет SEO-ярмаркой с дешёвыми фокусами. Смысл в другом: поисковик получает более честный сигнал о том, какие страницы стоит перечитать. Для сайта с регулярным блогом, кейсами, FAQ и техническими статьями это часть гигиены, как валидный canonical или нормальный robots.txt.

Внутри Solar это легло в общий принцип: автоматизация ценна только после живой проверки. Голосовой бот в тот же день отвечал примерно за 0.85 секунды после вопроса, @daraassistbot снова запускался через ограниченный wrapper под правильным пользователем, PDF КП был пересобран после визуального контроля 7 страниц A4. Sitemap попал в ту же категорию: не «скрипт отработал», а «проверка показала, что сигнал больше не врёт».

Такой подход особенно нужен для статических сайтов. У них нет WordPress-панели, где редактор нажал «обновить запись» и CMS аккуратно изменила дату материала. Есть набор генераторов, cron, файлов, sync-скриптов и шаблонов. Если не развести технический rebuild и содержательное изменение, сайт будет сообщать поисковику о фантомной свежести каждый раз, когда машина тронула файл.

Как устроен стабильный lastmod по хэшу

Базовая схема простая. Генератор берёт URL, читает соответствующий HTML, нормализует его и считает хэш. Затем смотрит в state-файл: какой хэш был у этой страницы в прошлый запуск. Если хэш изменился, обновляем дату lastmod на текущую дату или на дату содержательного источника. Если хэш прежний, оставляем старый lastmod. Никакого шаманства, просто память между запусками.

Нормализация нужна, потому что не всякое отличие HTML означает содержательное обновление. На 4bos.ru можно безопасно выкидывать из сравнения временные технические фрагменты, которые не меняют смысл страницы. Например, служебные комментарии сборки или нестабильные атрибуты, если они появятся. Но нормализация не должна превращаться в пылесос, который съедает всё неудобное. Изменился текст, JSON-LD, FAQ, внутренняя ссылка, canonical или блок TL;DR — это должно менять хэш.

State-файл нужен для стабильности. Без него скрипт не помнит, что видел вчера. В Solar для этого используется состояние в /opt/seo/sitemap_state/, а sitemap пересобирается автоматом. Важная деталь: cron через 10 минут может перезаписать ручную правку sitemap.xml. Поэтому руками sitemap не правится вообще. Ручная правка даёт иллюзию контроля до следующего cron, после чего машина спокойно стирает артистизм человека. Прекрасная маленькая сцена из жанра «я всё держу в голове».

В коде эта логика выглядит примерно так:

url = "https://4bos.ru/blog/primer/"
html = read_html_for_url(url)
normalized = normalize_for_sitemap_hash(html)
new_hash = sha256(normalized)

old = state.get(url)
if old.hash != new_hash:
    lastmod = content_date_or_today()
    state[url] = {"hash": new_hash, "lastmod": lastmod}
else:
    lastmod = old.lastmod

emit_sitemap_url(url, lastmod)

Реальная версия, конечно, учитывает несколько сайтов, директории, sitemap rebuild и ошибки чтения. Но для бизнеса важнее не строка кода, а инвариант: дата в sitemap меняется только тогда, когда страница стала другой по содержанию. Это можно объяснить маркетологу, разработчику и собственнику без семинара по XML.

На 4bos.ru такой инвариант хорошо сочетается с публикацией через helper. Статья выходит через /opt/4bos-blog-sync/agent_publish.py, helper генерирует TL;DR, FAQPage, Article schema, листинг и sitemap. Агент не пишет HTML руками и не трогает шаблон. В итоге источник изменений понятен: либо опубликована новая статья, либо изменён существующий материал, либо обновлена общая инфраструктура. Sitemap не должен смешивать эти события в одну кучу.

Что считать существенным изменением страницы

Для sitemap нужна рабочая граница. Если обновили основной текст статьи, это существенное изменение. Если добавили новый FAQ, это существенное изменение. Если поправили дату, автора, schema.org, canonical, Open Graph или внутреннюю ссылку на близкую статью, это тоже может быть существенным, потому что поисковик и AI-ответы читают не только видимый абзац.

Если поменяли только cache-bust CSS, порядок атрибутов, пробелы, минификацию или год в footer, lastmod лучше не двигать. Для пользователя страница не стала новой. Для Google она тоже не должна выглядеть новой. Это скучно, зато работает. SEO вообще часто выглядит как уборка склада, где каждый ящик подписан, а не как запуск ракеты. Плохая новость для любителей драматических презентаций.

Отдельная категория — изменения в шаблоне. Например, на 4bos.ru в article template может появиться новый блок связанных материалов или дополнительный JSON-LD. Если это влияет на конкретные статьи и меняет структуру страницы, хэш сдвинется и lastmod обновится. Если же изменение чисто декоративное, стоит подумать, нужно ли считать его значимым. Универсального ответа нет, но есть нормальная инженерная процедура: определить, что именно сравнивается, и проверить выборку URL до выката.

Для сайта бизнеса я бы фиксировал минимум 5 типов изменений, которые двигают lastmod:

• новый или переписанный основной текст страницы;
• добавленный FAQ, TL;DR, таблица, чек-лист или кодовый пример;
• изменение структурированных данных Article, FAQPage, Organization или Person;
• изменение canonical, hreflang или значимых внутренних ссылок;
• публикация новой версии страницы через официальный helper или CMS.

И 5 типов изменений, которые обычно не должны двигать lastmod:

• перезапись файла без изменения нормализованного HTML;
• смена версии CSS или JS без изменения контента страницы;
• обновление footer, счётчика, технического комментария сборки;
• массовый rsync или deploy, который только тронул mtime;
• ручная попытка «освежить» sitemap ради поисковика.

Последний пункт особенно важен. Фейковый lastmod не делает страницу свежее. Он только учит поисковую систему, что вашему sitemap лучше не доверять. Для человека это «ну мы же старались». Для робота это шумный датчик. Шумные датчики в нормальных системах либо чинят, либо игнорируют.

Чем sitemap связан с GEO и AI-readiness

GEO, то есть Generative Engine Optimization, любит не только красивые статьи, но и машинную ясность. У страницы должен быть прямой ответ в TL;DR, нормальная FAQ-секция, понятная сущностная разметка, автор, организация, внутренние ссылки и честные даты. Если AI-система вытаскивает фрагмент из статьи, ей помогает не заклинание, а структура: где ответ, кто автор, когда материал обновлялся, какие сущности связаны с темой.

На 4bos.ru каждая новая статья должна проходить через публикационный helper, который добавляет GEO-слой: TL;DR, FAQPage, Article schema и связанные материалы. Sitemap здесь не заменяет контент, а дополняет его. Он говорит краулеру: вот URL, вот когда там было значимое изменение. Если дата правдивая, у системы меньше причин перечитывать одно и то же и больше причин вернуться туда, где появилась новая информация.

Для AI-readiness это особенно заметно на технических материалах. Статья про Telegram CRM, миграцию AI-агентов или голосового бота может обновляться по мере изменения системы. Если обновился только шаблон сайта, дата статьи не должна прыгать. Если добавили рабочий чек-лист, пример payload, новую FAQ-пару или ссылку на свежий кейс, дата должна сдвинуться. Так появляется понятная история изменения знаний, а не календарь случайных deploy-событий.

Сюда же относится /llms.txt, robots.txt с Content-Signal, API catalog и schema.org. Все эти элементы дают машинам карту сайта и контекста. Но карта бесполезна, если стрелка компаса приклеена скотчем к красивому направлению. Lastmod — маленькая стрелка. Ей не нужно быть эффектной, ей нужно не врать.

Юрий Солар, основатель Solar OS, формулирует это проще: «Автоматизация ценна после проверки, когда можно показать пальцем: вот сигнал, вот результат, вот что теперь не врёт молча». Для sitemap это почти идеальное определение. Работает не та система, которая каждый день бодро пишет новую дату, а та, которая умеет молчать, когда ничего не изменилось.

Практический чек-лист для бизнеса

Если у вас сайт на WordPress, Tilda, самописном генераторе или статике, проверку sitemap можно сделать без большого проекта. Нужен один час внимательности и доступ к файлам или Search Console. Начните с 10 случайных URL в sitemap.xml. Откройте lastmod и сравните с фактической страницей: есть ли на ней содержательное изменение в указанную дату. Если все страницы «обновились» сегодня, а текст старый, генератор уже врёт.

Дальше проверьте, есть ли в sitemap <priority> и <changefreq>. Google их игнорирует, поэтому на 4bos.ru и других сайтах Solar эти поля убраны. Их наличие само по себе не катастрофа, но чаще оно показывает старую SEO-механику: добавить побольше тегов, чтобы выглядело серьёзнее. Поисковому роботу не нужна ваша самооценка важности страницы по шкале от 0.1 до 1.0. Ему нужны canonical URL, доступность, контент и честные сигналы.

Затем найдите источник даты. В CMS это может быть дата обновления записи. В статике — front matter. В самописной системе — поле в базе. В худшем варианте это mtime файла. Если видите mtime, задайте неприятный вопрос: что будет после массовой пересборки шаблона. Если ответ «все URL получат сегодняшнюю дату», значит генератор нужно чинить.

Минимальный план внедрения:

1. Собрать список URL из текущего sitemap.xml и сохранить снимок.
2. Для каждого URL посчитать хэш нормализованного HTML.
3. Сохранить state: URL, hash, lastmod.
4. На следующем запуске сравнивать новый hash со старым.
5. Обновлять lastmod только при изменении hash или содержательной даты источника.
6. Не править sitemap.xml руками, если его перезаписывает cron.
7. После выката проверить выборку хотя бы из 20 URL.

Для 4bos.ru я дополнительно смотрю, чтобы статья вышла через официальный helper, имела TL;DR 40-75 слов, FAQ минимум из 3 вопросов, 5 или больше H2-разделов и нормальную schema.org-разметку. Это не украшения. Это контур, в котором статья понятна человеку, поисковику и AI-ответам.

После внедрения нужен отдельный контрольный прогон. Я обычно беру 3 группы URL: свежие публикации, старые статьи и служебные страницы. Свежие должны получить дату публикации или обновления. Старые не должны менять lastmod после пустого rebuild. Служебные страницы требуют отдельного решения: если там меняется список ссылок, это может быть значимым изменением; если только шаблон, дату лучше не двигать. Такой прогон занимает меньше времени, чем последующее объяснение, почему Search Console видит странный всплеск обновлений.

Ещё один полезный тест — двойной запуск генератора подряд. Первый запуск может обновить state после новой публикации. Второй запуск, если контент не менялся, должен дать тот же sitemap. Если второй запуск снова меняет даты, значит где-то остался нестабильный фрагмент: timestamp в HTML, случайный id, порядок блоков, cache-bust или внешний виджет. Такие вещи надо выносить из hash-сравнения или стабилизировать в шаблоне. Иначе система будет честно фиксировать хаос, который сама же производит.

Для команды это удобно оформлять как договор: редактор отвечает за содержательные изменения, разработчик отвечает за генератор и нормализацию, SEO отвечает за выборочную проверку и Search Console. Один владелец у sitemap тоже нужен. Когда за файл отвечают все, обычно никто не замечает, что cron уже месяц публикует фантазию. На 4bos.ru этот владелец — публикационный контур: агент отдаёт payload, helper собирает страницу, rebuild обновляет листинг и sitemap, state lastmod хранит память.

Не стоит пытаться измерять качество lastmod только индексированием на следующий день. Индексация зависит от десятков факторов: внутренние ссылки, качество страницы, история сайта, crawl budget, ответ сервера, canonical, дубли. Lastmod — один сигнал. Его задача не победить поисковик, а не мешать ему. Это хорошая инженерная цель: сначала убрать ложь из данных, потом смотреть на органику и поведение страниц без лишнего шума.

Внутренний критерий приёмки простой: после публикации новой статьи sitemap должен поменять ровно эту статью и нужные листинги, а после пустого rebuild не должен менять ничего. Если меняется больше, надо смотреть diff HTML и state. Если меняется меньше, надо проверять, дошла ли статья до индекса, sitemap и связанных блоков. Машина должна быть скучно предсказуемой.

Самая частая ошибка бизнеса — пытаться решить sitemap отдельно от публикационного процесса. Тогда редактор пишет статью в одном месте, разработчик правит шаблон во втором, SEO-специалист руками «освежает» sitemap в третьем, а cron через 10 минут делает четвёртую версию правды. Потом все смотрят на Search Console и делают вид, что это сложная загадка. Обычно загадка проще: источников правды стало слишком много.

Итоги: sitemap как часть операционной дисциплины

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

6 июля 2026 года в Solar этот слой был приведён к нормальной форме: стабильный lastmod по хэшу HTML, без ручной правки sitemap.xml, без <priority> и <changefreq>, с проверкой 460 URL и 0 ложных изменений на тестовом прогоне. Для 4bos.ru это означает более спокойную публикационную механику: новая статья действительно новая, обновлённая статья действительно обновлена, а технический rebuild не изображает бурную редакционную жизнь.

Близкая тема уже разобрана в статье «Незаметная автоматизация: как SEO-машина работает без рук»: там показан контур источников, agent publish, llms.txt, sitemap и контроль дублей. Текущий материал закрывает узкий, но болезненный участок этой машины — даты в sitemap. Да, это не выглядит как большая фича. Зато именно такие скучные детали потом отличают работающую систему от набора скриптов, который бодро генерирует мусор с уверенным лицом.

Полный набор артефактов — AGENTS.md, промпты, скрипты, чек-листы и публикационные контуры из моей системы — в клубе «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

Solar OS.