Sitemap часто воспринимают как техническую формальность: плагин сгенерировал XML, адрес добавили в Вебмастер и забыли. На небольшом сайте такой подход обычно долго не мешает. На большом каталоге, интернет-магазине или проекте с фильтрами карта сайта довольно быстро превращается в еще один источник мусора.
Я бы смотрел на Sitemap не как на список всего, что существует в CMS, а как на подсказку роботу: вот страницы, которые мы действительно считаем значимыми и хотим регулярно показывать Яндексу. Это немного меняет логику работы с файлом.
И особенно это заметно, когда сайт растет. Если в XML летят дубли, служебные URL, пустые фильтры и страницы, которые сам сайт считает неканоническими, мы одновременно говорим роботу две разные вещи.
Что Sitemap на самом деле дает Яндексу
Яндекс прямо описывает Sitemap как файл, который сообщает поисковой системе об актуальной структуре сайта. Он особенно полезен там, где страниц много, часть URL находится глубоко в структуре или до некоторых страниц трудно добраться обычными ссылками.
Но наличие URL в Sitemap не означает, что страница автоматически попадет в поиск. Это важное различие. Карта помогает роботу узнать об адресе и планировать обход, а решение об индексировании и показе принимается отдельно.
Поэтому попытка лечить проблемы индексации простым добавлением еще большего количества URL в XML обычно не работает. Если страница закрыта от обхода, возвращает ошибку, является дублем или сама по себе слабая, Sitemap не превращает ее в хорошую посадочную.
Главная ошибка: выгружать в XML все подряд
Типичная картина на крупном сайте: CMS умеет создавать тысячи URL и почти все автоматически оказываются в Sitemap. Там могут лежать страницы пагинации, результаты внутренних фильтров, технические разделы, архивы, пустые категории, варианты одного и того же URL с параметрами.
Формально XML при этом может быть абсолютно валидным. Проблема не в синтаксисе, а в смысле.
Если страница не должна участвовать в поиске, я не вижу причины рекламировать ее поисковому роботу через карту сайта. Сначала полезно определить набор канонических индексируемых URL, а уже из него собирать Sitemap.
Сам Яндекс в документации рекомендует перед созданием файла определить канонические адреса страниц. Это хороший ориентир: карта сайта должна быть продолжением стратегии индексации, а не независимым списком из базы данных.
Что я оставляю в Sitemap
Базовое правило простое: в карте должны находиться страницы, которые сайт считает нормальными самостоятельными документами для поиска.
Для интернет-магазина это обычно категории, нужные подкатегории, индексируемые карточки товаров, полезные статьи и другие реальные посадочные. Для сайта услуг — страницы услуг, направления, статьи и важные информационные разделы.
При этом список надо сверять не только с CMS. Я смотрю, возвращает ли URL 200 OK, не закрыт ли он от робота, не ведет ли canonical на другой адрес и действительно ли страница нужна в индексе.
Если логика сайта говорит Яндексу не индексировать страницу, а Sitemap говорит обратное, лучше убрать противоречие.
lastmod полезнее, чем кажется
В XML можно передавать дату последнего изменения страницы через lastmod. Для меня это не декоративное поле. На больших проектах оно помогает отделять реально обновившиеся документы от тысяч страниц, которые годами не менялись.
Но только если дата честная.
Плохой вариант — при каждой генерации Sitemap ставить всем URL сегодняшнюю дату. Тогда сигнал теряет смысл: робот видит, что якобы изменился весь сайт, хотя фактически контент остался прежним.
Хороший вариант — менять lastmod тогда, когда действительно поменялось содержимое страницы, способное иметь значение для поиска: текст, товарные данные, структура, характеристики, ассортимент или другой существенный блок.
Яндекс отдельно рекомендует для больших сайтов отмечать lastmod у часто обновляющихся Sitemap-файлов, если используется индекс карт сайта. То есть на крупном проекте полезно думать не только на уровне отдельных URL, но и на уровне групп страниц.
Один огромный Sitemap или несколько
Технический предел для одного файла — 50 000 ссылок и 50 МБ в несжатом виде. Но я обычно делю карты раньше, если сайт имеет понятные типы страниц.
Например, отдельно категории, товары, статьи. Не ради SEO-магии, а ради диагностики.
Когда все лежит в одном XML, сложнее понять, какой именно сегмент плохо обходится или содержит ошибки. Раздельные карты позволяют быстрее сопоставить происходящее с типом страниц и не копаться в общей массе URL.
Это особенно удобно после массовых изменений: переезда каталога, смены структуры, добавления новых категорий или чистки фильтров.
Sitemap и краулинговый бюджет
Здесь легко уйти в мифологию. Сам по себе аккуратный Sitemap не заставит Яндекс мгновенно переобойти весь сайт. Скорость обхода робот рассчитывает алгоритмически, стараясь получить максимум страниц без лишней нагрузки на сервер.
Но мусор на сайте все равно имеет значение. В справке по скорости обхода Яндекс прямо советует посмотреть Статистику обхода и проверить, не ходит ли робот по техническим страницам и дублям, в том числе URL с GET-параметрами.
То есть задача не в том, чтобы волшебным XML увеличить бюджет, а в том, чтобы не подсовывать роботу лишние направления для обхода и одновременно поддерживать понятный список нужных страниц.
Что смотреть в Вебмастере после загрузки
Добавить адрес Sitemap и забыть — половина работы. Я проверяю, обработал ли его Яндекс, нет ли ошибок и совпадает ли содержимое карты с тем, что реально происходит на сайте.
Файл должен быть доступен роботу и отдавать 200 OK. Его можно проверить встроенным анализатором Sitemap. Если сервер отвечает слишком долго, это тоже проблема: в документации Яндекса отдельно указано, что при ответе дольше 10 секунд файл не загружается инструментом и не учитывается роботом при обходе.
Если карта уже добавлена и изменилась, удалять ее и добавлять заново не нужно. Робот периодически проверяет файл. В Вебмастере есть и ручной запуск повторной обработки, но я бы не превращал его в ежедневную кнопку.
Нужно ли постоянно отправлять Sitemap заново
Нет. Это еще одна привычка, которая осталась со времен ручной работы с поисковиками.
Если URL карты постоянный, а файл обновляется на этом адресе, Яндекс сам его перепроверяет. После существенных изменений можно ускорить обработку через Вебмастер, но постоянно удалять и добавлять файл смысла нет.
Гораздо полезнее потратить это время на проверку того, что именно попадает внутрь XML.
А что делать с очень большим сайтом
У Яндекса есть интересная рекомендация для сайтов с огромным количеством страниц: из Sitemap можно убрать URL, которые уже известны поиску, и оставлять новые или часто обновляющиеся страницы.
Я бы не применял это механически ко всем проектам. Но сама идея важная: Sitemap — не архив сайта, который обязан хранить каждый существовавший URL. Это рабочий инструмент коммуникации с роботом.
Если проект действительно большой, полезно смотреть Статистику обхода в Вебмастере и уже по фактическому поведению робота решать, как сегментировать карты и какие группы URL требуют внимания.
Мой порядок проверки Sitemap
Я начинаю не с XML, а с вопроса: какие страницы мы вообще хотим видеть в поиске. После этого проверяю, совпадает ли с этим набором карта сайта.
Дальше прохожу по простым вещам: коды ответа, canonical, robots.txt, наличие технических URL, параметры, пустые страницы, корректность lastmod. Потом смотрю обработку файла и Статистику обхода в Вебмастере.
Если сайт большой, разбиваю карту по логическим типам страниц. Так любые перекосы становятся заметнее.
И только после этого есть смысл обсуждать скорость обхода. Часто оказывается, что проблема была не в том, что Яндекс ходит медленно, а в том, что сайт дает ему слишком много ненужных адресов.
Что в итоге
Хороший Sitemap довольно скучный. В нем нет секретных приемов. Он просто содержит правильные канонические URL, нормально открывается, не спорит с robots.txt и логикой индексации, а даты обновления означают реальные изменения.
Именно поэтому я бы периодически проверял карту сайта вручную, особенно после изменений CMS, структуры каталога или SEO-настроек. Один автоматически появившийся тип URL способен незаметно раздуть XML на тысячи страниц.
Sitemap не заменяет внутренние ссылки, нормальную архитектуру и качественные страницы. Но когда он собран аккуратно, Яндексу проще понять, какую часть сайта мы сами считаем важной. А это уже полезная работа, без магии.