Sitemap.xml: какие страницы включать и когда менять lastmod

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

Sitemap.xml включает только канонические адреса, отдающие ответ 200, не закрытые в robots и не являющиеся дублями. Lastmod меняют при существенном изменении содержимого страницы, а не при пересборке файла или правке шаблона. Карта сообщает перечень адресов, но не гарантирует обход и индексацию, поэтому её состав сверяют с фактическим состоянием сайта.

Когда карта сайта расходится с реальностью: сборка состава и даты изменения

Представьте условный магазин на 1 800 адресов: каталог, статьи, фильтры, старые акции. Владелец просит «сделать карту сайта, чтобы всё быстрее попало в поиск», а через месяц выясняется, что в файле половина адресов отдаёт редирект, часть закрыта в robots, а дата изменения у всех страниц равна дню выгрузки. Это не гипотетическая катастрофа, а типичное расхождение между тем, что лежит в файле, и тем, что реально существует на сервере.

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

Если ваша задача — проверить поисковую карту, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Три разные задачи, которые путают в одном файле

Состав карты, канонический адрес и дата изменения — это три независимых решения, и каждая ошибка живёт своей жизнью. Если смешать их в одном порыве «обновить всё», получается файл, который врёт сразу по трём пунктам.

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

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

Что говорит документация, а что она не обещает

Официальное руководство Google по сборке карты сайта перечисляет технические требования к формату и ограничения по размеру, а также прямо оговаривает, что наличие адреса в файле не гарантирует обход и индексацию. Это стоит держать в голове: файл — заявка, а не команда. Общие принципы Google Search Essentials описывают, что вообще считается качественным контентом и какие технические условия важны для попадания в поиск; карта там — лишь один из вспомогательных механизмов.

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

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

Арифметика размера и порог, после которого файл делят

У карты есть технические лимиты: количество адресов в одном файле и размер файла в байтах. Когда сайт перерастает порог, файл делят на несколько частей и собирают индексный файл, который ссылается на них. Это не бюрократия, а способ не отдавать поисковой системе гигантский ответ, который она может не дочитать.

Условный пример: каталог на 40 000 адресов при лимите 50 000 формально влезает в один файл по количеству адресов, но по размеру файла может приблизиться к границе, если адреса длинные. Если завтра добавится раздел статей, файл перевалит. Поэтому деление планируют заранее, по смысловым группам: товары, категории, статьи, служебные страницы. Тогда при росте одного раздела не приходится перекраивать весь файл.

Отдельно про сжатие: файл можно отдавать в сжатом виде, и это снижает нагрузку на канал. Но сжатие не меняет состава — если внутри лежат редиректы, они там и останутся, просто быстрее передадутся. Экономия трафика не лечит содержательных ошибок.

Редирект в карте: почему адрес-призрак хуже отсутствия адреса

Редирект в карте — самая частая и самая безобидная на вид ошибка. Старый адрес товара переехал на новый, а в файле остался прежний. Поисковая система приходит по нему, получает ответ 301 и уходит на новый адрес. Формально ничего не сломалось, но файл теперь сообщает неверную информацию: он заявляет как канонический адрес, который каноническим не является.

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

Правило простое: в карте должен быть конечный адрес, который отдаёт ответ 200 и не перенаправляет. Редиректы из файла убирают, а не «оставляют на всякий случай». Если старый адрес важен для сохранения ссылочного веса, он живёт как редирект на сервере, но в карту не попадает.

Закрытые страницы и служебные адреса: что не должно попадать в перечень

Страница, закрытая в robots.txt или отдающая запрет на индексацию, в карте бессмысленна: вы просите обойти то, что сами закрыли. Это не ошибка сервера, а противоречие в инструкциях, и поисковая система разрешает его не в пользу файла.

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

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

Дубли адресов: один канонический, остальные — вне файла

Дубли — это когда одна и та же страница доступна по нескольким адресам: с www и без, с завершающим слешем и без, с параметрами отслеживания. В карте должен быть ровно один адрес — тот, который вы объявили каноническим.

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

Проверка здесь механическая: для каждой группы дублей выписать канонический адрес и сверить его с тем, что реально отдаёт сервер и что указано в разметке. Расхождение — повод не «поправить файл», а разобраться, какой адрес вообще считается основным. Иногда выясняется, что единого мнения нет даже внутри команды.

Дата изменения: что считать существенным

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

Разумный подход: считать существенным изменение, которое меняет смысл страницы для читателя, — новый товар, переписанное описание, обновлённые условия, добавленный раздел. Косметика, правка опечатки в подвале, смена года в шапке — не повод двигать дату. Если дата двигается на всё подряд, она перестаёт что-либо значить, и поисковая система вправе её игнорировать.

Отдельная ловушка — шаблонные правки. Обновили дизайн, и дата изменилась у всех страниц сразу. Технически файл не соврал: страница действительно изменилась. Но с точки зрения содержания ничего не произошло, и такой всплеск дат только создаёт шум. Шаблонные изменения стоит исключать из логики проставления даты на уровне генератора.

Как выглядит рабочий объект: строка реестра страниц

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

Такая таблица решает сразу несколько задач. Она отделяет канонический адрес от всех прочих вариантов. Она хранит дату существенного изменения отдельно от технической даты сборки. И она позволяет перед выгрузкой прогнать проверку: нет ли в файле адресов со статусом не 200, не попали ли туда закрытые страницы, не двигалась ли дата у шаблонных правок.

Генератор карты в этой схеме — тонкий слой: он берёт строки с in_sitemap = да и status = 200 и собирает из них файл. Логика отбора живёт в реестре, а не в скрипте, и её можно объяснить человеку, который не пишет код.

Эпизод первый: новый раздел, на который никто не ссылается

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

Разбор показывает: в карте адреса есть, ответ 200, даты проставлены. Но ни одна страница сайта не ссылается на новый раздел — он висит в меню, которое подгружается скриптом и не попадает в HTML. Для поисковой системы раздел существует только в файле, а файл — вспомогательный сигнал, не заменяющий ссылки.

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

Этот эпизод полезен как напоминание: карта — не замена внутренней перелинковке. Если страница важна, на неё должна вести ссылка с сайта. Файл лишь подтверждает, что адрес существует.

Эпизод второй: массовая правка шаблона и всплеск дат

Другой условный сценарий: на сайте меняют подвал — добавляют строку с юридическим адресом. Правка применяется ко всем страницам через шаблон, и генератор карты, видящий изменение HTML, проставляет сегодняшнюю дату всем 1 800 адресам.

Внешне всё корректно: страницы действительно изменились. Но с точки зрения содержания не поменялось ничего, а карта теперь заявляет, что весь сайт обновился в один день. Если такое происходит раз в месяц, дата перестаёт быть сигналом.

Решение — разделить технические и содержательные изменения на уровне источника данных. Реестр хранит last_meaningful_change, которое двигает редактор, а не генератор. Шаблонные правки в реестр не попадают вовсе. Тогда карта отражает реальную историю контента, а не историю релизов.

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

Состав XML-карты сайта: когда правило не срабатывает

Не всякий случай укладывается в схему «канонический адрес, ответ 200, дата существенной правки». Несколько исключений стоит проговорить заранее.

Страница с ограниченным доступом. Часть контента открывается только после авторизации. В карту такие адреса не включают, но и не удаляют из реестра — они остаются со статусом «не для карты», чтобы при следующей выгрузке их случайно не добавили.

Страница, которая временно недоступна. Ответ 503 во время технических работ — не повод вычищать адрес из карты: временную ошибку не стоит путать с удалением страницы, достаточно дождаться восстановления. Реестр должен позволять это сделать без потери истории.

Многоязычные версии. У каждой языковой версии свой канонический адрес, и в карте они существуют как отдельные записи. Ошибка — указывать в карте только основной язык и надеяться, что остальные найдутся сами.

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

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

Состав XML-карты сайта на экране сотрудника

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

Что стоит показать на таком экране: количество адресов в файле и в каждой группе; адреса, которые отдают не 200; адреса, закрытые в robots; записи, у которых дата изменилась сегодня; записи без единой внутренней ссылки. Каждый пункт — не приговор, а повод посмотреть.

Отдельно полезно показывать diff: что изменилось в файле по сравнению с прошлой выгрузкой. Добавленные адреса, удалённые, изменившие дату. Это позволяет заметить всплеск дат от шаблонной правки до публикации, а не после.

Кнопка «опубликовать» на таком экране должна быть последним шагом, а не первым. Сотрудник сначала смотрит на список проблем, потом решает, какие из них допустимы, и только затем выгружает файл. Такой порядок снижает вероятность, что в карту уедет мусор.

Проверки перед публикацией: короткий чек-лист

Проверки стоит превратить в повторяемую процедуру, а не в разовый героизм. Ниже — набор, который покрывает основные ошибки.

Этот чек-лист полезен тем, что каждая строка соответствует конкретному классу ошибок, а не абстрактному «качеству». Прогон занимает время, но результат предсказуем: файл перестаёт быть источником сюрпризов.

Отдельно стоит проверять, что карта доступна по ожидаемому адресу и не закрыта сама. Мелочь, которая случается чаще, чем кажется.

Практикум: разбор условной карты интернет-магазина

Возьмём условный магазин с 2 400 адресами в карте и разберём его по шагам. Цифры вымышленные, но логика применима к реальному сайту.

Шаг первый — статусы. Выгрузка показывает 180 адресов с ответом 301 и 40 с ответом 404. Редиректы заменяем конечными адресами, 404 убираем: страницы больше нет. После этого в файле 2 180 адресов.

Шаг второй — закрытые. Из оставшихся 60 адресов закрыты в robots — это страницы фильтров, которые кто-то добавил вручную. Исключаем. Остаётся 2 120.

Шаг третий — дубли. Находим 30 групп, где один товар доступен с параметром и без. В карте оставляем по одному адресу на группу, сверяем с разметкой. Остаётся 2 090.

Шаг четвёртый — даты. Видим, что у 1 500 адресов дата равна дню выгрузки. Проверяем: в этот день меняли шаблон. Откатываем даты к последним содержательным правкам из реестра. Остаётся 2 090 адресов с честными датами.

Шаг пятый — ссылки. Для 25 новых адресов нет внутренних ссылок. Добавляем ссылки из категорий и смежных товаров. Карту не трогаем.

Итог: файл стал меньше на 310 адресов, но каждый оставшийся корректен. Это и есть цель — не размер, а совпадение с реальностью.

Проверка на практике: состав xml-карты сайта

Если из всей статьи нужен один конкретный шаг, начните с выгрузки текущей карты и сверки статусов. Возьмите список адресов, прогоните его через проверку ответов сервера и посмотрите, сколько из них отдаёт редирект или ошибку. Это займёт немного времени и сразу покажет масштаб расхождения.

Дальше — по обстоятельствам: если редиректов много, стоит задуматься о реестре страниц как источнике правды; если даты у всех одинаковые, стоит проверить логику генератора. Но начать проще всего со статусов, потому что это самая механическая и самая наглядная проверка.

Карта сайта остаётся скромным вспомогательным файлом. Её ценность не в том, что она «ускоряет индексацию», а в том, что она честно описывает сайт. Честность здесь складывается из мелочей: конечных адресов, отсутствия закрытых страниц, дат, которые что-то значат. Начать можно с одной проверки — и этого обычно достаточно, чтобы увидеть, где файл расходится с реальностью.

Смежный вопрос разобран отдельно: Индексация сайта в Яндексе: проверка и исправления.