Sitemap XML: какие URL передавать поисковым системам

Sitemap XML часто воспринимают как список, который заставляет поисковик добавить страницы в выдачу. Отсюда появляются карты со всеми адресами CMS: результатами фильтров, редиректами, ошибками, личным кабинетом и устаревшими товарами. Файл успешно принимается панелью вебмастера, но сайт продолжает давать противоречивые сигналы.

Sitemap XML — это подсказка об адресах, которые владелец считает каноническими и важными для обнаружения; карта не гарантирует обход, индексирование или позицию.

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

Обычный файл содержит набор элементов url. Для каждого указывают loc — абсолютный адрес страницы. Можно добавить lastmod — дату последнего существенного изменения. Протокол также предусматривает changefreq и priority, но Google сообщает, что игнорирует эти значения. Поэтому назначать всем страницам максимальный приоритет или обещать ускорение обхода бессмысленно.

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

Адреса должны быть абсолютными, а XML — использовать UTF-8 и корректное экранирование специальных символов. По базовому протоколу карта содержит URL одного хоста и охватывает пути не выше каталога, где размещена. Google допускает cross-submission для подтверждённых сайтов и снимает ограничение каталога при отправке через Search Console; Яндекс требует размещать карту и перечисленные URL на одном домене. Поэтому самый простой переносимый вариант — карта в корне нужного хоста. Её адрес можно указать в robots.txt и отправить через Google Search Console и Яндекс Вебмастер.

В карту входят страницы, которые одновременно:

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

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

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

Типовые лишние записи:

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

Не нужно исключать URL из карты только потому, что он временно не показывается по желаемому запросу. Сначала проверяют, должна ли страница участвовать в поиске и является ли канонической. Карта описывает намерение владельца, а не текущую позицию.

Внутренняя ссылка создаёт путь и контекст. Sitemap сообщает о существовании адреса. Индексирование — решение поисковой системы после обработки страницы. Ранжирование — выбор ответа для конкретного запроса.

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

Добавление адреса не исправит:

Все эти условия относятся к общему контуру SEO для бизнеса и качеству страницы. Sitemap лишь делает заявленный список прозрачнее.

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

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

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

Протокол допускает полную дату со временем или только календарную дату в формате W3C Datetime. Главное — корректный формат и единая логика. Не следует придумывать дату вручную для страниц, у которых нет надёжного источника изменения.

changefreq и priority не заменяют lastmod и не позволяют управлять расписанием робота. Даже поисковая система, которая читает дополнительные поля, сама принимает решение о частоте обхода.

По протоколу один файл sitemap ограничен 50 000 URL и размером 50 МБ без сжатия. Если адресов больше, создают несколько карт и перечисляют их в sitemap index. Файлы можно сжимать gzip, но ограничение размера применяется к распакованному содержимому.

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

Индекс карты содержит элементы sitemap с адресом вложенного файла и необязательным lastmod: здесь дата относится к изменению самого файла Sitemap, а не всех перечисленных в нём страниц. Один sitemap index может содержать до 50 000 адресов карт и занимать до 50 МБ без сжатия; он не должен ссылаться на другой sitemap index. Данные об изображениях, видео, новостях и локализованных версиях добавляют только при реальной потребности и по требованиям соответствующего расширения.

В большой системе важно избегать дублирования URL между файлами. Дубликат не создаёт дополнительного веса, зато затрудняет учёт. У каждого типа сущности должен быть понятный генератор и владелец.

В Google Search Console карту отправляют для подтверждённого ресурса, в Яндекс Вебмастере — через раздел файлов Sitemap. Её адрес также можно указать директивой Sitemap в robots.txt. Это помогает роботам находить файл, но не отменяет наблюдение в панелях.

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

Ошибки обработки делятся на несколько уровней:

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

Для данных Яндекса полезен Яндекс Вебмастер: он показывает состояние карты и страниц в контексте этой поисковой системы. Google Search Console отражает Google. Результат одного сервиса нельзя переносить на другой без проверки.

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

Чтобы оценить карту, выгрузите четыре набора:

Затем постройте таблицу:

Сверку проводите по типам страниц. Общий процент скрывает системные различия: 98% корректных URL ничего не говорит, если оставшиеся 2% — весь раздел услуг. Для крупного сайта достаточно сначала проверить репрезентативную выборку каждого шаблона и все необычные состояния, затем автоматизировать правила.

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

Хорошая XML-карта не пытается убедить поисковик, что все адреса одинаково важны; она точно отражает уже принятое решение о составе сайта. Перед выпуском достаточно проверить владельца генерации, каноничность URL, реальные ответы, согласованность с внутренними ссылками и изменения lastmod.