Коротко. Sitemap.xml — это машиночитаемый список канонических URL сайта в формате протокола sitemaps.org. Он подсказывает роботу, что обойти, но не гарантирует индексацию и не является фактором ранжирования. Один файл вмещает до 50 000 URL и 50 МБ в несжатом виде, дальше нужен sitemap index. Теги changefreq и priority поисковики де-факто игнорируют, lastmod учитывается только тогда, когда датам можно верить.
Что такое sitemap.xml и кому он реально нужен
XML-карта сайта — обычный текстовый файл в кодировке UTF-8, который перечисляет адреса страниц по единой схеме, описанной в протоколе sitemaps.org версии 0.9. Формат не менялся с 2005 года и одинаково понимается Google, Яндексом, Bing и остальными краулерами: это один из немногих действительно универсальных стандартов в SEO.
Базовый способ обнаружения страниц у робота — переход по ссылкам. Он берёт известный URL, скачивает HTML, вытаскивает все href и ставит найденное в очередь. Sitemap — второй, независимый канал обнаружения: список адресов, который не требует, чтобы до страницы существовал путь по ссылкам.
Отсюда следует, кому карта сайта даёт заметный эффект:
- Крупные каталоги и магазины. Десятки и сотни тысяч URL, глубокая вложенность, часть карточек доступна только через фильтры и пагинацию — робот физически не дойдёт до всего за разумное число обходов.
- Новые сайты без внешних ссылок. Обнаруживать нечего: внешних сигналов нет, внутренняя перелинковка ещё пустая.
- Сайты со слабой внутренней структурой. Разделы, на которые не ведёт ни одна ссылка из меню и листингов — «сироты» в терминах технического аудита.
- Медиа и новостные проекты. Контент устаревает за часы, скорость обнаружения важнее всего остального.
- Мультиязычные проекты. Разметку hreflang удобнее вести в sitemap, чем править в
<head>каждой страницы.
И кому она почти бесполезна: сайту на 30–80 страниц, где всё связано сквозным меню и хлебными крошками. Такой сайт робот обходит целиком за один заход. Файл не навредит, но и не решит ни одной проблемы — если страницы не в индексе, причина в другом, и разбирать её надо по сценарию из материала почему сайта нет в поиске.
Что sitemap делает и чего он НЕ делает
Это самая частая точка заблуждений, поэтому разберём прямо.
Что sitemap действительно делает
- Сообщает роботу список адресов. Один запрос — тысячи URL, вместо обхода по цепочке ссылок.
- Передаёт дату изменения — если вы её честно проставляете. Это позволяет роботу приоритизировать перечитывание изменившегося.
- Ускоряет обнаружение новых и глубоко лежащих страниц. Обнаружение — не индексация, но без него индексации не будет вовсе.
- Даёт диагностику. В панелях вебмастеров видно «отправлено» против «проиндексировано» по каждому файлу. Это единственный простой способ померить, какая доля вашего контента реально попала в индекс.
Чего sitemap не делает
- Не гарантирует индексацию. Наличие URL в файле — приглашение, а не обязательство. Робот сам решает, обходить ли и стоит ли страница места в индексе.
- Не влияет на ранжирование. Ни один тег протокола не является фактором ранжирования.
priority— приоритет внутри вашего сайта для очереди обхода, а не «вес» страницы в выдаче. - Не отменяет robots.txt и noindex. Если URL закрыт от обхода в robots.txt или помечен
noindex, включение в sitemap ничего не изменит — только создаст конфликт сигналов. - Не заменяет внутреннюю перелинковку. Ссылочная структура передаёт вес и объясняет иерархию; sitemap не делает ни того, ни другого.
- Не чинит дубли. За выбор канонической версии отвечает
rel="canonical"и настройки хоста, а не карта сайта. - Не переиндексирует по требованию. Отправка файла не запускает немедленный обход всех URL.
Правило. Sitemap — подсказка к обходу. Если страница плохая, дублирующая или технически недоступная, попадание в sitemap не улучшит её судьбу. Наоборот: массовое добавление мусора размывает сигнал и портит собственную диагностику — вы перестанете понимать, что именно у вас не индексируется.
Структура sitemap.xml: urlset, url, loc, lastmod, changefreq, priority
Минимально корректный файл выглядит так:
<?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-07-14</lastmod>
</url>
<url>
<loc>https://example.com/catalog/okna/</loc>
<lastmod>2026-06-28T11:20:00+03:00</lastmod>
</url>
<url>
<loc>https://example.com/about/</loc>
</url>
</urlset>Здесь важны четыре вещи. Первая — XML-декларация в самой первой строке, без пробелов и пустых строк перед ней. Вторая — атрибут xmlns у корневого элемента: это идентификатор пространства имён, а не адрес, по которому что-то скачивается, поэтому переписывать его на https:// нельзя — файл перестанет распознаваться как sitemap. Третья — внутри одного <url> ровно один <loc>. Четвёртая — необязательные теги можно просто не выводить, как в третьей записи выше.
Как теги учитываются на самом деле
| Тег | Обязателен | Как реально учитывается | Типовая ошибка |
|---|---|---|---|
<urlset> | Да | Корневой элемент. Без правильного namespace документ не будет распознан как карта сайта | Namespace потерян, переписан на https или заменён «похожим» — файл читается как произвольный XML |
<url> | Да | Контейнер одной записи. Ровно один <loc> внутри | Два <loc> в одной записи или запись без <loc> вовсе |
<loc> | Да | Единственное, что читают все поисковики без исключений. Абсолютный URL той же схемы и того же хоста, что и сам файл | http-адрес на https-сайте, относительный путь, неэкранированный &, кириллица без percent-encoding |
<lastmod> | Нет | Учитывается, только если датам можно доверять. Google явно оговаривает: значение используется, когда оно последовательно и проверяемо точное. В индексном файле — самый полезный тег: показывает, какой из файлов имеет смысл перечитать | Подставляется время генерации файла, а не дата изменения контента — и весь сайт «обновляется» каждую ночь |
<changefreq> | Нет | Google игнорирует полностью. Остальные краулеры — в лучшем случае как очень слабую подсказку. Реальную частоту обхода определяет поведение сайта, а не декларация | daily у всех страниц «чтобы чаще заходили» — сигнал обесценивается за неделю |
<priority> | Нет | Google игнорирует. Значение относительное внутри одного сайта и никогда не было фактором ранжирования | 1.0 у всех URL, что математически эквивалентно отсутствию приоритета |
<xhtml:link> | Нет | Расширение для hreflang. Google читает; удобнее централизованной правки в <head> | Нет самоссылки, набор альтернатив в разных записях не совпадает |
<sitemapindex> / <sitemap> | Только в индексе | Корневой элемент и запись индексного файла. Внутри — <loc> на обычный sitemap и опционально <lastmod> | Индекс, ссылающийся на другой индекс, и смешение <url> с <sitemap> в одном файле |
Про lastmod подробно
Формат — W3C Datetime: допустимо и короткое 2026-07-14, и полное 2026-07-14T09:15:00+03:00 с указанием часового пояса. Смешивать оба варианта в одном файле можно, парсер это переварит.
Проблема не в формате, а в достоверности. «Значимым изменением» считается правка основного контента, структурированных данных или ссылок на странице — но не смена года в подвале, не пересборка кеша и не автоматический пересчёт блока «похожие товары». Если генератор ставит lastmod равным времени сборки файла, то через месяц у робота накапливается статистика: даты меняются, содержимое — нет. Дальше сигнал просто перестают учитывать по всему домену, и вернуть доверие сложнее, чем не терять его.
Предупреждение. Честныйlastmodу трети страниц полезнее, чем «свежий»lastmodу всех. Если взять дату изменения контента неоткуда — не выводите тег вовсе. Отсутствие сигнала лучше ложного сигнала.
Лимиты протокола: 50 000 URL, 50 МБ и sitemap index
Протокол задаёт два жёстких ограничения на один файл: не более 50 000 URL и не более 50 МБ в несжатом виде (52 428 800 байт). Оба лимита действуют одновременно: файл на 30 000 очень длинных URL с hreflang-разметкой упрётся в мегабайты раньше, чем в количество записей.
Файл можно отдавать сжатым gzip — как sitemap.xml.gz или через Content-Encoding: gzip. Лимит 50 МБ при этом считается по распакованному размеру, так что сжатие экономит трафик, но не поднимает потолок.
Когда URL больше лимита, файлы разбивают и объявляют через индексный:
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-static.xml</loc>
<lastmod>2026-05-02</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-categories.xml</loc>
<lastmod>2026-07-10</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products-1.xml.gz</loc>
<lastmod>2026-08-04T02:15:00+03:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products-2.xml.gz</loc>
<lastmod>2026-08-04T02:15:00+03:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-articles.xml</loc>
<lastmod>2026-08-05</lastmod>
</sitemap>
</sitemapindex>Индексный файл подчиняется тем же лимитам: до 50 000 записей и до 50 МБ. Формально это даёт потолок в 2,5 млрд URL на хост — на практике до него не доходит никто.
Вложенность индексов
Индексный файл не может ссылаться на другой индексный файл. Двухуровневая схема «индекс → индексы → sitemap» невалидна: поисковик прочитает верхний уровень, увидит внутри не карты, а индексы, и вложенные файлы останутся необработанными. Если разбиение уже переросло один уровень, правильное решение — не городить второй, а отправить несколько независимых индексных файлов (в robots.txt можно перечислить сколько угодно строк Sitemap:).
И ещё одно ограничение: индекс может перечислять только карты того же хоста. Общий индекс на несколько поддоменов работает лишь при подтверждении прав на все хосты в панели вебмастера — подробнее о разнице хостов в материале о поддоменах и подпапках.
Практика. Не упирайтесь в 50 000. Держите потолок шарда на уровне 20 000–45 000 URL: остаётся запас на рост каталога, файлы быстрее собираются и быстрее отдаются, а при ошибке в генерации вы теряете один шард, а не всю карту.
Правила URL: абсолютные адреса, один хост, одна схема, экранирование
Абсолютные URL того же хоста и той же схемы
Каждый <loc> — полный адрес с протоколом. Относительные пути вида /catalog/ протоколом не предусмотрены. Схема и хост должны совпадать с адресом самого файла sitemap: карта на https://example.com/sitemap.xml не может содержать http://example.com/... и https://www.example.com/... — для поисковика это другие хосты.
Именно отсюда растёт самый частый запрос про «sitemap xml https». Сценарий типовой: сайт переехал на HTTPS, редиректы настроены, а генератор карты продолжает подставлять старый базовый адрес из конфига или из поля «адрес сайта» в CMS. В результате каждый URL в карте — это лишний хоп через 301, и робот тратит бюджет обхода на редиректы вместо страниц. Как это диагностировать — в разборе 301 против 302 и в общем гайде по редиректам.
Ограничение по каталогу
По протоколу карта влияет только на URL, лежащие «не выше» её собственного каталога: файл на https://example.com/catalog/sitemap.xml вправе перечислять адреса внутри /catalog/, но не /blog/. Есть два законных обхода: положить файл в корень сайта (рекомендуемый вариант) либо объявить его строкой Sitemap: в robots.txt — объявленная в robots.txt карта считается относящейся ко всему хосту.
XML-экранирование и percent-encoding
Внутри <loc> находится XML-значение, а не «просто ссылка». Пять символов обязаны экранироваться: & → &, < → <, > → >, ' → ', " → ". На практике ломает файл почти всегда именно голый амперсанд из URL с параметрами.
Отдельная история — кириллические и любые не-ASCII адреса. Их нужно приводить к percent-encoding по RFC 3986: строка сначала кодируется в UTF-8, затем каждый байт записывается как %XX. Некоторые парсеры простят кириллицу «как есть», но валидатор такой файл забракует, а часть роботов приведёт адрес к другой форме и получит дубль.
# Неверно
<loc>https://example.com/каталог/окна/</loc>
<loc>https://example.com/catalog?a=1&b=2</loc>
<loc>/catalog/okna/</loc>
<loc>http://example.com/catalog/</loc>
# Верно
<loc>https://example.com/%D0%BA%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3/%D0%BE%D0%BA%D0%BD%D0%B0/</loc>
<loc>https://example.com/catalog?a=1&b=2</loc>
<loc>https://example.com/catalog/okna/</loc>
<loc>https://example.com/catalog/</loc>
# Быстро закодировать путь
python3 -c "import sys,urllib.parse; print(urllib.parse.quote(sys.argv[1], safe='/:?=&'))" \
'https://example.com/каталог/окна/'Расширения протокола: image, video, news и hreflang
Базовый протокол описывает только адреса. Поверх него существуют расширения — дополнительные пространства имён, которые добавляют метаданные. Подключать их стоит осознанно: каждое расширение раздувает файл и требует поддержки в генераторе.
Карты изображений
Нужны, когда картинки подгружаются скриптами, лежат на отдельном CDN-хосте или являются самостоятельным контентом (фотобанк, каталог, портфолио). Из полей сегодня реально поддерживается только адрес изображения — теги с подписью, заголовком, лицензией и геолокацией объявлены устаревшими и не обрабатываются.
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
<url>
<loc>https://example.com/catalog/okna/</loc>
<image:image>
<image:loc>https://cdn.example.com/img/okna-1.jpg</image:loc>
</image:image>
<image:image>
<image:loc>https://cdn.example.com/img/okna-2.jpg</image:loc>
</image:image>
</url>
</urlset>Обратите внимание: сами изображения могут лежать на другом хосте — на адреса картинок правило «тот же хост» не распространяется. Ограничение — до тысячи изображений на одну страницу.
Видео-карты
Имеет смысл заводить тем, у кого видео — основной контент: онлайн-кинотеатры, обучающие платформы, видеоблоги. Расширение передаёт заголовок, описание, ссылку на превью, ссылку на плеер или файл, длительность и дату истечения прав. Для сайта с одним роликом на главной затраты не окупаются — достаточно микроразметки на странице.
Новостные карты
Отдельный формат для сайтов, принятых в новостные сервисы. Ключевое ограничение: в файл включаются только материалы, опубликованные за последние двое суток, всё старое из него нужно вычищать. Передаются название издания, язык, дата публикации и заголовок. Часть исторических тегов (жанры, ключевые слова, уровень доступа) больше не обрабатывается.
hreflang через xhtml:link
Для мультиязычных сайтов разметку языковых версий можно вынести из HTML в sitemap. Это удобнее: правки делаются в одном генераторе, а не в шаблонах, и не раздувают <head> каждой страницы (что заодно упрощает работу с title, description и другими метатегами).
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/pricing</loc>
<xhtml:link rel="alternate" hreflang="ru" href="https://example.com/pricing"/>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing"/>
</url>
<url>
<loc>https://example.com/en/pricing</loc>
<xhtml:link rel="alternate" hreflang="ru" href="https://example.com/pricing"/>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/pricing"/>
</url>
</urlset>Два правила, на которых спотыкаются чаще всего. Первое: каждая запись перечисляет все языковые версии, включая саму себя. Второе: связи должны быть взаимными — если русская страница ссылается на английскую, английская обязана ссылаться на русскую. Односторонние связи игнорируются целиком, а не частично.
Что класть в sitemap, а что — нет
Критерий один и он простой: в карте должны быть только те URL, которые вы хотите видеть в индексе как самостоятельные страницы. Формально это три условия одновременно:
- URL отдаёт 200 OK — не редирект, не 404, не 403, не 5xx;
- URL канонический —
rel="canonical"на странице указывает на него самого; - URL индексируемый — не закрыт в robots.txt, нет
noindexни в метатеге, ни в заголовкеX-Robots-Tag.
Конфликты, которые обесценивают файл
- URL закрыт в robots.txt. Робот не может скачать страницу, чтобы проверить её содержимое, но видит адрес в карте. Результат — записи вида «обнаружено, но не проиндексировано» и предупреждение о конфликте в панели вебмастера.
- Страница с
noindex. Прямое противоречие: карта говорит «проиндексируй», метатег — «не индексируй». Побеждаетnoindex, а карта теряет доверие. - Редирект. Каждый такой URL — потраченный впустую запрос робота. На больших сайтах это заметная доля краулингового бюджета.
- 404 и 410. Явный признак, что карта не пересобиралась после удаления контента.
- Неканоническая версия. URL с UTM-метками, идентификатором сессии, вариантами сортировки и фильтров, версии с
wwwи без. Все они схлопываются в канонический адрес — в карте им делать нечего. - Служебные страницы. Корзина, оформление заказа, личный кабинет, внутренний поиск, страницы благодарности, тестовые и стейджинговые адреса.
- Пагинация и фасетные фильтры. Спорный случай: если страницы пагинации самоканоничны и несут ценность, их включают; если они схлопываются на первую — нет.
Диагностическое правило. Отношение «проиндексировано / отправлено» имеет смысл, только если в sitemap лежит чистый список. Насыпав туда всё подряд, вы получите условные 20% и не сможете отличить проблему качества контента от собственного мусора в файле.
Разбиение по типам контента: как sitemap превращается в диагностику
Один общий sitemap.xml на 40 000 URL отвечает на вопрос «сколько проиндексировано» и не отвечает на вопрос «что именно не проиндексировано». Разбиение решает это бесплатно: панели вебмастеров показывают статистику по каждому файлу отдельно.
Практическая схема для магазина: sitemap-static.xml (десяток посадочных), sitemap-categories.xml, sitemap-products-N.xml, sitemap-articles.xml. Если в отчёте видно, что категории проиндексированы на 98%, статьи на 90%, а товары на 34% — вы за минуту локализовали проблему до товарных карточек, вместо того чтобы гадать по всему сайту.
Второй уровень разбиения — по партициям внутри типа. Для товаров удобно резать по диапазонам идентификаторов или по дате добавления: тогда «свежий» шард пересобирается часто, а исторические — редко, и lastmod в индексном файле начинает нести реальную информацию.
| Размер и тип сайта | Схема файлов | Как обновлять |
|---|---|---|
| Лендинг, сайт-визитка — до ~100 URL | Один статический sitemap.xml в корне | Руками или при сборке проекта; пересобирать при добавлении страниц |
| Корпоративный сайт, блог — 100–5 000 URL | Один sitemap.xml, либо индекс + два файла: страницы и статьи | Плагин CMS или генерация при сборке; суточного крона достаточно |
| Интернет-магазин — 5 000–50 000 URL | Индекс + разбиение по типам: категории, товары, статьи, статика | Динамическая генерация с записью в файлы по крону; товарный файл — чаще остальных |
| Крупный каталог, маркетплейс — от 50 000 URL | Индекс + шардирование по типам и партициям по 20 000–45 000 URL | Только динамическая генерация из БД, инкрементально: пересобирается изменившийся шард, а не весь набор |
| Новостной сайт, медиа | Обычный индекс + отдельная новостная карта (только последние двое суток) | Новостной файл — на каждую публикацию; общий — по расписанию |
| Мультиязычный сайт | Индекс + по файлу на язык, hreflang через xhtml:link | Генерация из одного источника данных, чтобы наборы альтернатив не разъезжались между языками |
| Сайт с поддоменами | Свой sitemap и свой robots.txt на каждом хосте | Независимо друг от друга; общий индекс — только при подтверждении прав на все хосты |
Как получить файл: плагин CMS, краулер, скрипт, динамическая генерация
Плагин или штатный модуль CMS
Самый быстрый путь. Популярные движки умеют собирать карту либо из коробки, либо через SEO-плагин. Минус один, но существенный: по умолчанию в файл попадает всё подряд — теги, архивы по датам, страницы авторов, вложения. Настройка исключений — обязательный шаг, а не опция. После установки плагина откройте получившийся файл глазами и вычеркните всё, что не должно быть отдельной страницей в поиске.
Генератор-краулер
Программа или онлайн-сервис обходит сайт как робот и выгружает статический файл. Плюс: краулер видит реальную доступность страниц и не включит то, до чего сам не дошёл. Минусы: это снимок на момент обхода, который устаревает; краулер не найдёт страницы-сироты (а именно ради них карта часто и делается); на больших сайтах обход занимает часы. Разумная зона применения — сайты до нескольких десятков тысяч URL с редкими изменениями.
Генерация при сборке
Для статических генераторов и SSG-фреймворков карта собирается на этапе билда из того же источника, что и сами страницы. Список URL по определению совпадает с тем, что реально задеплоено. Идеальный вариант для документации, блогов и контентных проектов.
Динамическая генерация из базы
Для крупного сайта альтернатив нет. Только генерация из БД гарантирует, что карта отражает текущее состояние: товар снят с публикации — исчез из файла в ближайший цикл. Ключевой нюанс — не отдавать карту «на лету» на каждый запрос: выборка на 200 000 строк с последующей сборкой XML это тяжёлый запрос, а запрашивают карту не только роботы. Правильно — собирать в файлы по расписанию и отдавать их статикой.
<?php
// build-sitemap.php — запуск по расписанию, результат кладётся статикой
$base = 'https://example.com';
$dir = '/var/www/example.com/public';
$max = 45000; // запас до лимита 50 000
$part = 1;
$n = 0;
$sql = "SELECT slug, updated_at
FROM products
WHERE is_published = 1
AND is_indexable = 1
AND canonical_id IS NULL
ORDER BY id";
$open = function (int $p) use ($dir) {
$f = fopen("$dir/sitemap-products-$p.xml", 'w');
fwrite($f, '<?xml version="1.0" encoding="UTF-8"?>' . "\n");
fwrite($f, '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">' . "\n");
return $f;
};
$out = $open($part);
foreach ($pdo->query($sql, PDO::FETCH_ASSOC) as $row) {
if ($n >= $max) { // закрыли шард, открыли следующий
fwrite($out, "</urlset>\n");
fclose($out);
$out = $open(++$part);
$n = 0;
}
$path = '/product/' . rawurlencode($row['slug']);
$loc = htmlspecialchars($base . $path, ENT_XML1 | ENT_QUOTES, 'UTF-8');
$mod = date('Y-m-d', strtotime($row['updated_at'])); // дата контента, не времени сборки
fwrite($out, " <url><loc>$loc</loc><lastmod>$mod</lastmod></url>\n");
$n++;
}
fwrite($out, "</urlset>\n");
fclose($out);Три вещи, которые здесь важнее самого кода: выборка фильтрует по признакам «опубликован», «индексируем» и «канонический»; путь прогоняется через rawurlencode, а итоговый URL — через XML-экранирование; lastmod берётся из поля контента, а не из time().
Как объявить sitemap: robots.txt, панели вебмастеров, IndexNow
Строка Sitemap в robots.txt
Самый универсальный способ: любой краулер, поддерживающий протокол, увидит карту без всякой регистрации.
User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /search
Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap-news.xmlПравила директивы: адрес обязательно абсолютный; строка не принадлежит ни одной группе User-agent и действует глобально, поэтому её принято выносить в конец файла; строк может быть несколько — например, отдельно основной индекс и отдельно новостная карта. Регистр названия директивы значения не имеет. Подробный разбор синтаксиса и приоритетов — в гайде по robots.txt.
Панели вебмастеров
В Google Search Console карта добавляется в разделе Sitemaps подтверждённого ресурса — отправлять нужно индексный файл, вложенные подхватятся сами. В Яндекс.Вебмастере — раздел «Индексирование → Файлы Sitemap»; по документации на обработку добавленного файла может уйти до двух недель, так что паниковать на третий день не нужно.
Плюс панелей не в самой отправке (robots.txt делает то же самое), а в отчётности: статус обработки, дата последнего чтения, число найденных URL, список ошибок с конкретными строками.
Пинг и IndexNow
Здесь важное обновление, о котором многие руководства до сих пор молчат. Классические ping-эндпоинты, которыми годами «пинали» поисковики после публикации, свою роль потеряли: Google убрал упоминание такого эндпоинта из документации, Bing тоже отказался от него в пользу другого механизма. Ориентироваться на «пингануть после деплоя» больше нет смысла.
Актуальный быстрый сигнал — протокол IndexNow: вы кладёте на сайт ключевой файл и отправляете HTTP-запрос со списком изменившихся адресов. Его поддерживают Bing, Яндекс и ещё несколько поисковиков; Google в протоколе не участвует. Логика такая: sitemap — базовый и обязательный канал для всех, IndexNow — дополнительный быстрый сигнал для тех, кто его принимает. Одно не заменяет другое.
Как часто пересобирать файл
По факту изменений, а не по календарю. Контентный сайт — раз в сутки ночью. Магазин со стабильным ассортиментом — раз в сутки, товарный шард чаще при массовых загрузках. Новостной сайт — новостную карту на каждую публикацию. Статический сайт-визитка — при деплое. Если ничего не менялось, пересобирать файл не нужно: это только собьёт lastmod.
Как проверить sitemap
Заголовки ответа и валидность XML
Первое, что нужно увидеть, — что файл вообще отдаётся напрямую, с кодом 200 и правильным типом содержимого. Корректный Content-Type — application/xml или text/xml. Если вы видите text/html, это почти всегда значит, что запрос перехватил роутер CMS или SPA и отдал HTML-шаблон вместо файла.
# 1. Заголовки: код ответа, тип содержимого, сжатие
curl -sI https://example.com/sitemap.xml \
| grep -iE 'HTTP/|content-type|content-encoding|content-length|x-robots-tag'
# 2. Валидность XML (тишина в выводе = ошибок нет)
curl -s https://example.com/sitemap.xml | xmllint --noout -
# 3. Для сжатой карты
curl -s https://example.com/sitemap-products-1.xml.gz | gunzip | xmllint --noout -
# 4. Проверка по официальной XSD-схеме протокола
curl -sO https://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd
curl -s https://example.com/sitemap.xml -o sitemap.xml
xmllint --noout --schema sitemap.xsd sitemap.xml
# 5. BOM в начале файла — частая причина «ошибки синтаксического анализа»
curl -s https://example.com/sitemap.xml | head -c 3 | xxd
# efbb bf в выводе = BOM присутствует, его нужно убратьВыборочная проверка кодов ответа
Валидный XML ещё ничего не говорит о том, живы ли перечисленные страницы. Разумный компромисс между «проверить всё» и «не проверять ничего» — случайная выборка из полусотни адресов. Если в ней окажется хотя бы один редирект или 404, проблема почти наверняка массовая.
# Коды ответа для 50 случайных URL из карты, 8 запросов параллельно
curl -s https://example.com/sitemap.xml \
| grep -oE '<loc>[^<]+</loc>' \
| sed -E 's#</?loc>##g' \
| shuf -n 50 \
| xargs -P 8 -I{} curl -s -o /dev/null -w '%{http_code} %{url_effective}\n' {} \
| sort | uniq -c | sort -rn
# Сколько всего URL в карте и нет ли http-адресов на https-сайте
curl -s https://example.com/sitemap.xml | grep -c '<loc>'
curl -s https://example.com/sitemap.xml | grep -c '<loc>http://'Ожидаемый результат первой команды — одна строка вида 50 200 …. Любые 301, 302, 404 и 5xx в выводе означают, что генератор карты не синхронизирован с реальным состоянием сайта. Расшифровка кодов — в справочнике по HTTP-статусам.
Отчёты панелей вебмастеров
Смотрите три числа по каждому файлу: обнаружено URL, проиндексировано, ошибки. Разрыв между первыми двумя — это ваш реальный показатель качества контента и технической доступности. Категории «обнаружено, сейчас не проиндексировано» и «просканировано, сейчас не проиндексировано» означают разные вещи: в первом случае робот до страницы не дошёл, во втором — дошёл и решил не брать.
Инструменты enterno.io
- SEO-аудит — проверяет наличие и доступность карты сайта, находит конфликты между sitemap, robots.txt и мета-директивами.
- Проверка robots.txt — есть ли директива
Sitemap, абсолютный ли адрес, не закрыты ли перечисленные в карте разделы. - Поиск битых ссылок — быстрый способ найти 404 среди URL, которые вы объявили поисковикам.
- Проверка редиректов — прогон адресов из карты на предмет лишних хопов и цепочек.
- Анализ HTTP-заголовков —
Content-Type,Content-EncodingиX-Robots-Tagу самого файла карты.
Типовые ошибки: симптом, причина, проверка, фикс
| Симптом | Причина | Как проверить | Фикс |
|---|---|---|---|
| «Не удалось получить файл Sitemap» в панели | Файл отдаёт 404, редирект или закрыт базовой авторизацией | curl -sI по адресу карты | Отдавать 200 напрямую, снять авторизацию с пути карты |
| «Ошибка синтаксического анализа» | BOM или пробел перед XML-декларацией, неэкранированный &, обрезанный файл | head -c 3 | xxd, затем xmllint --noout | Убрать BOM, экранировать спецсимволы, проверить, что генерация доходит до конца |
| Карта открывается как страница сайта | Запрос перехватывает роутер CMS или SPA, отдаётся Content-Type: text/html | curl -sI и просмотр первых строк тела | Отдавать статический файл до роутера или явно задать тип содержимого |
| Отправлено 50 000, проиндексировано 1 200 | В карте мусор: дубли, фильтры, служебные и тонкие страницы | Выборка кодов ответа + сверка с rel="canonical" | Чистить список до канонических страниц, разбить по типам и мерить отдельно |
| «URL в Sitemap заблокирован в robots.txt» | Конфликт директив: адрес объявлен и одновременно закрыт от обхода | Проверка robots.txt | Решить, что правда: убрать URL из карты либо открыть раздел для обхода |
| http-адреса в карте на https-сайте | Захардкоженный базовый адрес в конфиге или в настройках CMS | grep -c '<loc>http://' по файлу | Исправить базовый URL и пересобрать все шарды |
| Карта лежит в подпапке, но покрывает весь сайт | Ограничение протокола по каталогу | Сверить путь файла с путями в <loc> | Перенести файл в корень либо объявить строкой Sitemap: в robots.txt |
У всех URL lastmod = сегодня | Генератор подставляет время сборки файла | Открыть файл и посмотреть разброс дат | Брать дату из поля изменения контента; если её нет — не выводить тег |
| В карте адреса, удалённые год назад | Статический файл, который никто не пересобирает | Выборочная проверка кодов ответа | Перевести генерацию на расписание или на сборку проекта |
| Кириллические адреса «как есть» | Генератор не кодирует путь | Проверка по XSD-схеме | rawurlencode для пути, затем XML-экранирование итогового URL |
| Индекс обработан, вложенные файлы — нет | Индекс ссылается на другой индекс либо на карты чужого хоста | Открыть корневой элемент вложенных файлов | Развернуть в один уровень; несколько индексов объявить отдельными строками в robots.txt |
| Файл больше 50 МБ или свыше 50 000 URL | Отсутствие шардирования | grep -c '<loc>' и размер файла | Разбить на шарды по 20 000–45 000 URL и собрать индекс |
Частые вопросы
Нужен ли sitemap.xml маленькому сайту?
Обязательным он не является ни для одного сайта. Для сайта на несколько десятков страниц со сплошной перелинковкой эффект будет близок к нулю: робот и так обойдёт всё. Но карта ничего не стоит, а панель вебмастера получит понятную статистику «отправлено против проиндексировано» — уже ради этого её имеет смысл сделать.
Влияет ли sitemap на позиции в поиске?
Нет. Ни сам файл, ни priority, ни changefreq не участвуют в ранжировании. Карта влияет только на обнаружение и приоритет обхода. Обещания «настроим sitemap и вырастут позиции» — маркетинг, а не механика поиска.
Где должен лежать файл и как его назвать?
Имя произвольное — sitemap.xml просто общепринятое соглашение. Расположение существеннее: по протоколу карта покрывает только свой каталог и вложенные, поэтому корень сайта — единственное место, где вопрос не возникает. Файл в подпапке допустим, но тогда его нужно объявить в robots.txt.
Что делать, если URL больше 50 000?
Разбить на несколько файлов и собрать индексный. Не пытайтесь уложиться, выбрасывая страницы: лимит существует для управляемости, а не для того, чтобы ограничить размер вашего сайта. Разумный размер шарда — 20 000–45 000 URL.
Нужно ли указывать changefreq и priority?
Практической пользы нет. Google их игнорирует, остальные краулеры в лучшем случае считают слабой подсказкой. Вреда от них тоже нет, кроме лишних байтов, — но если вы пишете генератор с нуля, эти теги можно спокойно не реализовывать и потратить время на честный lastmod.
Сколько ждать индексации после отправки карты?
Гарантированных сроков не существует. Обработка самого файла обычно занимает от нескольких часов до нескольких дней, у Яндекса документация допускает до двух недель. Индексация конкретных страниц зависит от их качества, авторитета сайта и краулингового бюджета — карта на этот срок влияет слабо.
Можно ли класть в карту страницы с редиректом или noindex?
Технически можно, практически не нужно. Редирект тратит запрос робота впустую, noindex создаёт прямое противоречие сигналов. Изредка редирект добавляют намеренно, чтобы робот быстрее узнал о переезде — но это разовая мера с последующей чисткой, а не постоянное состояние файла.
Нужен ли отдельный sitemap для поддомена?
Да. Поддомен — отдельный хост со своим robots.txt и своей картой. Перечислять его URL в карте основного домена нельзя, если только вы не подтвердили права на оба хоста в панели вебмастера.
Чеклист
- Файл открывается по прямому адресу, отдаёт 200 и
Content-Type: application/xml. - Кодировка UTF-8, BOM отсутствует, перед XML-декларацией нет пробелов и пустых строк.
- Namespace
http://www.sitemaps.org/schemas/sitemap/0.9на месте и не переписан. - Все
<loc>— абсолютные URL той же схемы и того же хоста, что и сам файл. - Амперсанды и прочие спецсимволы экранированы, не-ASCII пути приведены к percent-encoding.
- В карте только канонические, индексируемые URL, отдающие 200.
- Нет пересечений с
Disallowв robots.txt и со страницами подnoindex. - Ни один файл не превышает 50 000 URL и 50 МБ в несжатом виде.
- Индексный файл ссылается только на обычные карты того же хоста, без вложенных индексов.
lastmodотражает реальное изменение контента, а не время сборки файла.- Карта разбита по типам контента, чтобы отчёт вебмастера показывал проблемные разделы.
- В robots.txt есть строка
Sitemap:с абсолютным адресом. - Файл добавлен в Google Search Console и Яндекс.Вебмастер, статус обработки проверен.
- Генерация автоматизирована: расписание или сборка проекта, а не ручная правка.
- Выборка из 50 случайных URL периодически проверяется на коды ответа.