XML Sitemap: какие URL включать и как отслеживать ошибки

Какие URL включать в Sitemap

Google рекомендует указывать URL, которые должны появляться в поиске, и выбирать предпочтительные canonical-версии, а не все дубли. Canonical — это основной вариант страницы среди одинаковых или очень похожих URL. Само присутствие в Sitemap является лишь слабым сигналом канонизации: поисковая система может выбрать другую версию, если остальные сигналы ей противоречат. Это зафиксировано в инструкциях Google по созданию Sitemap и канонизации. Яндекс рекомендует сначала определить канонические URL для Sitemap и в общем случае включать значимые страницы: основная справка Яндекса. В отдельном официальном материале Яндекс перечисляет среди нежелательных записей редиректы, ответы 404/500, noindex, Disallow и дубли: рекомендации Яндекса об обновлениях сайта.

Матрица ниже превращает это правило в решение для каждого класса страниц.

Я бы не принимал широкое правило «все URL со знаком вопроса исключить»: оно может удалить полезные страницы фильтров или региональные версии. Но и обратная крайность вредна: UTM-метки, сортировки и идентификаторы сессий не должны размножать один документ. Решение принимается по самостоятельности содержания и выбранному canonical, а не по внешнему виду адреса.

Sitemap не заменяет внутренние ссылки. Страница может находиться в XML, но оставаться изолированной от навигации и контекста сайта. Поисковой системе легче интерпретировать URL, когда Sitemap, canonical, HTTP-ответ, правила индексирования и доступные HTML-ссылки говорят одно и то же.

Сначала определите источник истины

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

Для каждого типа страниц источник должен отвечать на пять вопросов:

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

Рассчитайте ожидаемое количество URL до сборки файла.

Если правила публичности и canonical зависят от платформы, их нужно проверять на уровне самой системы управления контентом. Ограничения таких генераторов и модулей разобраны отдельно в материале о SEO-возможностях CMS.

У задачи должен быть владелец. Разработчик отвечает за контракт и выпуск генератора, SEO-специалист - за поисковые правила и проверку состава, владелец контента или каталога - за публикационные статусы, а ответственный за проект принимает результат по доказательствам. Формулировка «сделать Sitemap» слишком широка: в ней нет ни входных данных, ни проверяемого результата. Распределение ролей удобно закреплять внутри общего процесса SEO-работ, а не восстанавливать после первой ошибки.

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

Минимальный XML и два вида экранирования

Обычный XML Sitemap использует кодировку UTF-8 и namespace http://www.sitemaps.org/schemas/sitemap/0.9. В обязательном минимуме нужны корневой <urlset>, отдельный <url> для страницы и абсолютный адрес в <loc>. Эти правила, допустимые элементы и ограничения закреплены в протоколе Sitemap.

Ниже учебный пример на домене example.com. Это не конфигурация Медиакода.

<?xml version="1.0" encoding="UTF-8"?><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">  <url>    <loc>https://www.example.com/services/seo</loc>    <lastmod>2026-07-30</lastmod>  </url>  <url>    <loc>https://www.example.com/catalog?brand=alpha&amp;page=2</loc>    <lastmod>2026-07-29T14:30:00+03:00</lastmod>  </url></urlset>

В этом фрагменте есть несколько деталей, которые часто ломают генератор:

• http:// внутри namespace указан протоколом. Его не нужно самовольно менять на https://.
• <loc> содержит полный URL с протоколом и хостом.
• амперсанд в XML записан как &, иначе документ может перестать быть корректным XML;
• URL encoding и XML entity escaping - разные операции: сначала адрес приводится к корректному URI/IRI, затем специальные символы экранируются для XML;
• <lastmod> передается только при наличии достоверной даты значимого изменения.

Два этапа экранирования особенно заметны в международных и параметризованных адресах. Unicode-символ может потребовать percent-encoding по правилам URI/IRI, а &, <, >, кавычки и апостроф внутри XML имеют собственное представление. Требования определяют RFC 3986, RFC 3987 и спецификация XML. Проверка только того, что ссылка открывается в браузере, не заменяет XML-парсер.

Как использовать lastmod без вымышленных обновлений

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

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

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

Внутри sitemap index значение <lastmod> относится к изменению дочернего файла Sitemap, а не к последней странице в нем. Это отдельное правило: протокол Sitemap. HTTP-заголовок Last-Modified тоже является самостоятельным механизмом кеширования и не подменяет <lastmod> страницы.

Changefreq и priority работают по-разному в Google и Яндексе

Дополнительные теги нельзя описывать одним универсальным правилом. Google прямо сообщает, что игнорирует changefreq и priority; высокий priority не повышает позиции. Яндекс описывает changefreq как необязательную рекомендацию и документирует учет priority при выборе очередности загрузки, но не как фактор ранжирования. Сравнение подтверждают документация Google и справка Яндекса.

Не стоит присваивать всем коммерческим страницам priority=1.0, а статьям более низкие значения в надежде управлять выдачей. Для Google это поле не работает, а для Яндекса оно не превращается в оценку качества страницы. Если команда не может объяснить шкалу и проверить ее применение, дополнительный тег лишь усложняет генератор.

Лимиты, gzip и Sitemap index

Один Sitemap может содержать не более 50 000 URL и занимать не более 50 МБ в несжатом виде. Один sitemap index может перечислять до 50 000 дочерних Sitemap. Gzip уменьшает объем передачи, но не повышает лимит распакованного XML. Вкладывать sitemap index в другой sitemap index нельзя. Актуальные ограничения приведены в протоколе Sitemap, документации Google для больших карт и справке Яндекса.

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

Большие наборы лучше делить по стабильному и диагностируемому признаку:

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

Такое разделение называют шардированием. Его польза не в ранжировании, а в локализации проблемы. Если дочерний файл товаров неожиданно потерял 30 процентов URL, команда сразу знает, какой источник и шаблон проверять. Произвольные файлы sitemap-1.xml, sitemap-2.xml и sitemap-3.xml с постоянно меняющимся составом дают меньше диагностической пользы.

Sitemap index для двух стабильных классов:

<?xml version="1.0" encoding="UTF-8"?><sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">  <sitemap>    <loc>https://www.example.com/sitemap-services.xml.gz</loc>    <lastmod>2026-07-30T15:10:00+03:00</lastmod>  </sitemap>  <sitemap>    <loc>https://www.example.com/sitemap-articles.xml.gz</loc>    <lastmod>2026-07-31T09:20:00+03:00</lastmod>  </sitemap></sitemapindex>

Главный и дочерние файлы разумно размещать в корне сайта, если они перечисляют URL из разных веток. По базовому протоколу и для Яндекса карта в /catalog/ описывает URL этого каталога и его подкаталогов, но не /services/. Для Google это ограничение пути действует, если Sitemap не отправлен через Search Console; отправка через Search Console является отдельным исключением. Cross-site submission требует подтверждения прав на затронутые сайты. Для поддоменов безопаснее использовать отдельные карты. Яндекс также требует совпадения домена, протокола, хоста и варианта www: протокол, Google об области действия и cross-site submission, Яндекс о Sitemap.

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

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

Предварительная приемка нужна до того, как адрес появится в Google Search Console или Яндекс Вебмастере. Зеленый статус панели не исправит ошибку источника, а обработка неверного файла только расширит область диагностики.

• Определены источник истины и правила публикации, canonical и indexability для каждого типа страниц.
• Ожидаемое число URL рассчитано по типам и сверено с уникальными <loc>.
• Все <loc> абсолютные и относятся к разрешенному origin.
• В выборке нет необоснованных 3xx, 4xx, 5xx, soft 404, noindex, robots-blocked и неканонических URL.
• XML использует UTF-8, корректный namespace и проходит парсер; URI encoding и XML escaping проверены отдельно.
• Число URL и несжатый размер ниже рабочих порогов; gzip распаковывается без ошибки.
• Главный и дочерние файлы возвращают прямой 200 без авторизации, cookie и редиректа.
• lastmod отражает значимое изменение или не передается.
• Проверены включаемые и исключаемые URL каждого класса.
• Сохранена предыдущая версия и описан откат.
• Назначены владельцы генератора, мониторинга и исправления.

Для проверки нужен фактически опубликованный ответ, а не только файл в репозитории. CDN, кеш, правила маршрутизации и сборка могут изменить результат. Если используется sitemap index, каждый дочерний файл проверяется отдельно.

Как передать Sitemap Google и Яндексу

Google поддерживает три практических способа: добавить адрес в Google Search Console, использовать авторизованный Search Console API или указать абсолютный URL строкой Sitemap: в robots.txt. Старый открытый ping endpoint отключен и возвращает 404, поэтому его нельзя оставлять в cron или плагине: способы отправки Google, отключение ping.

Отчет Sitemaps в Search Console показывает файлы, отправленные через интерфейс или API. Sitemap, найденный только в robots.txt, может использоваться Google, но не обязан появиться в этом отчете. После успешного чтения Google периодически получает файл повторно; неизмененный XML не нужно отправлять несколько раз в день. Удаление записи из отчета также не заставляет Google забыть ранее обнаруженные URL: описание отчета Sitemaps.

Для Яндекса адрес указывают директивой Sitemap: в robots.txt или добавляют в разделе Индексирование -> Файлы Sitemap. Измененный файл не требуется удалять и создавать заново: робот проверяет обновления. Приоритетное обновление имеет отдельные лимиты, поэтому его используют после существенного исправления, а не как обязательный шаг при каждой публикации. Sitemap не стоит отправлять как обычную страницу через инструмент переобхода вместо специализированного раздела: Файлы Sitemap в Яндекс Вебмастере, директива Sitemap.

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

Лестница доказательств: от файла до страницы в поиске

Статус Success или OK относится к файлу, а не ко всем страницам внутри. Для меня принципиально разделять: статус файла не является статусом страниц внутри него. Чтобы команда не спорила о слове «отправили», полезно разделить шесть последовательных состояний.

В Google поле Discovered pages означает число уникальных URL, распарсенных из файла, а не число обойденных или проиндексированных страниц. Last read показывает, когда Google в последний раз получил файл; успешную обработку без ошибок подтверждает статус Success. Точную семантику полей описывает справка Search Console.

В Яндексе признак fromSitemap=true подтверждает, что URL обнаружен из карты. Дата и код обхода относятся к следующему уровню, а присутствие в поиске проверяется отдельно. Эти данные описаны в справке об архиве страниц, статистике обхода и проверке важных страниц.

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

Пять классов ошибок и порядок диагностики

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

Класс A. Поисковая система не может загрузить файл

Сначала проверяется точный адрес из панели: протокол, хост, www, регистр пути и расширение. Затем файл запрашивается без браузерной сессии. Нужен прямой 200, а не цепочка редиректов, HTML-страница входа или ответ, зависящий от cookie. Для Яндекса отдельными причинами ошибки могут быть долгий ответ, DNS, пустой ответ, запрет в robots.txt и проблема gzip: анализ Sitemap, справочник ошибок.

Класс B. Файл загружается, но не разбирается

Нужно скачать именно опубликованный ответ, распаковать его при необходимости и передать XML-парсеру. Проверяются корневой элемент, namespace, обязательные элементы, кодировка, экранирование, число записей и несжатый размер. В sitemap index каждый дочерний файл проверяется отдельно. Частая ошибка - валидный index с одной битой дочерней картой, из-за которой теряется целый класс страниц.

Класс C. Файл обработан, но количество URL не совпало

Сравниваются три числа: ожидаемый набор из источника, уникальные <loc> в опубликованном файле и распознанные URL в панели. Разница может появиться из-за дублей, пропущенного типа страниц, ошибки одного дочернего файла, разных origin, кеша или задержки отчета.

Класс D. URL обнаружен, но не индексируется

На этом этапе Sitemap уже выполнил свою задачу обнаружения. Проверяются HTTP-код и soft 404, noindex, robots, canonical, дубли, внутренние ссылки, доступность сервера и самостоятельная ценность страницы. Для динамической страницы отдельно проверяют, какой основной контент видит конкретная поисковая система в отрендеренной версии: Google выполняет JavaScript при рендеринге, а Яндекс по умолчанию самостоятельно решает, выполнять ли его: Google о JavaScript SEO, Яндекс о рендеринге. Повторная отправка того же файла не исправляет конфликт страницы.

Класс E. Старые URL не исчезают

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

Мониторинг после выпуска

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

Хороший мониторинг не сообщает команде просто «в Sitemap ошибка». Он называет затронутый тип страниц, размер отклонения, владельца исправления и решение: чинить, откатывать или наблюдать.

Автоматически полезно проверять:

• HTTP-код и отсутствие редиректа у главного и дочерних файлов;
• время ответа;
• корректность XML и gzip;
• несжатый размер;
• число всех и уникальных <loc>;
• изменение состава по типам страниц;
• долю 3xx, 4xx, 5xx, noindex и неканонических URL в выборке;
• слишком свежий, одинаковый или будущий lastmod;
• дату последнего получения файла и отдельный статус его обработки в панелях;
• ошибки загрузки и разбора.

Рабочий журнал может выглядеть так:

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

Когда Sitemap можно принимать

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

Хороший Sitemap не обязательно сложный. Его качество видно по согласованности: источник данных, XML, canonical, HTTP, правила индексирования и поисковые панели описывают один и тот же набор страниц. У каждого расхождения есть затронутый тип URL, владелец и следующее действие.

Если проверка затрагивает несколько CMS, большой каталог, параметры, дубли, редиректы и разные правила Google и Яндекса, работа выходит за рамки создания одного файла. Ее разумно включить в техническую часть SEO Медиакода: сначала определить целевой состав страниц и критерии приемки, затем менять генератор и передавать результат поисковым системам.