Sitemap для крупного сайта перестаёт справляться с задачей, когда число URL превышает 50 000 или файл становится больше 50 МБ - это жёсткий лимит протокола sitemaps.org, а не рекомендация. Решение - sitemap index: файл-указатель, который ссылается на несколько дочерних sitemap-файлов, каждый в пределах лимита.
В проектах Exceltic.dev мы регулярно видим один и тот же сценарий: сайт с каталогом на 80 000-150 000 товарных страниц или блогом на несколько сотен статей продолжает работать с единственным sitemap.xml, оставшимся от раннего этапа разработки. Формально файл валиден, пока не упирается в лимит - но по факту Google Search Console уже давно показывает неполный охват, просто это никто не связывает с sitemap.
Дальше - как устроен sitemap index, как правильно разбивать URL по файлам для мониторинга индексации и какие из атрибутов lastmod, changefreq и priority Google использует на практике, а какие полностью игнорирует.
Рост контентного сайта - каталога, блога на сотни постов или мультистрановых страниц - редко ощущается как отдельное событие. Лимит sitemap превышается незаметно, между двумя обычными спринтами разработки. Проблему обнаруживают не по ошибке сборки, а по тому, что охват в Google Search Console вдруг перестаёт расти вместе с числом опубликованных страниц.
Когда одного sitemap.xml перестаёт хватать
XML sitemap - файл в формате XML со списком URL сайта, который сообщает поисковым системам, какие страницы существуют и когда они обновлялись.
Протокол sitemaps.org задаёт точный лимит: не более 50 000 URL и не более 50 МБ в несжатом виде на один файл. Это ограничение действует, даже если файл отдаётся сжатым через gzip - лимит считается по размеру до сжатия.
На практике лимит по объёму настигает раньше, чем лимит по количеству URL. Если в sitemap записаны длинные URL с параметрами, тегами <image:image> или множеством <lastmod> для hreflang-версий, 50 МБ можно набрать и на 30 000-35 000 записей.
Ситуации, где лимит превышается почти неизбежно:
- Каталог товаров на маркетплейсе или интернет-магазине от 50 000 SKU.
- Блог или база знаний, которая копит сотни статей за несколько лет и добавляет к ним теговые и категорийные страницы.
- Мультистрановой или мультиязычный сайт, где каждая страница дублируется в 3-5 языковых версиях.
Если сайт превысил лимит, а sitemap.xml продолжает перечислять все URL подряд, Google либо обрежет файл на 50 000-й записи, либо целиком откажется его обрабатывать. Часть страниц выпадает из поля зрения краулера без единого сообщения об ошибке в интерфейсе - разве что охват в Search Console перестанет расти.
Что такое sitemap index и как он устроен
Sitemap index - файл, который не содержит сами URL страниц, а перечисляет ссылки на другие sitemap-файлы, каждый из которых укладывается в лимит 50 000 URL и 50 МБ.
Структура простая: корневой файл (обычно sitemap-index.xml или sitemap.xml) содержит список тегов <sitemap>, каждый с адресом дочернего файла и датой его последнего изменения.
Пример структуры sitemap index
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-posts.xml</loc>
<lastmod>2026-08-20</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products-1.xml</loc>
<lastmod>2026-08-25</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products-2.xml</loc>
<lastmod>2026-08-25</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-pages.xml</loc>
<lastmod>2026-07-01</lastmod>
</sitemap>
</sitemapindex>Протокол sitemaps.org устанавливает тот же лимит и для самого индекса: до 50 000 ссылок на дочерние sitemap-файлы, размер индекса - не более 50 МБ. На практике этого достаточно даже для сайтов с десятками миллионов страниц, поскольку каждая ссылка в индексе - это отдельный файл на 50 000 URL.
Google и другие поисковые системы обходят индекс рекурсивно: сначала читают корневой файл, затем каждый дочерний sitemap как обычный список URL. Для краулера это прозрачно - разница проявляется только в том, как вы мониторите результат.
Как разбивать URL на файлы осмысленно
Самая частая ошибка - механически резать список URL по 50 000 подряд, без учёта типа контента. Технически это соответствует лимиту, но лишает вас главного преимущества sitemap index - раздельного мониторинга индексации по разделам сайта.
Google Search Console показывает статистику индексации для каждого отдельного sitemap-файла. Если разбить URL по типу контента - статьи отдельно, товары отдельно, статические страницы отдельно, - вы сразу видите, какой раздел индексируется хуже.
Пример: у сайта 600 статей в блоге и 120 000 товарных страниц в каталоге. Логичная разбивка:
sitemap-posts.xml- все 600 статей, один файл, лимит не выбран.sitemap-products-1.xml…sitemap-products-3.xml- товары по 40 000 URL на файл, с запасом от лимита в 50 000.sitemap-pages.xml- статические страницы (о компании, контакты, лендинги).
При такой структуре в Search Console видно: sitemap-posts.xml - 95% страниц в индексе, sitemap-products-2.xml - 40%. Проблема локализована мгновенно - без этой разбивки пришлось бы вручную сверять тысячи URL из общего списка.
Для мультиязычных сайтов имеет смысл отдельный sitemap-файл на каждую языковую версию каталога или блога - это же разделение упрощает работу с hreflang-разметкой и её проверку.
Пошаговая генерация
Генерация при сборке статического сайта
На статическом или headless-стеке (Astro, Next.js со статическим экспортом) sitemap генерируется как часть сборки, а не вручную. Скрипт на этапе билда проходит по content collections или по данным из CMS, группирует URL по типу контента и пишет отдельные XML-файлы плюс корневой sitemap index.
Готовые интеграции вроде @astrojs/sitemap закрывают базовый случай - один плоский sitemap.xml. Как только сайт вырастает за лимит и нужна разбивка по типам контента, требуется собственный build-скрипт или endpoint, который формирует несколько файлов и индекс над ними.
Автоматическое обновление при добавлении контента
Sitemap не должен обновляться вручную. Каждый деплой - через CI/CD или webhook из headless CMS - должен пересобирать актуальный список URL и перезаписывать файлы.
Ключевой момент: дата в <lastmod> должна браться из реального поля обновления контента (поле updatedAt в CMS или дата git-коммита файла), а не проставляться как текущая дата сборки для каждой страницы при каждом деплое.
Регистрация в Google Search Console и robots.txt
В Google Search Console нужно указать только адрес корневого sitemap index - не каждый дочерний файл по отдельности. Google сам обойдёт все вложенные файлы.
Дополнительно адрес sitemap index стоит указать строкой в robots.txt:
Строка Sitemap в robots.txt
Sitemap: https://example.com/sitemap-index.xmlЭто разные механизмы с разными задачами: sitemap.xml сообщает краулеру, какие страницы существуют, а robots.txt и llms.txt управляют тем, каким краулерам вообще разрешено заходить на сайт. Один файл без другого не работает как полноценная стратегия видимости - sitemap без корректного robots.txt может указывать на страницы, которые сам же robots.txt запрещает обходить.
lastmod, changefreq, priority - что из этого Google реально использует
Из трёх необязательных атрибутов sitemap Google по собственному признанию использует по существу только один - и то не всегда.
changefreq (заявленная частота обновления страницы) Google уже несколько лет официально игнорирует. Поле можно оставить в файле для совместимости с другими системами, но на индексацию оно не влияет.
priority (относительный приоритет страницы от 0 до 1) Google также не учитывает при выборе, что и когда индексировать. Приоритет страницы поисковая система определяет по внутренней перелинковке и другим сигналам, а не по значению, которое вы сами себе присвоили.
lastmod - единственное поле, которое Google действительно способен использовать, но только при одном условии: значение должно быть точным и отражать реальное изменение контента. Если lastmod при каждой пересборке сайта проставляется как текущая дата для всех страниц подряд - в том числе для тех, где ничего не менялось, - Google со временем перестаёт доверять этому полю целиком, для всего домена.
Практический вывод: не тратьте время на настройку changefreq и priority - это балласт, увеличивающий вес файла без пользы. Настройте lastmod только если он берётся из реальной даты изменения контента, а не из даты сборки.
Типичные ошибки
- Единый sitemap.xml на 80 000+ URL. Формально превышает лимит протокола - часть страниц Google не увидит вовсе.
- lastmod = дата деплоя для всех страниц. Портит доверие к полю для всего домена, а не только для затронутых страниц.
- Sitemap index не указан в robots.txt и не добавлен в Search Console. Файлы существуют на сервере, но поисковая система о них не знает.
- В sitemap попадают страницы с noindex, редиректы, неканонические дубли. Такие URL расходуют краулинговый бюджет и создают противоречивые сигналы для Google.
- Разбивка по алфавиту или по порядку добавления вместо типа контента. Технически укладывается в лимит, но делает мониторинг индексации по разделам бессмысленным.
Для кого это актуально
Sitemap index нужен не каждому сайту. Лендинг или корпоративный сайт на 20-40 страниц прекрасно обходится одним sitemap.xml - разбивка на несколько файлов только усложнит поддержку без всякой пользы.
Тема актуальна для контентных каталогов (тысячи и десятки тысяч товарных страниц), блогов и баз знаний с сотнями статей, мультистрановых и мультиязычных сайтов. Если на существующем сайте до сих пор один файл sitemap.xml, а объём контента давно перерос разумные рамки, добавить корректную структуру sitemap index на уже работающий сайт - точечная доработка, а не повод для полного пересобирания проекта. Если же вы только планируете новый контентный сайт с расчётом на рост каталога или блога, разумно заложить архитектуру sitemap с самого начала - это часть работ при разработке корпоративного сайта с нуля.
Часто задаваемые вопросы
Сколько URL можно указать в одном sitemap-файле?
Не более 50 000 URL и не более 50 МБ в несжатом виде - это официальный лимит протокола sitemaps.org, а не рекомендация конкретной поисковой системы. При превышении лимита нужен sitemap index, который ссылается на несколько отдельных файлов, каждый в пределах ограничения.
Можно ли сжимать sitemap в gzip?
Да, sitemap-файл можно отдавать в формате .xml.gz, и это уменьшает объём передаваемых данных. Важно учитывать: лимит 50 МБ считается по размеру файла до сжатия, а не после. Sitemap на 45 МБ в несжатом виде всё ещё должен быть разбит, даже если после gzip он весит 4 МБ.
Нужен ли sitemap index, если на сайте меньше 50 000 страниц?
Формального требования нет - один sitemap.xml укладывается в лимит. Но если сайт смешивает разные типы контента (статьи, товары, статические страницы), разбивка на несколько файлов через sitemap index уже на 5 000-10 000 URL даёт раздельный мониторинг индексации по разделам в Google Search Console, что упрощает диагностику.
Как Google узнаёт о существовании sitemap index?
Двумя способами: через строку Sitemap: в robots.txt, которую краулер читает автоматически, и через ручную отправку адреса в отчёте «Файлы Sitemap» Google Search Console. Оба способа можно использовать одновременно - это не конфликтует.
Влияет ли правильный sitemap на позиции сайта в поиске?
Напрямую нет - sitemap не поднимает страницы в выдаче. Но он влияет на то, находит ли Google вообще ваши страницы и как быстро их индексирует. Без корректного sitemap на крупном сайте часть контента может годами не участвовать в ранжировании просто потому, что краулер о нём не знает.
Если на вашем сайте sitemap давно не пересматривался, а объём контента вырос в разы - опишите задачу команде Exceltic.dev. Разберём текущую структуру и предложим план внедрения sitemap index под ваш объём и тип контента.