Sitemap.xml — це файл зі списком канонічних URL, які ви показуєте Google як сторінки для обходу. Він не замінює нормальну структуру сайту, але допомагає пошуковику швидше знаходити нові, оновлені або глибоко вкладені сторінки.

Для невеликих сайтів з простою архітектурою однієї XML-карти часто достатньо. Але коли ресурс росте, з’являються окремі типи сторінок, мовні версії, тисячі товарів або великий блог, одна карта стає незручною в підтримці. Саме в цей момент з’являється практичний сенс у sitemap index — файлі, який збирає кілька sitemap в одну зрозумілу структуру.

Усе це важливо не лише з технічної точки зору. Добре зібрана карта сайту дає Google чистіший сигнал: які URL є канонічними, які сторінки варто обходити, а які взагалі не повинні потрапляти в sitemap. Це базова, але часто недооцінена частина просування сайту .

Матеріал спирається на офіційну документацію Google щодо sitemap , рекомендації щодо sitemap index files і вимоги sitemap protocol .

Що таке sitemap.xml і для чого він потрібен

Класичний файл sitemap.xml містить список URL, які пошукова система може обходити. Для SEO важливо не просто згенерувати його автоматично, а наповнити правильними адресами: канонічними сторінками з кодом відповіді 200, без редиректів, дублів, службових розділів і сторінок, закритих від індексації.

Sitemap особливо корисний у трьох випадках: коли сайт великий, коли він новий і на нього ще мало зовнішніх посилань, а також коли частина важливих сторінок захована глибоко в структурі. Для простого сайту на кілька десятків сторінок з нормальною перелінковкою це не завжди критичний інструмент. Для магазину, медіа або великого корпоративного проєкту — уже зовсім інша ситуація.

Тут важливо не перебільшувати роль карти сайту. Вона не «змушує» Google індексувати сторінку. Якщо URL слабкий, дубльований, закритий через robots.txt , має noindex або canonical на іншу сторінку, сама присутність у sitemap проблему не вирішить.

Коли звичайної XML-карти вже недостатньо

Формальні ліміти — не єдина причина переходити на кілька карт. На практиці складнощі починаються раніше. Наприклад, коли на сайті окремо живуть товари, категорії, блог, фільтри, статичні сторінки і ще кілька мовних версій. Тримати все це в одному sitemap технічно можна, але підтримувати — незручно. У таких випадках проблема зазвичай впирається не лише в карту сайту, а й у те, як загалом побудована структура ресурсу ще на етапі розробки сайту .

У таких проєктах карти зазвичай розбивають за типами сторінок або розділами сайту. Окремо — товари, окремо — категорії, блог, статичні сторінки, іноді ще й зображення. Це спрощує не лише підтримку, а й перевірку: коли виникає проблема, видно не просто «щось не так із sitemap», а де саме вона виникла.

Для прикладу: у блозі на 200–300 матеріалів окремий sitemap index може бути зайвим. Але коли на сайті вже десятки тисяч товарів, SEO-сторінки, новини та кілька мов, одна загальна карта швидко перетворюється на незручний компроміс.

Що таке sitemap index і як він працює

Sitemap index або sitemap index file — це XML-файл, який містить не самі сторінки, а посилання на інші файли sitemap. По суті, це зміст для кількох карт сайту. Замість того щоб передавати десятки файлів окремо, ви подаєте один індекс, а Google уже переходить до вкладених sitemap.

Технічно файл будується через кореневий тег <sitemapindex> , усередині якого розміщуються блоки <sitemap> з обов’язковим тегом <loc> і, за потреби, <lastmod> . Саме таку структуру описують і sitemap protocol , і документація Google.

Сам по собі файл-індекс не дає сайту жодного «бонусу». Він потрібен тоді, коли без нього вже незручно керувати картами: сайт росте, типів сторінок стає більше, а підтримка однієї спільної sitemap починає забирати зайвий час.

Які переваги дає sitemap index

  • Простіше підтримувати великий сайт. Коли карти розбиті на товари, категорії, блог і службові розділи, з ними легше працювати й технічно, і в межах SEO-аудиту.

  • Швидше видно джерело проблеми. Якщо збій стався не в усій структурі, а лише, наприклад, у sitemap товарів, це видно одразу.

  • Не треба щоразу перебудовувати один великий файл. Оновлюється тільки та карта, де реально з’явилися нові URL або змінився контент.

  • Зручніше працювати з великими або мультимовними проєктами. Особливо там, де різні розділи сайту оновлюються з різною швидкістю.

  • Легше перевіряти карту в Google Search Console. Коли файли логічно розділені, помилки читаються значно швидше, ніж у спільному списку на десятки тисяч URL.

Ліміти та технічні вимоги

І протокол, і документація Google задають чіткі межі, які краще врахувати ще до генерації файлів:

  • один файл sitemap може містити до 50 000 URL або мати розмір до 50 МБ без стиснення;

  • один файл sitemap index може містити до 50 000 посилань на окремі sitemap;

  • усі файли мають бути у форматі UTF-8 і відповідати синтаксису XML;

  • у sitemap варто залишати лише канонічні URL, які ви реально хочете бачити в індексі;

  • посилання в sitemap index мають вести на карти того самого сайту, якщо не налаштований окремий сценарій cross-site submission.

Окремо варто прибрати ще одну поширену ілюзію. Теги <changefreq> і <priority> довго сприймали як інструмент впливу на обхід, але Google прямо зазначає, що зараз їх не використовує. Тому ставка має бути не на ці поля, а на коректний склад sitemap, реальний <lastmod> і відсутність технічного шуму.

Як подати sitemap index у Google Search Console

Базовий сценарій простий: файл розміщують на домені, після чого його URL додають у розділ Sitemaps у Search Console. Для великих сайтів також корисно вказати шлях до карти в robots.txt , щоб Google швидше знаходив актуальний файл під час повторних обходів.

Але сам факт успішного подання ще мало про що говорить. Значно важливіше, що саме лежить усередині. Якщо в sitemap потрапили сторінки з noindex, canonical на інший URL, 3xx-, 4xx- чи 5xx-відповідями, карта формально буде існувати, але як сигнал для індексації працюватиме слабко.

Корисно також звіряти sitemap із фактичною індексацією. Якщо потрібно глибше розібратися з тим, як пошукові системи обходять і додають сторінки в індекс, подивіться матеріал як проіндексувати сайт у пошукових системах і окремо перевірте налаштування Google Search Console .

Яких помилок варто уникати

Найгірший варіант — коли sitemap формально є, але всередині змішані нормальні 200-сторінки, редиректи, 404, параметричні URL, noindex-розділи і дублікати. Для Google це не допомога, а зайвий шум.

  • Не додавайте в sitemap URL із редиректом, 404-сторінки та параметричні дублікати.

  • Не змішуйте в одному файлі канонічні й неканонічні версії сторінок.

  • Не оновлюйте <lastmod> автоматично для всіх URL, якщо контент насправді не змінювався.

  • Не сприймайте sitemap як заміну структурі сайту, навігації та внутрішній перелінковці.

  • Не очікуйте, що сама присутність сторінки в карті гарантує її індексацію.

Типова практична помилка — коли CMS автоматично додає в sitemap сторінки з canonical на інші URL. Формально вони є в карті, але як корисний сигнал для Google працюють погано. Саме тому sitemap треба не просто згенерувати, а перевірити вручну або в межах технічного SEO-аудиту сайту .

Висновок

Для невеликого сайту з чіткою структурою одного sitemap.xml зазвичай достатньо. Ускладнювати систему заради самого sitemap index немає сенсу. Але коли сайт росте, з’являються різні типи сторінок, мовні версії або десятки тисяч URL, файл-індекс стає зручним робочим інструментом.

Його головна перевага не в тому, що він «просуває» сайт, а в тому, що наводить порядок у роботі з індексацією. Google отримує чистішу структуру карт, а команда сайту — зрозуміліший контроль над тим, які URL реально подаються на обхід.

Щоб закрити тему повністю, варто також порівняти XML-карту з HTML-навігацією в матеріалі HTML карта: чи потрібна вона на сучасних сайтах .