Бесплатный валидатор карты сайта

Что такое sitemap.xml и почему это важно?

Sitemap — это структурированный XML-документ, содержащий список URL сайта, о которых вы хотите сообщить поисковым системам. Он публикуется по стабильному пути, почти всегда /sitemap.xml, и следует протоколу Sitemap — небольшой спецификации, первоначально опубликованной Google в 2005 году и принятой в качестве совместного стандарта Google, Yahoo и Microsoft год спустя. Формат прост: корневой элемент <urlset>, содержащий по одному элементу <url> на каждую страницу, с необязательными метаданными о том, когда каждый URL был последний раз изменён, как часто он обновляется и каков его относительный приоритет по сравнению с другими страницами сайта.

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

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

Sitemap важен и для длинного хвоста. Сайт со 100 000 страниц товаров, 5 000 записей в блоге и 200 категориями содержит слишком много страниц, чтобы любая схема внутренней перелинковки делала каждый URL доступным в несколько кликов. Без sitemap сайт полагается на исследовательский обход Googlebot для обнаружения глубоких URL, что работает, но медленно. С sitemap каждый URL становится известен Google немедленно, и краулер может тратить свой бюджет на проверку актуальности и качества контента, а не на обнаружение страниц. Для интернет-магазинов, новостных изданий, маркетплейсов и контентных сайтов sitemap не является опциональным.

Как использовать этот инструмент

Инструмент принимает URL sitemap или корневой домен и возвращает структурированный отчёт о валидности, полноте и доступности.

Шаг 1 — Введите URL sitemap. Вставьте полный URL вашего sitemap или просто домен — инструмент выполнит автообнаружение через robots.txt и попробует распространённые пути: /sitemap.xml, /sitemap_index.xml и /sitemap.xml.gz. Он также автоматически следует по файлам sitemap-index и обходит все дочерние sitemap внутри них.

Шаг 2 — Изучите отчёт о валидности. Инструмент проверяет XML на соответствие схеме протокола Sitemap, выявляет некорректные значения lastmod, проверяет URL на превышение лимита пути в 2048 символов и подтверждает, что файл не превышает жёстких ограничений в 50 МБ несжатого текста и 50 000 URL. Каждая проблема отображается с точным URL или номером строки, вызвавшим её.

Шаг 3 — Проверьте доступность. Для выборки URL из sitemap инструмент выполняет HEAD-запрос и сообщает код ответа. URL в sitemap, возвращающие 404, 301, 302 или 5xx, — это шум, расходующий краулерный бюджет. Отчёт отображает их сгруппированными, чтобы вы могли исправить или удалить их.

Протокол sitemap в деталях

Минимально валидный sitemap выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-04-27T12:00:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/article</loc>
    <lastmod>2026-04-15</lastmod>
  </url>
</urlset>

Обязательным является только <loc>. Три остальных необязательных поля — <lastmod>, <changefreq> и <priority> — в современной практике трактуются по-разному.

Жёсткие ограничения и паттерн sitemap-index

Один файл sitemap может содержать не более 50 000 URL и должен быть не больше 50 МБ в несжатом виде. Эти ограничения существуют в протоколе с момента запуска и применяются всеми основными краулерами. Файлы, превышающие лимит, не просто усекаются — они полностью отклоняются Googlebot, который затем сообщает об ошибке в Search Console. Для сайтов с большим количеством URL, чем помещается в один файл, протокол определяет формат sitemap-index, содержащий список нескольких дочерних sitemap:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
</sitemapindex>

Индекс может содержать до 50 000 дочерних sitemap, каждый из которых включает 50 000 URL, что даёт теоретический лимит в 2,5 миллиарда URL для всего сайта. На практике организация по типу контента — страницы, товары, записи блога, теги, категории — создаёт поддерживаемую структуру и позволяет перегенерировать только изменившийся дочерний sitemap при каждом деплое. Принято называть индекс sitemap.xml или sitemap_index.xml, а дочерние файлы — с описательными путями.

Точность lastmod и когда Google ему доверяет

Google неоднократно заявлял, что использует lastmod, когда значение достоверно, и обесценивает его для всего sitemap, когда оно выглядит ненадёжным. Сайт, который всегда указывает сегодняшнюю дату для каждого URL, декларирует актуальность, которой нет; Google обнаруживает паттерн и перестаёт учитывать это поле. То же относится к значениям lastmod, которые никогда не обновляются даже при изменении контента — отсутствие сигнала само по себе является сигналом.

Используйте полный формат ISO 8601 с указанием смещения часового пояса: 2026-04-27T12:00:00+00:00. Форма только с датой 2026-04-27 допустима и принимается, но форма с временем предпочтительна для часто обновляемых сайтов, где время суток имеет значение. Устанавливайте lastmod по реальному времени изменения содержимого страницы, а не по времени деплоя приложения. Страницы, которые не изменились, должны сохранять прежнее значение lastmod, даже когда остальная часть sitemap перегенерируется.

changefreq и priority: преимущественно игнорируются

Поля <changefreq> и <priority> были определены в исходном протоколе, чтобы владельцы сайтов могли указывать, как часто страница изменяется (always, hourly, daily, weekly, monthly, yearly, never), и её относительный приоритет на сайте (десятичное число от 0.0 до 1.0). Современный Google игнорирует оба поля. Краулер определяет частоту обхода на основе наблюдаемых паттернов изменений, а приоритеты — исходя из качества контента и ссылочного веса, а не из деклараций в sitemap.

Практическая рекомендация — не использовать оба поля. Они увеличивают размер и сложность sitemap, не влияя на поведение краулера. Документация Bing предполагает, что changefreq всё же слабо учитывается, но влияние настолько незначительно, что поддержание точных значений редко оправдывает инженерные затраты. Чистый sitemap только с <loc> и <lastmod> — современный стандарт по умолчанию.

Автообнаружение через robots.txt и отправка через Search Console

Есть два способа сообщить Google о sitemap: указать его в robots.txt или отправить через Search Console. Оба метода работают, оба рекомендуются, и их совместное использование — современная лучшая практика.

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

Объявление в robots.txt считывается всеми добросовестными краулерами — Googlebot, Bingbot, DuckDuckBot, Yandex и большинством SEO-инструментов — без какой-либо платформоспецифичной настройки. Отправка через Search Console специфична для Google, но открывает отчёты об индексировании, показывающие, сколько URL из sitemap проиндексировано, сколько исключено и почему. Для сайта, который серьёзно относится к SEO: отправляйте через Search Console для получения отчётности и указывайте в robots.txt для переносимости.

Расширения sitemap для изображений, видео и новостей

Базовый протокол имеет расширения для изображений, видео и новостей. Sitemap для изображений добавляет элемент <image:image>, перечисляющий изображения на каждой странице, что помогает Google обнаруживать изображения на страницах с JavaScript, где URL изображений отсутствуют в исходном HTML. Sitemap для видео добавляет элемент <video:video> с названием, описанием, превью и длительностью и остаётся стандартным способом передавать видео в Google Video. Sitemap для новостей использует отдельный элемент <news:news> с датой публикации и обязательным пространством имён и является обязательным условием для включения в Google News.

Для типичного маркетингового или контентного сайта обычного URL-sitemap вполне достаточно. Расширения оправданы по сложности только тогда, когда обнаружение изображений, видео или включение в Google News является значимым источником трафика.

Распространённые ошибки, которые вредят SEO

404-ошибки и редиректы в sitemap. Перечисление URL, возвращающих 404 или перенаправляющих на другой адрес, загрязняет sitemap шумом. Google помечает их в Search Console как ошибки sitemap и может обесценить остальную часть sitemap. Аудируйте sitemap при каждом деплое и удаляйте URL, возвращающие не 200. Редиректы следует заменять целевым URL.

Включение неканонических URL. Страницы с rel="canonical", указывающим на другой URL, не должны присутствовать в sitemap. Sitemap — это список страниц, которые вы хотите проиндексировать; страницы, у которых задан другой канонический URL, — это страницы, которые вы явно попросили поисковые системы игнорировать. Их включение создаёт противоречивые сигналы.

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

Sitemap заблокирован через robots.txt. Строка Disallow: /sitemap.xml или более широкое Disallow: /sitemap, попадающее под этот файл, не позволяет краулерам получить sitemap вообще. Всегда проверяйте с помощью curl или инструмента проверки sitemap после изменения robots.txt, чтобы убедиться в доступности URL sitemap.

Дочерние sitemap в sitemap-index, возвращающие 404. Sitemap-index, ссылающийся на десять дочерних sitemap, но девять из которых доступны, приводит к тому, что отсутствующий помечается как ошибка. Хуже того, если паттерн путей меняется между деплоями, каждый старый URL дочернего sitemap становится 404 до перегенерации индекса. Генерируйте индекс из того же источника данных, что и дочерние файлы, чтобы они оставались синхронизированными.

Смешивание протоколов внутри sitemap. Sitemap, опубликованный по адресу https://example.com/sitemap.xml, должен содержать только URL с https://. URL с http:// считаются другим хостом и игнорируются процессором sitemap канонического хоста. То же относится к несоответствию www и non-www: выберите один вариант и используйте его во всём sitemap.

Забытое экранирование специальных символов в URL. XML требует экранирования &, <, >, " и ' внутри значений атрибутов и элементов. URL с неэкранированными амперсандами ломают XML-парсер, и весь sitemap не проходит валидацию. Генерируйте URL через библиотеку, которая обрабатывает экранирование, а не конкатенируя строки вручную.

Граничные случаи, о которых редко говорят

Sitemap.xml, публикуемый с неверным Content-Type, ломает некоторые краулеры. Правильный Content-Type — application/xml или text/xml. Некоторые серверы возвращают text/plain или text/html для .xml-файлов, если MIME-тип не настроен, и в частности Bingbot известен тем, что отклоняет подобные ответы. Инструмент проверяет Content-Type и помечает его как предупреждение, когда он не соответствует ожидаемому.

Сжатые sitemap в формате .xml.gz существенно экономят трафик — sitemaps сжимаются до 5–10% от исходного размера благодаря многократному повторению URL-префиксов. Как Google, так и Bing принимают gzip-sitemap без дополнительной настройки, а ограничение на размер файла применяется к несжатому размеру. Единственный нюанс: некоторые хостинг-платформы отдают .gz-файлы с неверным Content-Encoding, из-за чего краулер получает сырые байты gzip, которые не удаётся разобрать. Проверьте сжатую версию в браузере: если вместо XML отображаются бинарные данные, в ответе отсутствует заголовок Content-Encoding: gzip.