Sitemap.xml: що додавати, типові помилки та як перевірити файл

Карта сайту в форматі XML описана в протоколі на sitemaps.org. Це список адрес у кодуванні UTF-8, до кожної з яких можна додати дату останньої зміни. Пошукові системи читають його як підказку: «ось сторінки, які ми вважаємо важливими».

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

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

Найпростіший коректний sitemap виглядає так:

<?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-10-24</lastmod>
  </url>
  <url>
    <loc>https://example.com/pricing</loc>
    <lastmod>2026-09-02</lastmod>
  </url>
</urlset>

Обов'язковий лише елемент loc усередині url. Правила з протоколу такі:

• кодування UTF-8, спеціальні символи в адресах екрановані (наприклад, & замість &);
• адреси абсолютні, з протоколом і хостом: https://example.com/page, а не /page;
• в одному файлі не більше 50 000 адрес і не більше 50 МБ до стиснення;
• файл може бути стиснений у .xml.gz, але ліміт 50 МБ рахується для розпакованого вмісту;
• sitemap, що лежить у підкаталозі, за протоколом може описувати лише адреси цього підкаталогу та глибше.

Хост і протокол в адресах мають збігатися з сайтом. Якщо сайт працює на https://example.com, то записи з http:// або www. будуть помилкою.

Правило просте: у sitemap потрапляють лише ті адреси, які ви хочете бачити в індексі. Кожна має відповідати кільком умовам.

• Код відповіді 200. Ніяких редиректів і 404.
• Сторінка індексується: на ній немає noindex у мета-тегу чи в заголовку X-Robots-Tag.
• Адреса є канонічною. Якщо сторінка вказує canonical на іншу адресу, у файлі має бути саме ця інша адреса. Докладніше про це в статті про canonical.
• Адреса не заблокована в robots.txt. Інакше ви одночасно просите знайти сторінку й забороняєте її відкривати. Як писати правила, описано в посібнику з robots.txt.
• Немає службових адрес: пошуку по сайту, фільтрів із параметрами, сторінок кошика, чернеток.

Що виключати найчастіше

Зазвичай зайвими виявляються пагінація, яку CMS додає автоматично, архіви тегів з однією записаною сторінкою, дублікати з параметрами ?utm_source= та сторінки подяки після форм. Якщо ви сумніваєтеся, чи потрібна сторінка в пошуку, їй не місце й у sitemap.

Окремо для зображень, відео та новин існують розширення протоколу. Їх варто підключати лише тоді, коли такі матеріали для вас справді важливі.

Поле lastmod містить дату останньої суттєвої зміни сторінки у форматі W3C: 2026-10-24 або повний варіант із часом і часовим поясом. Google, за його документацією, враховує це значення лише тоді, коли воно стабільно й перевірювано точне. Тобто якщо дата справді відображає зміну вмісту, вона допомагає вирішувати, що переглянути вдруге.

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

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

Поля priority та changefreq Google ігнорує, це зазначено в його документації. Писати їх можна, якщо їх вимагає інша система, але ніякого впливу на пошук від них очікувати не варто. Файл без них не гірший.

Якщо дат у вас немає взагалі, краще пропустити lastmod, ніж підставляти поточний день.

Коли адрес більше за 50 000 або файл важчий за 50 МБ, його потрібно розділити. Для цього створюють індексний файл, який посилається на окремі sitemap:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-10-24</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-10-20</lastmod>
  </sitemap>
</sitemapindex>

Розбивати корисно й до досягнення ліміту. Окремі файли для сторінок, блогу та товарів дозволяють у Search Console бачити, яка група адрес проблемна. Індексний файл можна додавати в robots.txt і подавати в Search Console так само, як звичайний sitemap, а вкладені файли додавати вже не потрібно. Деталі наведено в документації Google про великі sitemap.

Для малого сайту з кількох десятків сторінок один файл цілком достатній. Не ускладнюйте структуру без потреби.

Якщо сайт багатомовний, зв'язки між версіями можна описати прямо у sitemap замість тегів у head. Для цього підключають простір імен xhtml, а кожен запис url перелічує всі альтернативи, у тому числі себе. Нижче приклад для української версії в корені та версій /en й /es:

<?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="uk" href="https://example.com/pricing"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/pricing"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
  </url>
  <url>
    <loc>https://example.com/en/pricing</loc>
    <xhtml:link rel="alternate" hreflang="uk" href="https://example.com/pricing"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/pricing"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
  </url>
  <url>
    <loc>https://example.com/es/pricing</loc>
    <xhtml:link rel="alternate" hreflang="uk" href="https://example.com/pricing"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/pricing"/>
    <xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/pricing"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
  </url>
</urlset>

Головне правило взаємності: якщо сторінка А вказує на Б, то Б повинна вказувати на А. Код мови для української — uk, а не ua. Решту типових помилок, зокрема питання x-default, зібрано в посібнику з hreflang. Не змішуйте два способи для однієї сторінки без потреби: достатньо тегів у head або запису в sitemap.

Ось що трапляється найчастіше.

• Застарілі адреси. Сторінку видалили або перенесли, а в файлі вона лишилася. Пошуковик отримує 404 або редирект і знижує довіру до всього списку.
• Неправильний протокол чи хост. Сайт переїхав на HTTPS, а sitemap досі перелічує http://. Те саме з варіантами www та без нього.
• Дата збирання замість дати зміни. Описано вище: усі lastmod однакові й оновлюються при кожному деплої.
• Закриті адреси. Сторінки з noindex або під забороною в robots.txt не повинні потрапляти у файл.
• Адреси з параметрами. Фільтри, сортування, сесійні ідентифікатори створюють сотні дублікатів.
• HTML замість XML. За адресою /sitemap.xml віддається сторінка 404 з кодом 200 (так звана м'яка 404) або редирект на головну. Для користувача це виглядає як сторінка, а для пошуковика як зламаний файл.
• Файл завеликий. Перевищено 50 000 адрес або 50 МБ, і частина записів ігнорується.
• Нічого не оголошено. Файл існує, але ніхто про нього не знає: його немає ні в robots.txt, ні в Search Console.

Як оголосити sitemap

Найпростіший спосіб, окрім Search Console, — рядок у robots.txt:

User-agent: *
Disallow: /admin/

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

Рядок Sitemap не залежить від груп User-agent і має містити повну абсолютну адресу.

Не потрібні дорогі інструменти. Достатньо такого порядку.

1. Відкрийте файл у браузері. Має відобразитися XML, а не сторінка сайту.
2. Перевірте заголовки відповіді командою curl -I https://example.com/sitemap.xml. Очікуємо код 200 і тип вмісту XML:

HTTP/2 200
content-type: application/xml

1. Додайте файл у звіт «Файли Sitemap» в Google Search Console і порівняйте кількість надісланих адрес із кількістю виявлених. Велика різниця — привід шукати проблему.
2. Виберіть п'ять–десять адрес із різних частин файлу, відкрийте їх і переконайтеся, що вони віддають 200, не мають noindex і що canonical вказує на них самих.
3. Переконайтеся, що файл оголошено в robots.txt.

Те саме частково автоматизує безкоштовний сканер. Він шукає sitemap за адресою /sitemap.xml та в одному sitemap того самого хоста, оголошеному в robots.txt, повідомляє, якщо файл відсутній, порожній, не оголошений або не містить lastmod, помічає адреси з http чи з чужим хостом і запитує три адреси з файлу (першу, середню й останню), щоб побачити, чи вони відповідають. Він пасивний: читає до 200 КБ файлу, не перевіряє весь файл за схемою і не сканує кожну адресу. Це перевірка для швидкого огляду, а не заміна Search Console. Сканер входить до SEO-аудиту, а питання безпеки охоплює перевірка безпеки. Якщо вас цікавить видимість для ШІ-пошуку, дивіться готовність до ШІ-пошуку.