Карта сайта (sitemap.xml)

Происхождение и история термина

2005 — Google Sitemaps. 2 июня 2005 года Google объявил о новом сервисе, который позволяет вебмастерам «automatically submit their web pages to Google» («автоматически отправлять свои страницы в Google»), и выложил открытый генератор XML-файлов Sitemap ^[18].

2006 — общий протокол. 15 ноября 2006 года Google сообщил, что Yahoo! и Microsoft присоединяются к поддержке протокола; номер версии подняли до 0.9, а развитие протокола перенесли на сайт sitemaps.org ^[19]. С тех пор пространство имён файлов — http://www.sitemaps.org/schemas/sitemap/0.9 ^[2], а сам протокол распространяется по лицензии Creative Commons Attribution-ShareAlike ^[1].

2007 — строка в robots.txt. 11 апреля 2007 года Google объявил, что протокол поддерживает и Ask.com, и что о файле можно сообщить строкой в robots.txt вида Sitemap: http://www.mysite.com/sitemap.xml с полным URL ^[20]. Способ действует и сейчас ^[2].

2009 — научная оценка. Исследователи UCLA и Google У. Шонфельд и Н. Шивакумар на конференции WWW 2009 сравнили обнаружение страниц по ссылкам и через Sitemaps. По данным Google на октябрь 2008 года, файлы Sitemap публиковали около 35 млн сайтов; вывод работы — Sitemaps и обычный обход по ссылкам «complement each other very well» («хорошо дополняют друг друга») ^[21]. Эти цифры — исторические и не описывают текущую картину.

2016 — последняя редакция текста протокола. Страница протокола на sitemaps.org последний раз обновлялась 21 ноября 2016 года ^[2].

2022 — «весенняя уборка» расширений. 6 мая 2022 года Google опубликовал пост «Spring cleaning: some sitemap extension tags are going away» ^[23]. По изложению Search Engine Journal, из расширения для изображений выведены теги image:caption, image:geo_location, image:title и image:license, из видеорасширения — в том числе video:category, video:gallery_loc, video:price и video:tvshow; после 6 августа 2022 года эти теги перестали на что-либо влиять, а их наличие в файле не наказывается ^[24]. В текущей документации Google по изображениям эти теги перечислены как удалённые, со ссылкой на это объявление ^[7].

2022 — RFC 9309. Стандарт IETF для robots.txt (сентябрь 2022) не включил строку Sitemap: в число своих правил: в п. 2.2.4 Sitemaps приведены как пример «других записей», которые краулеры могут интерпретировать, при условии что разбор таких записей не мешает разбору основных правил ^[17]. Поэтому строку Sitemap: корректно описывать как часть протокола sitemaps.org, а не как директиву стандарта RFC.

2023 — отказ от ping. В июне 2023 года Google объявил, что адрес «ping» для отправки файлов Sitemap HTTP-запросом перестаёт работать ^[25]. По сообщению Search Engine Land, речь шла о предусмотренном протоколом способе отправки без аутентификации («unauthenticated REST method»); к концу 2023 года такие запросы должны были начать возвращать ошибку 404, а Google объяснил решение тем, что большинство таких отправок оказывалось спамом ^[22].

2025 — Sitemap и поиск с ИИ. В июле 2025 года Bing назвал поле lastmod «key signal» для приоритизации повторного сканирования и рекомендовал сочетать Sitemap с протоколом IndexNow ^[16].

В русскоязычной практике закрепились названия «карта сайта» и «файл Sitemap»; именно «файл Sitemap» и раздел «Файлы Sitemap» используются в Справке Яндекс Вебмастера ^[11], ^[12].

Суть и механизм

Место Sitemap в работе поисковика

Поисковая система узнаёт о страницах из разных каналов. Google пишет, что Sitemap помогает поисковикам находить URL, но «it doesn't guarantee that all the items in your sitemap will be crawled and indexed» («не гарантирует, что все элементы будут просканированы и проиндексированы») ^[4]. Саму отправку файла Google называет «merely a hint» — лишь подсказкой ^[5]. Яндекс перечисляет Sitemap среди способов сообщить роботу о страницах наряду с переобходом в Вебмастере, обходом страниц со счётчиком Метрики и протоколом IndexNow ^[15] и предупреждает: «Яндекс не гарантирует, что все указанные в файле URL попадут в результаты поиска»; кроме того, сами «файлы Sitemap не участвуют в поиске» ^[11].

Иначе говоря, Sitemap влияет на обнаружение адресов; очередь обхода разобрана в статье «Сканирование (краулинг)», дальнейшая судьба страницы — в статье «Индексация».

Минимальный файл

Обязательны только три элемента: корневой urlset, запись url и адрес loc ^[2]. Пример по образцу документации Google ^[5]:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/foo.html</loc>
    <lastmod>2022-06-04</lastmod>
  </url>
</urlset>

Адрес в loc указывается полностью, с протоколом: Google требует «fully-qualified, absolute URLs» и сканирует их ровно в том виде, в каком они записаны ^[5].

Теги и как их учитывают поисковики

Расхождение по priority реальное: Google и Bing этот тег не используют, а Справка Яндекса описывает его учёт при очерёдности загрузки страниц. О влиянии priority на ранжирование не пишет ни один из этих источников, а протокол прямо говорит, что значение «does not imply any effect on the ranking» ^[3].

Технические требования и лимиты

Две оговорки к таблице. Первая — о сжатии: протокол считает лимит 50 МБ для файла «once uncompressed», то есть после распаковки ^[2], а FAQ того же сайта формулирует иначе — не больше 50 МБ «whether compressed or not» ^[3]; в таблице правило дано по тексту протокола. Справка Яндекса указывает лимит для файла «в несжатом виде», но поддержку gzip прямо не описывает ^[11]. Вторая — о длине адреса: страница Справки Яндекса о файле Sitemap ^[11] и справочник ошибок ^[14] расходятся (2048 и 1024 символа). Безопаснее держать адреса не длиннее 1024 символов (вывод).

Где размещать и как называть

По протоколу файл может перечислять только адреса в своём каталоге и ниже: файл из /catalog/ не может содержать URL из /images/; все URL должны иметь тот же протокол и хост, что и файл; размещать файл настоятельно рекомендуется в корне сайта ^[2]; то же советует FAQ протокола ^[3]. Google допускает любое место, но без отправки через Search Console файл действует только на свой каталог и вложенные ^[5].

Отправлять файлы для нескольких сайтов Google разрешает двумя способами ^[5]. Если права на все сайты подтверждены в Search Console, можно отправить там один или несколько файлов (или индекс) с адресами всех этих сайтов. Без Search Console файлы разных сайтов можно хранить в одном месте, которым управляет владелец (в примере Google — https://sitemaps.example.com), но у каждого сайта должен быть свой файл только с его URL, а robots.txt каждого сайта — ссылаться на этот файл. Яндекс требует указывать ссылки «только того домена, на котором будет расположен файл» ^[11].

Имя sitemap.xml — устойчивое соглашение, а не требование: поисковику передают полный адрес файла, текстовый вариант протокол разрешает называть как угодно ^[2], а Google — любым именем с расширением .txt ^[5].

Индекс Sitemap

Когда адресов больше 50 000 или файл больше 50 МБ, нужен файл индекса ^[3]. Его корень — sitemapindex, внутри — записи sitemap с обязательным loc и необязательным lastmod ^[2]. Файлы, перечисленные в индексе, должны лежать в том же каталоге, что и индекс, или глубже ^[6]. Пример по образцу Google ^[6]:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap1.xml.gz</loc>
    <lastmod>2024-08-15</lastmod>
  </sitemap>
</sitemapindex>

Яндекс обрабатывает каждый файл, в том числе вложенный в индекс, отдельно ^[12].

Форматы

Расширения

Протокол допускает дополнительные пространства имён. Google документирует несколько расширений:

• Изображения — пространство имён http://www.google.com/schemas/sitemap-image/1.1, теги image:image и image:loc; в одной записи url — до 1000 изображений ^[7].
• Новости — пространство имён http://www.google.com/schemas/sitemap-news/0.9; включаются только статьи, созданные за последние два дня; в одном файле до 1000 тегов news:news; обязательны news:publication с news:name и news:language, а также news:publication_date и news:title ^[8].
• Видео — Google упоминает, что запись о видео может содержать длительность, рейтинг и возрастную пригодность ролика ^[4]; часть видеотегов выведена из употребления в 2022 году ^[24].
• Языковые версии — элементы xhtml:link rel="alternate" hreflang="…"; каждая запись url перечисляет все версии страницы, включая саму себя; дочерние элементы не учитываются в лимите URL ^[9].

Фрагмент с языковыми версиями по образцу Google (сокращён до двух версий) ^[9]:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.example.com/english/page.html</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://www.example.com/english/page.html"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://www.example.de/deutsch/page.html"/>
  </url>
</urlset>

Справка Яндекса сообщает, что через Sitemap можно передать сведения о локализованных страницах и об изображениях, и отсылает за подробностями об изображениях к справке Яндекс Картинок ^[11]. Элементы, которые Яндекс не поддерживает, он игнорирует с пометкой «Неизвестный тег», а поддерживаемые данные учитывает ^[12]. Правила Google нельзя автоматически переносить на Яндекс.

Виды и классификации

По формату (классификация Google): XML; RSS, mRSS и Atom 1.0; текстовый файл ^[5]. Яндекс принимает два формата — XML и TXT ^[11].

По роли файла (протокол sitemaps.org): обычный файл Sitemap со списком страниц (urlset) и файл индекса Sitemap со списком других файлов (sitemapindex) ^[2].

По типу содержимого (расширения Google): страницы, изображения, видео, новости, локализованные версии ^[5], ^[7], ^[8], ^[9].

По способу создания:

1. Ручной статический файл — для небольших сайтов, которые редко меняются.
2. Автоматическая генерация средствами CMS: Google отмечает, что WordPress, Wix или Blogger, скорее всего, уже создают файл сами ^[4].
3. Генерация скриптом или серверной частью сайта при публикации и удалении страниц.
4. Внешние генераторы, которые обходят сайт по ссылкам и собирают найденные адреса.

HTML-карта сайта — другое понятие: обычная веб-страница со ссылками на разделы для посетителей. Протокол Sitemaps и рекомендации поисковиков, приведённые в этой статье, относятся только к машиночитаемым файлам.

Как применяется на практике

Кому нужен Sitemap

Что включать и что не включать

Google рекомендует включать канонические URL, которые владелец хочет видеть в результатах поиска ^[5]. Яндекс советует до создания файла определить канонические адреса страниц, особенно если похожие страницы дублируют друг друга ^[11]. Из официальных требований следуют практические правила (вывод):

• включать: канонические адреса страниц, открытых для индексации и отвечающих кодом 200;
• не включать: адреса с перенаправлением, с ответами 4xx и 5xx, закрытые в robots.txt или метатегом noindex, дубли с параметрами сортировки и фильтров, неканонические варианты.

Убрать страницу из поиска с помощью Sitemap нельзя: для этого протокол отсылает к robots.txt и метатегу robots ^[2]. Подробности — в статьях «robots.txt», «Мета-тег robots» и «Канонический адрес (canonical)».

Как сообщить поисковику о файле

Строка в robots.txt выглядит так:

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

По протоколу в ней указывается полный URL; строка не зависит от групп User-agent, таких строк может быть несколько, а при использовании индекса достаточно указать только его ^[2]. Синтаксис остальных правил robots.txt разобран в статье «robots.txt».

Как поддерживать файл

• Генерировать автоматически, чтобы новые страницы попадали в файл, а удалённые исчезали (рекомендация).
• Ставить честный lastmod — дату реального изменения страницы (см. таблицу тегов).
• Делить большие сайты на несколько файлов и собирать их в индекс ^[3], ^[6]. Деление по типам страниц — рекомендация, а не требование поисковиков.
• Не удалять и не загружать заново изменённый файл в Яндекс Вебмастере: робот регулярно проверяет его сам. Для ускорения есть кнопка обновления — до 10 раз для одного хоста, после чего следующая попытка появится через 30 дней после первой; ускоренная обработка занимает три дня ^[12].
• Сочетать Sitemap и IndexNow там, где это поддерживается: так советует Bing ^[16], а Яндекс указывает IndexNow среди способов сообщить роботу об изменениях ^[15]. Google в этих источниках как участник IndexNow не упоминается.

Типовые сценарии (условные примеры)

1. Интернет-магазин. Генератор, обходящий сайт по ссылкам, добавляет в Sitemap адреса фильтров и сортировок. Файл разрастается за счёт неканонических дублей, которые противоречат рекомендации включать канонические URL ^[5], ^[11].
2. Новостной сайт. Редакция ведёт отдельный новостной Sitemap для Google. В нём должны быть только статьи за последние два дня; более старые адреса или их метаданные news:news нужно убирать ^[8].
3. Переезд на HTTPS. После переезда в Sitemap остаются адреса http://. Яндекс в таком случае рекомендует проверить совпадение протокола и префикса www ^[11]; в Вебмастере файл, который сам отдаёт перенаправление, получает статус «Редирект» ^[12]. Подробнее — в статьях «HTTPS и SSL-сертификат» и «301-редирект».

Как измерить или проверить

Яндекс Вебмастер

В разделе «Индексирование → Файлы Sitemap» у каждого файла есть статус ^[12]:

Обработка занимает до двух недель, для индекса может затянуться; после удаления файла сведения исчезают из базы в течение нескольких недель ^[12]. Инструмент «Анализ файлов Sitemap» проверяет файл по тексту, загруженному файлу или ссылке ^[13]. Справочник ошибок Яндекса, среди прочего, перечисляет: файл больше 50 МБ, больше 50 000 URL, длина URL больше «установленного предела (1024 символа)», некорректный URL, не соответствующий расположению файла, невалидный XML; неверная дата в lastmod отнесена к предупреждениям; обработка прекращается, если в файле больше 100 ошибок ^[14]. Предел в 1024 символа расходится со значением 2048 на странице Справки о файле Sitemap ^[11].

Google Search Console

Отчёт «Файлы Sitemap» показывает статусы «Успешно», «Обнаружены проблемы» и «Не получено» ^[10]. Число выявленных страниц — это количество URL в файле, а не просканированных или проиндексированных. В отчёте видны только файлы, отправленные через сам отчёт или API, — найденные через robots.txt там не показываются; хранится не более 1000 отправок. Сколько URL из файла проиндексировано, показывает отчёт об индексировании страниц с фильтром по файлу Sitemap ^[10].

Bing Webmaster Tools

Bing советует отслеживать статус отправки, дату последнего чтения файла и ошибки обработки, которые могут мешать индексированию ^[16].

Рабочие показатели (не официальные метрики)

• Доля проиндексированных URL из Sitemap = проиндексировано / отправлено в файле × 100 % (по отчёту об индексировании, отфильтрованному по файлу Sitemap ^[10]).
• Доля «мусорных» URL = URL с ответом не 200, с перенаправлением, с noindex или неканонические / всего URL в файле × 100 %.

Мини-инструмент «Проверка и генератор sitemap.xml»

Инструмент работает в браузере; каждое его правило подписано источником — протокол, Google или Яндекс.

Режим «Проверка». Вставьте текст XML или загрузите файл. Инструмент проверяет:

• корректность XML, корень urlset или sitemapindex и пространство имён sitemaps.org ^[2];
• наличие loc и абсолютные адреса ^[2], ^[5]; единый протокол и хост ^[2], ^[11];
• лимиты: 50 000 URL или файлов в индексе, 52 428 800 байт ^[2], ^[11]; длина адреса — ошибка от 2048 символов (протокол ^[2]) и предупреждение от 1025 символов с пометкой «по справочнику ошибок Яндекса» ^[14];
• формат lastmod (W3C Datetime) ^[2], с предупреждением, если у всех URL одна дата или дата в будущем;
• диапазон priority и значения changefreq ^[2] с пометкой о разном учёте у Google, Bing и Яндекса ^[5], ^[11], ^[16];
• дубли, неэкранированные символы ^[2] и адреса с параметрами сортировки или сессий (стоит проверить каноничность);
• структуру image:image (до 1000 на URL) и xhtml:link ^[7], ^[9].

Итог — сводка «ошибки / предупреждения / информация». Ошибкой считается только нарушение протокола; правила одного поисковика показываются как предупреждения.

Режим «Генератор». Из списка адресов (по одному в строке) инструмент собирает sitemap.xml или TXT-файл, по желанию с одной датой lastmod (с напоминанием, что она должна отражать реальное изменение), при числе адресов больше 50 000 — несколько файлов и индекс, а также строку для robots.txt.

Чего инструмент не делает: не проверяет, проиндексированы ли адреса; не обходит сайт и не проверяет код ответа каждого URL; не отправляет файл в поисковые системы. Для проверки файла по ссылке используйте «Анализ файлов Sitemap» в Яндекс Вебмастере ^[13] и отчёт «Файлы Sitemap» в Search Console ^[10].

Как пользоваться (пример условный). В файле из 1200 адресов ошибок нет; предупреждения — одинаковый lastmod, равный дате генерации, и 40 адресов с ?sort=. Владелец исправляет lastmod, проверяет каноничность страниц с сортировкой и заново отправляет файл.

Ошибки, ограничения и спорные вопросы

Мифы «Sitemap = индексация» и «Sitemap поднимает позиции». Отправка файла — лишь подсказка, сканирование и индексирование не гарантированы ^[4], ^[5], ^[11]; файлы Sitemap не участвуют в поиске ^[11], а priority не влияет на ранжирование ^[3].

Миф «priority и changefreq управляют роботом». Google и Bing эти теги игнорируют ^[5], ^[16]; Яндекс описывает учёт priority при очерёдности загрузки ^[11]. Это различие реализаций, а не научный спор.

Одинаковый lastmod у всех страниц. Если в поле стоит дата генерации файла, это противоречит протоколу ^[2]. Google в таком случае просто не будет опираться на поле: он учитывает lastmod, только если тот стабильно и проверяемо точен ^[5].

Конфликт сигналов. В файле есть адреса, закрытые в robots.txt, с noindex, неканонические или отдающие перенаправление и 404. Отдельный случай — сам файл закрыт правилом Disallow: в Вебмастере он получит статус «Запрет в robots.txt» ^[12].

Несовпадение протокола и хоста. http вместо https, www вместо адреса без www: протокол требует одинаковых протокола и хоста ^[2], а Яндекс называет проверку этого совпадения первым шагом, если файл не обрабатывается ^[11].

Технические сбои: превышение лимитов, кодировка не UTF-8, неэкранированный & в адресах с параметрами (протокол требует экранировать этот символ ^[2]). В справочнике ошибок Яндекса есть, например, «Невалидный XML», превышение размера файла и числа URL, ошибка префикса UTF-8 ^[14].

Устаревшие практики. Ping-запросы к Google из старых плагинов, по сообщению Search Engine Land со ссылкой на Google, не создают проблем для поиска, а сами запросы должны возвращать ошибку 404 ^[22]. Устарели и теги изображений и видео, выведенные из употребления в 2022 году ^[7], ^[24]. Новостной Sitemap со статьями старше двух дней нарушает правила Google ^[8].

Ограничения. Sitemap не заменяет внутреннюю перелинковку: Google называет хорошо перелинкованные сайты случаем, когда файл может не понадобиться ^[4], а исследование 2009 года описывает Sitemaps и обход по ссылкам как взаимодополняющие способы ^[21]. Удаление файла не удаляет страницы из индекса: Google помнит и файл, и его URL ^[10].

Спорное: нужен ли файл маленькому сайту. Google допускает, что сайту примерно до 500 страниц файл может быть не нужен, но тут же пишет, что в большинстве случаев он полезен ^[4]. Переносить этот порог на Яндекс нельзя: в его Справке такого порога нет ^[11].

Частые вопросы

Связанные термины

• robots.txt
• Сканирование (краулинг)
• Индексация
• Канонический адрес (canonical)
• Краулинговый бюджет
• Яндекс Вебмастер
• Google Search Console
• hreflang
• Страницы-сироты
• Структура сайта