Sitemap - це той файл на вашому сайті, який ніхто ніколи не перечитує.
Хтось налаштував його багато років тому, ймовірно через плагін, і відтоді він тихо повідомляє пошуковим системам, що сканувати. Він працює, тому ніхто його не відкриває.
Ми відкрили 21 такий файл — від IKEA, Booking.com, Stripe, Shopify, Zillow, Goodreads, wikiHow і ще десятка інших — і перевірили кожен за самим протоколом sitemap.
Вісім були чистими. Тринадцять - ні.
Один із цих тринадцяти був наш.
Результати стисло
Майже все, що ми знайшли, пояснюється двома проблемами, і обидві невидимі ззовні: поля, які нічого не роблять, і URL, які файл технічно не має права охоплювати.
Жодна з них не зламає ваш сайт. Обидві варті десяти хвилин.
Що ми перевіряли і як
Ми брали robots.txt кожного сайту, переходили за першим sitemap, який він оголошував, відкривали один реальний файл URL за ним і ставили три запитання.
Чи кожен URL розташований усередині власної папки sitemap? Протокол каже, що sitemap охоплює власний шлях і все нижче. Файл у /sitemaps/, який перелічує сторінки в /products/, виходить за ці межі.
Чи містить він priority або changefreq? Обидва є коректним XML, і обидва Google ігнорує. Це залишки з 2005 року.
Чи містить він читабельний lastmod? Ось це Google використовує, коли довіряє вам.
Потім ми прогнали кілька тих самих файлів через наш власний XML Sitemap Generator, який виконує саме ці перевірки, щоб переконатися, що наше прочитання і висновок інструмента збігаються. Вони збіглися.
Лише 8 із 21 були чистими
Чисті вісім: Omni Calculator, Healthline, Coursera, Vercel, Netlify, MongoDB, Semrush і Similarweb.
Інші тринадцять: wikiHow, Calculator.net, NerdWallet, Goodreads, GeeksforGeeks, Zillow, Booking.com, IKEA, Stripe, Shopify, HubSpot, Atlassian — і UNmiss.
У цьому поділі є закономірність, та сама, яку ми побачили, коли перевіряли, хто публікує llms.txt: компанії з інструментами для розробників охайні, а великі споживчі сайти на старіших контентних системах - ні.
Поля, які нічого не роблять
Вісім із 21 sitemap містять <priority>. Вісім містять <changefreq>.
Обидва теги були частиною початкової специфікації sitemap 2005 року. Ідея була в тому, що ви повідомляєте пошуковим системам, які сторінки найважливіші й як часто вони змінюються, а сканування планується відповідно.
Це не пережило зустрічі з реальністю, бо кожен сайт казав, що кожна сторінка має priority 1.0 і змінюється щодня. Google прямо ігнорує обидва поля. Вони досі є коректним XML. Вони просто нічого не роблять.
На малому сайті це нешкідливий шум. На великому - ні. Product sitemap IKEA має 47.6 MB при жорсткому ліміті протоколу 50 MB — і кожен запис у ньому витрачає байти на два поля, які ніхто не читає.
URL поза власною папкою
Десять із 21 перелічують URL, які розташовані поза власною директорією sitemap. Це цікавіша помилка, бо майже ніхто не знає, що таке правило існує.
Sitemap має охоплювати лише власний шлях і все нижче. Розмістіть файл за адресою example.com/sitemaps/products.xml, і технічно він охоплює /sitemaps/ та нижче — не /products/ і не вашу головну сторінку.
На практиці Google поблажливий, особливо коли ви надсилаєте sitemap напряму в Search Console. Але "зазвичай пробачають" - гірша позиція, ніж "коректно", а виправлення є найпростішим у SEO: перемістіть файл у корінь домену. Sitemap за адресою example.com/sitemap.xml охоплює все, завжди, без винятків, які треба пам'ятати.
Ми провалили власну перевірку
Тепер незручна частина і причина, чому ми впевнені, що решта цього матеріалу чесна.
Ми прогнали unmiss.com через наш власний XML Sitemap Generator. Він повідомив: 370 URL, 399.5 KB, HTTP 200, із читабельним lastmod у кожному записі — а потім позначив ось це:
370 записів містять priority або changefreq.
"Google прямо ігнорує обидва поля. Вони коректні, але просто нічого для вас не роблять."
Кожен окремий URL. Це видно в сирому файлі, де після кожного запису йде дата, слово weekly і число 0.7:
Ніхто свідомо цього не обирав. Воно прийшло з дефолту багато років тому й вижило, бо ніхто не відкривав файл знову — саме в цьому і суть статті.
Повторіть це за один день
Чотири кроки. Усе разом займає менше часу, ніж читання про це.
1. Відкрийте власний sitemap. Додайте /sitemap.xml до свого домену або знайдіть адресу у своєму robots.txt. Більшість людей ніколи не дивилися.
2. Пошукайте в ньому priority і changefreq. Якщо вони там є, приберіть їх. Недоліків і ризику немає; вони нічого не робили.
3. Перевірте, де лежить файл. Якщо він у підпапці, а ваші сторінки в іншому місці, перенесіть його в корінь. Один цей рух закриває цілу категорію проблем.
4. Переконайтеся, що lastmod чесний. Це єдине поле, яке досі має значення, і воно має значення лише тоді, коли правдиве. Файл, який стверджує, що все змінилося сьогодні, вчить пошукові системи ігнорувати це поле.
Що ми не могли виміряти
21 sitemap - це вибірка. Ми обрали впізнавані назви з видавництва, ритейлу, софту та інструментів для розробників і читали перший sitemap, який кожен сайт оголошував. Інша вибірка дала б інші відсотки.
Один файл на сайт. Деякі з цих компаній публікують тисячі файлів sitemap. Ми оцінювали один реальний файл URL від кожної, припускаючи, що їх генерує та сама система — це ймовірно, але не перевірено.
Path scope - це правило, яке Google зазвичай пробачає. Ми повідомляємо про нього, бо воно є в специфікації і бо наш інструмент його позначає, а не тому, що можемо показати втрату трафіку. Не можемо.
Ми не бачимо, що будь-яка пошукова система робить із цими файлами. Усе тут - це те, що сайти публікують, а не те, що сканується або індексується.
Вставте адресу sitemap, який ви вже публікуєте, і наш XML Sitemap Generator перевірить його за протоколом, не відвідуючи жодного URL усередині. Це та сама перевірка, яка знайшла проблему в нашому власному файлі й у десяти з двадцяти одного вище.
- Позначає URL поза власним шляхом sitemap
- Вказує на priority і changefreq, які Google ігнорує
- Повертає очищену копію, яку можна опублікувати сьогодні
Поширені запитання
Які sitemap ви перевіряли і якими були результати?
21 читабельний sitemap 23 серпня 2026 року. Чисті: Omni Calculator, Healthline, Coursera, Vercel, Netlify, MongoDB, Semrush, Similarweb. З принаймні однією проблемою: wikiHow, Calculator.net, NerdWallet, Goodreads, GeeksforGeeks, Zillow, Booking.com, IKEA, Stripe, Shopify, HubSpot, Atlassian і UNmiss. Десять перелічували URL поза власною папкою sitemap, вісім містили priority і вісім містили changefreq.
Чи роблять priority або changefreq хоч щось?
Не для Google, який прямо ігнорує обидва поля і чітко про це казав. Інші сканери можуть їх читати, але жодна велика пошукова система не зобов'язується діяти за будь-яким із них. Це коректний XML, який нічого не робить, і його видалення не несе ризику.
Чому має значення, де розташований файл sitemap?
Бо протокол каже, що sitemap охоплює лише власний шлях і все нижче. Файл у /sitemaps/products.xml технічно не охоплює /products/. Google загалом поблажливий, особливо до sitemap, надісланих у Search Console, але проблема повністю зникає, якщо покласти файл у корінь домену.
Чи є sitemap із такими проблемами зламаним?
Ні, і ми б не використовували це слово. Жоден із тринадцяти сайтів тут не має sitemap, який не працює. Вони містять поля, що марнують місце, а в десяти випадках - схему шляхів, яку специфікація строго не дозволяє. Це проблеми охайності, не аварії — саме тому вони живуть роками.
Ви знайшли проблему у власному sitemap. Яку саме?
Усі 370 URL в англійському sitemap unmiss.com містять priority і changefreq. Наш власний XML Sitemap Generator позначив це, коли ми спрямували його на себе. Воно прийшло з дефолту багато років тому, ніхто не відкривав файл знову, і це саме той патерн провалу, про який ця стаття.
А що з lastmod?
Ось це досі важливо. Google використовує lastmod, коли довіряє значенню, а довіра здобувається точністю. Кожен sitemap у нашій вибірці мав його фактично в кожному записі, і це добре — за умови, що дати реальні. Файл, який стверджує, що кожна сторінка змінилася сьогодні, вчить пошукові системи не зважати на це поле.
Наскільки великим може бути sitemap?
50,000 URL або 50 MB без стиснення, залежно від того, що настане першим; після цього його ділять на кілька файлів за індексом sitemap. Саме через цю межу марні поля мають значення в масштабі: product sitemap IKEA вже має 47.6 MB, тобто 95% ліміту, і водночас витрачає байти на два поля, які ніхто не читає.
Чи можу я запустити цю перевірку самостійно?
Так, у будь-який спосіб. Вручну: відкрийте свій robots.txt, перейдіть за sitemap і пошукайте у файлі priority та changefreq. Або вставте адресу в наш XML Sitemap Generator, який виконає ті самі перевірки й поверне виправлену копію.
Виправте файл, який ніхто не перечитує
Більша частина цієї серії - про компанії, які побудували щось видатне. RTINGS вимірює те, що ніхто не вимірює, wikiHow малює картинку для кожного кроку, Goodreads знайшов шістнадцять іменників там, де всі інші знайшли один.
Цей матеріал про протилежне: річ, яка є в кожного сайту і яку майже ніхто не переглядав удруге.
Тринадцять із двадцяти одного великого, добре забезпеченого ресурсами бізнесу публікують sitemap, у якому щось не так. Не тому, що це складно, а тому, що це невидимо. Файл працює, тому ніхто його не відкриває, тому дефолти 2005 року живуть вічно.
Ми були одним із цих тринадцяти й дізналися про це лише тоді, коли спрямували власний інструмент на себе.
Тож відкрийте свій sitemap. Це займає хвилину, і є чималий шанс, що ви не читали його з дня створення.
Перевірено 23 серпня 2026 року. Метод: отримати robots.txt кожного сайту, перейти за першим оголошеним sitemap, відкрити один реальний файл URL за ним і перевірити path scope, priority, changefreq та lastmod. Результати перехресно перевірялися нашим власним XML Sitemap Generator, який виконує ті самі перевірки, і обидва підходи збіглися.
Один файл на сайт - це вибірка, а не аудит кожного sitemap, який ці компанії публікують. Path scope - це правило специфікації, яке пошукові системи часто пробачають, і ми не стверджуємо, що будь-яка з цих проблем коштувала комусь трафіку.