sitemap.xml: зачем нужна карта сайта и как ее не сломать

Что карта сайта дает поиску и чего не дает

sitemap.xml - список адресов сайта в машиночитаемом виде. Файл лежит по адресу вида `https://example.com/sitemap.xml` и отвечает роботу на единственный вопрос: какие страницы у сайта есть.

Карта ускоряет обнаружение. Робот берет адрес из файла, а не выходит на страницу по ссылкам, поэтому новый материал попадает в очередь на обход быстрее. Боты нейросетей читают тот же файл: Perplexity, например, ходит по сайту в момент запроса и список адресов берет оттуда же.

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

Позиции карта тоже не двигает. Оценивать в файле нечего: там нет ни текста, ни входящих ссылок.

Кому карта не нужна

Сайт на тридцать страниц, где от главной до каждой из них два клика, обходится без карты. Робот найдет все по ссылкам за один обход. Файл в такой ситуации не вредит, но и пользы от него ждать не стоит: если страницы не индексируются, причина лежит в другом месте.

В выдаче по запросу про карту сайта все статьи написаны в логике «нужна всем». Тридцать страниц в эту логику не укладываются.

Кому нужна

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

Как устроен файл: обязательное и необязательное

Минимальный рабочий файл выглядит так.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/blog/statya</loc>
    <lastmod>2026-08-22</lastmod>
  </url>
</urlset>

Обязательных тегов три: контейнер `urlset`, запись `url` и адрес `loc` внутри нее. Дата изменения `lastmod` помечена в протоколе как необязательная, хотя из всех дополнительных тегов смысл есть только у нее.

Требования протокола:

• до 50 000 адресов и до 50 МБ на файл в распакованном виде, сжатие gzip разрешено
• кодировка UTF-8, служебные символы в адресах экранируются
• адреса пишутся целиком, с протоколом и доменом: `https://example.com/page`, а не `/page`
• один протокол и один домен на файл. Если сайт работает на https, адресов с http в карте быть не должно
• файл охватывает свой уровень и все, что ниже. Карта в корне описывает сайт целиком, карта в папке `/blog/` - только адреса блога

Имя файла жестко не задано. `sitemap.xml` в корне - соглашение, а не требование протокола: карта может называться иначе и лежать в папке, если на нее указывает строка в robots.txt или ее адрес добавлен в панели вебмастеров.

XML не единственный формат. Поиск принимает текстовый список: файл `sitemap.txt`, один адрес в строке, ничего больше. Принимает ленты RSS и Atom - для блога это рабочий вариант, хотя лента отдает не все страницы, а последние записи.

Что держать в карте: адреса, которые вы хотите видеть в выдаче. Отвечающие кодом 200, открытые для обхода, с каноническим тегом на самих себя. Страницы благодарности, результаты внутреннего поиска и прочие служебные адреса в файл не идут.

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

Какие теги поиск читает, а какие игнорирует

Протокол разрешает внутри записи четыре тега: адрес, дату изменения, частоту обновления и приоритет. На поведение поиска влияют два первых.

Приоритет и частота обновления

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

Совет «поставьте главной приоритет 1.0, а карточкам 0.5» кочует по статьям с начала десятых и до сих пор попадает в заголовки топа. Измеримого результата от него нет. Если генератор проставляет эти теги сам, пусть проставляет: вреда от них нет. Тратить на них время не надо.

Дата изменения

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

Формат - W3C Datetime: либо `2026-08-22`, либо с указанием времени и часового пояса `2026-08-22T07:27:47+00:00`.

Дата, которая врет

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

Главный источник вранья - массовая пересборка. Генератор собирает файл заново и ставит всем адресам текущее время, хотя правился один материал.

Как это выглядит, видно на карте сайта, который вы читаете. Семнадцатого августа 2026 года почти все страницы «изменились» за неполные три минуты: 07:27:47, 07:27:49, 07:27:50 и дальше подряд до 07:30:26. Двадцатого августа то же самое повторилось на десяти статьях одного кластера, с 18:55:20 по 18:55:51. Десять статей не правятся одновременно за тридцать одну секунду.

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

Карта как датчик: три числа, которые стоит сверять

Карту почти не используют как диагностику, хотя дешевле инструмента на сайте нет. Смотреть надо на три числа.

• Сколько адресов в файле. Открыть карту в браузере и посчитать записи. На больших сайтах список проще выгрузить
• Сколько адресов обнаружено. Google Search Console (GSC), отчет по файлам Sitemap, столбец с числом обнаруженных адресов. В Яндекс Вебмастере то же самое лежит в разделе «Индексирование»
• Сколько адресов в индексе. Отчет по страницам в GSC, отфильтрованный по файлу карты

Что видно	Что это значит	Куда идти
В файле больше, чем обнаружено	Файл прочитан не целиком: ошибка формата, обрыв на середине, часть адресов недоступна роботу	Статус обработки в отчете, затем прогон адресов краулером
Обнаружено, но не в индексе	Карта отработала, вопрос не к ней: качество страниц, дубли, запрет на обход	Отчет по страницам в GSC и разбор статусов
В индексе больше, чем в файле	В поиск попало то, чего в карте нет: служебные адреса, версии с параметрами, дубли	Список проиндексированных адресов, сверка со списком из карты

Расхождение в пару процентов - норма, файл читается не мгновенно. Разрыв в треть означает, что отчеты Google Search Console надо открывать сегодня, а не в конце квартала. Третья строка таблицы выводит на дубли.

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

Типовая история: после переезда на новую версию сайта в карту попали адреса старой структуры. Файл читается, ошибок в отчете нет, обнаруженных адресов вдвое меньше заявленных. Через месяц половина страниц выпадает из поиска. К этому моменту причину ищут в текстах.

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

Как отдать карту поиску

Способа два, и делать стоит оба.

Строка в robots.txt

В robots.txt добавляется строка с абсолютным адресом карты.

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

Строка не привязана к блоку `User-agent` и стоит в любом месте файла. Если карт несколько, строк будет столько же. Этот способ читают все краулеры, которые заходят на сайт, включая те, у которых панели вебмастеров нет. Остальные директивы файла разобраны в статье про настройку robots.txt.

Панели вебмастеров

В Google Search Console адрес добавляется в отчете по файлам Sitemap, в Яндекс Вебмастере - в разделе «Индексирование». Панель, в отличие от строки в robots.txt, отвечает: когда файл прочитан, сколько адресов из него найдено, где ошибка.

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

Статус после отправки бывает трех видов: файл прочитан успешно, прочитан с ошибками, не получен вовсе. Последний вариант означает, что робот до файла не дошел: адрес отдает ошибку, закрыт от обхода или отвечает слишком долго. В первые сутки статус может оставаться пустым, это нормально.

Чего делать не надо

Пинговать поиск запросом на адрес вида `google.com/ping?sitemap=...`. Google свернул этот способ в 2023 году, запрос возвращает 404. Инструкция, которая до сих пор предлагает пингануть карту, устарела целиком, и остальные советы из нее стоит перепроверить.

Ускорить обход можно протоколом IndexNow: одна отправка расходится по Яндексу, Bing и остальным участникам, Google среди них нет.

Большие сайты: разбивка и индексный файл

В один файл влезает 50 000 адресов и 50 МБ. Каталог, который в эти рамки не помещается, режется на несколько карт, а поиску отдается индексный файл - список этих карт.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-tovary-1.xml</loc>
    <lastmod>2026-08-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-kategorii.xml</loc>
    <lastmod>2026-08-21</lastmod>
  </sitemap>
</sitemapindex>

Адресов страниц в индексном файле нет, только ссылки на карты и даты их изменения. Вложенность одноуровневая: индексный файл не может ссылаться на другой индексный.

Резать стоит по типам страниц: карточки отдельно, категории отдельно, статьи отдельно. Тогда отчет по каждому файлу читается как диагностика раздела. Скажем, из карты категорий обнаружено 90% адресов, из карты карточек - 40%, и уже понятно, где искать. При нарезке по алфавиту или по порядку выгрузки эта информация теряется: расхождение размазывается по всем файлам поровну и ни на что не указывает.

Пять ошибок, из-за которых карта работает против сайта

Каждый адрес в файле - заявка на обход. Заявки, ведущие в никуда, тратят время робота и снижают доверие к самому файлу.

1. Адреса, отдающие редирект

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

2. Адреса, закрытые в robots.txt

Сайт одновременно говорит «обойди эту страницу» и «сюда нельзя». Робот подчинится запрету, а запись в карте останется противоречием, которое видно в отчете как ошибка. Найти можно сверкой списка из карты с правилами robots.txt.

3. Адреса с каноническим тегом на другую страницу

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

4. Несуществующие страницы

Материал удален, адрес отдает 404, запись в файле осталась. Накапливается это годами, особенно когда карта собиралась руками или генератор давно не обновлялся. Ловится по кодам ответа в отчете краулера, а предупреждается привычкой: страница снимается с публикации и в тот же день уходит из карты.

5. Одинаковая дата изменения у всех адресов

Все адреса в файле помечены одним временем. Поиск сверяет даты с содержимым, подтверждения не находит и перестает верить тегу.

Найти все пять разом можно одним прогоном: выгрузить адреса из карты и пропустить их в режиме списка через краулер - Screaming Frog, Netpeak Spider или любой аналог. В отчете сразу видны коды ответа, канонические теги и запреты. Часть ошибок Яндекс Вебмастер показывает сам, в разделе с файлами Sitemap.

Карта сайта на конструкторе

Tilda, Wix, Webflow, Framer и Squarespace собирают карту сами. Файл отдается по стандартному адресу, состав определяется по опубликованным страницам, доступа к нему у вас нет. Разберу на Тильде: сайт, который вы читаете, собран на ней.

Файлов там бывает до трех:

• `/sitemap.xml` - обычные страницы сайта
• `/sitemap-feeds.xml` - посты из модуля «Потоки», если блог собран на нем
• `/sitemap-store.xml` - карточки товаров из «Каталога»

В панели вебмастеров каждый файл добавляется отдельно. Если блог собран на «Потоках», магазин на «Каталоге», а в GSC отправлен только основной файл, остальные страницы поиск ищет сам.

Отдельная история с `/sitemap-feeds.xml`: он прописан в robots.txt даже у сайтов без «Потоков» и отдает в этом случае 404. Ошибка старая и косметическая, поиск от нее не страдает, но в отчете она висит красным и мешает читать остальное. Правкой файла это не лечится: robots.txt на Тильде не редактируется. Убрать строку можно только вместе с модулем - «Настройки сайта» → «Еще» → «Подключаемые модули», кнопка «Удалить потоки и отключить модуль», дальше сохранить и опубликовать страницы заново. Если «Потоки» когда-нибудь понадобятся, проще оставить ошибку висеть.

Под контролем остаются три вещи:

• состав страниц. Опубликованные попадают в карту, черновики - нет
• запрет индексации. Настройки страницы, вкладка SEO, галочка «Запретить поисковикам индексировать эту страницу» - закрытый адрес из файла исчезает. Для поста «Потоков» то же самое делается в его карточке
• перелинковка между страницами. На конструкторе она весит больше, чем на самописном сайте, потому что подкрутить карту нельзя

Вне контроля - даты. Генератор ставит их по моменту сборки, и после любой массовой операции весь сайт выглядит обновленным. Пример из раздела про `lastmod` снят как раз отсюда.

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

Если содержимое файла нужно контролировать, обходной путь один. Положить свою карту по адресу, до которого у вас есть доступ, и отдать этот адрес в панели вебмастеров. Поиск не требует, чтобы файл назывался sitemap.xml и лежал в корне. Условие одно: файл доступен и охватывает адреса того же домена. На Тильде добавить строку в robots.txt при этом не выйдет, останется только путь через панели, а автоматическая карта будет лежать рядом с вашей.

Что проверить в своей карте за десять минут

• Открыть `https://ваш-домен/sitemap.xml`. Файл отдается, внутри - адреса нужного домена и протокола
• Сравнить число записей с числом страниц, которым место в выдаче. Если разница вдвое, разбираться надо в тот же день
• Посмотреть на даты. Если они идут подряд с шагом в секунду, тег не работает и сигнал свежести надо давать на самой странице
• Найти строку Sitemap в robots.txt
• Проверить, один ли у сайта файл карты. На конструкторе их бывает два-три, а в панель добавляют первый и забывают про остальные
• Открыть отчет по файлам Sitemap в обеих панелях: статус, дата обработки, число обнаруженных адресов
• Записать три числа: в файле, обнаружено, в индексе. Вернуться к ним через месяц

Один пункт не сошелся - работа на полчаса. Если не сходится половина списка, проблема шире карты, и начинать надо с технической проверки сайта целиком.

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

Нужна ли карта сайта маленькому сайту?

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

Чем sitemap.xml отличается от HTML-карты сайта для посетителей?

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

Как часто нужно обновлять файл?

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

Обязательно ли указывать карту в robots.txt?

Формально нет: карту, добавленную в панели вебмастеров, поиск найдет и без строки в robots.txt. На практике - да, стоит. Строку прочитает любой краулер, а панели есть не у всех поисковых систем и не у всех ботов нейросетей.

Ускорит ли карта попадание новых страниц в индекс?

Ускорит обнаружение адреса, но не решение включить его в индекс. Страница из карты быстрее встанет в очередь на обход. Дальше поиск оценивает ее по своим правилам и может не взять вовсе.

Что делать, если поиск пишет, что не может прочитать файл?

Сначала открыть адрес карты в браузере в режиме инкогнито: часто файл отдает 404 или редирект. Затем проверить, не закрыт ли этот адрес в robots.txt. Дальше смотреть на размер и формат: обрыв файла на середине, лишние символы перед объявлением XML, кодировка не UTF-8. Если файл открывается и валиден, а статус не меняется вторые сутки, стоит отправить его повторно: обработка не мгновенная.