Выберите критерии допуска до генерации XML
XML‑карта сайта — это машиночитаемый список URL и опционной метадаты. Начинайте с правила допустимости, а не с дампа данных краулера: включайте страницу только если она предназначена для поиска, публично доступна и является предпочитаемой версией своего контента. Оставляйте вне карты фасетные каталоги, результаты внутреннего поиска, варианты кампаний, страницы входа и превью, если только они не являются намеренно публичными целями поиска.
Публичные, полезные страницы, предназначенные для поиска, с одним предпочтительным URL.
Перенаправления, ошибки, дубликаты, страницы с noindex и приватные маршруты.
Помощь в обнаружении не гарантирует обход или индексацию.
Указывайте канонический URL, а не все способы до него добраться
Канонический URL — это версия, которую вы хотите, чтобы поисковики считали представителем страницы среди похожих версий. Включение в карту сайта является слабым сигналом каноничности, поэтому оно должно подкреплять — а не противоречить — перенаправлениям, self-referential каноническим тегам и внутренним ссылкам. Выберите один стабильный формат HTTPS и выводите именно его.
Проверьте http и https, www и без www, правила со слешем в конце, регистр символов, печатные страницы, фильтры и трекинговые параметры. Если URL перенаправляет, в карту следует вносить только его конечное каноническое назначение. Для каждой локализованной страницы, имеющей собственное целевое назначение, указывайте отдельный канонический URL; не используйте карту сайта для объединения разного локализованного контента.
Пишите полный протокол и хост, а не относительный путь. Google обходит URL в том виде, в котором они перечислены.
Карта сайта, канонический тег, внутренняя навигация и политика перенаправлений должны указывать на одну и ту же страницу.
Блокировка дубликата не устанавливает предпочтительную версию.
Делайте XML маленьким, валидным и правдивым
Используйте структуру Sitemap Protocol: XML в кодировке UTF-8 с urlset, пространством имён sitemap и элементом loc для каждого URL. Экранируйте символы, чувствительные для XML, в значениях URL. Автоматизация должна сериализовать URL, а не собирать XML вручную конкатенацией строк.
Каждая карта сайта может содержать не более 50 000 URL и быть не больше 50 МБ в несжатом виде. Это лимиты, а не целевые значения. Делите файл заранее, если продукты, статьи, локали или типы контента создают полезные операционные границы.
Используйте lastmod только для реальной даты значительного изменения страницы. Google применяет его, когда он последователен и проверяем; обновление только года копирайта таким статусом не является. Никогда не штампуйте каждый URL временем запуска генератора. Google игнорирует changefreq и priority, поэтому опускайте их.
loc обязателен; lastmod опционален и должен описывать страницу, а не момент генерации.
Gzip уменьшает объём передачи, но распакованный файл должен оставаться меньше 50 МБ.
Проверьте корректность XML, доступность по сети и поведение перечисленных страниц.
Используйте индексы, чтобы масштабироваться, не теряя владения
Sitemap index (индекс карты сайта) перечисляет файлы карт сайта. Применяйте его, когда сайт превышает лимиты одного файла или нуждается в раздельных инвентарях. Группируйте по редакционной, товарной или сервисной ответственности. Для него действуют те же лимиты: 50 000 элементов и 50 МБ несжатого размера.
Держите дочерние файлы на целевом сайте по стабильным URL. Протокол в целом привязывает допустимые URL к хосту и расположению sitemap; перекрёстные соглашения требуют подтверждённого владения.
Разделяйте по тестируемой цели — тип контента, витрина, набор языков или граница деплоя. Фиксируйте генератор, владельца и ожидаемую наполняемость.
Отправляйте полный индекс, а не каждый дочерний файл вручную.
lastmod в индексе описывает файл карты сайта, а не его страницы.
Публикуйте, отправляйте и правильно интерпретируйте результаты
Размещайте карту сайта по стабильному, публично доступному HTTPS‑адресу, желательно рядом с корнем. Добавьте абсолютную директиву Sitemap в robots.txt. Отправьте карту или индекс в Google Search Console и Bing Webmaster Tools для получения сведений о обработке.
В Search Console статус Success (Успех) означает, что карта была получена и прочитана без ошибок. Статус Has errors (С ошибками) означает, что файл прочитали с ошибками; Couldn’t fetch (Не удалось получить) означает, что файл был недоступен. Исправляйте доставку, аутентификацию, DNS, правила robots, перенаправления или XML и отправляйте снова.
Рассматривайте количество обнаруженных страниц как диагностический вход, а не как оценку. Обнаруженная страница не гарантирует обход или индексацию. Выбирайте образцы URL и сверяйте их с каноническим URL, ответом сервера и отчётами по индексированию.
robots.txt способствует обнаружению; отправка в инструменты открывает отчёты обработки.
Search Console показывает файлы, отправленные через отчёт или API, а не все, найденные через robots.txt.
Эксплуатируйте карту сайта как критическую инфраструктуру релизов
Качество карты сайта может деградировать, когда плагин CMS меняет поведение, релиз изменяет канонический хост, правила кэширования отдают устаревший вывод или массовая операция публикует неполные страницы. Включите проверки карты сайта в предпусковые и откатные процедуры. Не заменяйте молча полный инвентарь пустым или некорректным файлом.
Храните предыдущую заведомо корректную карту, помечайте неожиданные изменения в количестве URL и выбирайте образцы добавлений и удалений до публикации. Когда меняются пути, координируйте перенаправления, канонические теги, внутренние ссылки и карты сайта как единый набор изменений. Это проактивная оптимизация доступности: защищайте обнаруживаемую публичную поверхность до того, как краулеры и посетители столкнутся с битым путём.
Приостанавливайте публикацию при некорректном, пустом, с неправильным хостом или неканоническом выводе карты сайта.
Держите предыдущий артефакт и конфигурацию генератора готовыми для отката.