Що sitemap.xml робить — і чого не робить
Sitemap.xml дає пошуковій системі список URL, які власник сайту вважає важливими. Це канал виявлення та додатковий сигнал про бажані canonical-адреси, але не команда обов’язково додати кожну сторінку в індекс.
Якщо URL повертає помилку, має noindex, веде canonical на іншу сторінку або майже не відрізняється від десятків сусідніх матеріалів, наявність у sitemap не виправить проблему. Спочатку приводять до ладу саму сторінку, а потім додають її у файл.
П’ять умов перед додаванням URL
Перед генерацією sitemap корисно застосувати один короткий фільтр. URL повинен відповідати 200 без ланцюга редиректів, бути дозволеним для індексації, містити self-canonical і мати хоча б один нормальний внутрішній шлях із навігації або пов’язаного матеріалу.
Остання умова редакційна: сторінка має давати самостійну відповідь. Якщо відмінність полягає лише в назві міста або послуги, краще посилити одну основну сторінку, ніж відправляти пошуковику серію майже однакових URL.
- HTTP 200 після всіх перенаправлень.
- Немає meta або X-Robots-Tag noindex.
- Canonical веде на цей самий доступний URL.
- Є контекстне внутрішнє посилання.
- Матеріал має окрему користь для відвідувача.
Мінімальна структура XML-файлу
Для звичайної HTML-сторінки достатньо абсолютної адреси в loc. lastmod варто додавати лише тоді, коли дата формується з реального суттєвого оновлення: зміни основного тексту, структури, даних або важливих посилань.
Для UA/EN сторінок можна додавати взаємні hreflang-посилання. Вони повинні описувати справжні мовні відповідники, а не вести всі версії на одну головну. priority і changefreq не варто використовувати як спосіб переконати Google, що слабка сторінка важливіша.
| Елемент | Практичне правило |
|---|---|
| loc | Абсолютний canonical URL із HTTPS |
| lastmod | Дата останньої суттєвої зміни |
| hreflang | Взаємні мовні відповідники |
| priority/changefreq | Не використовувати як заміну якості |
Як перевірити sitemap автоматично
Перевірка починається з парсингу всіх loc. Для кожного URL варто отримати фінальний HTTP-статус, robots-директиву та canonical. Після цього список порівнюють із фактично indexable сторінками сайту.
Окремо шукають URL, яких немає у внутрішній навігації, та внутрішні посилання через 301. Якщо сторінка доступна тільки з sitemap, це сигнал переглянути структуру, а не просто залишити її у файлі.
- Завантажити sitemap.xml з production.
- Перевірити кожен loc без автоматичного приховування redirect.
- Порівняти canonical, robots і HTTP-статус.
- Зіставити список із внутрішнім crawl.
- Повторити перевірку після deploy.
Що дивитися після подання в Search Console
У Search Console важливий не лише статус успішного читання файлу. Порівнюйте кількість надісланих URL, причини виключення та приклади сторінок, які Google вибрав або не вибрав для індексації.
Окремий URL діагностують через URL Inspection. Якщо Google обрав інший canonical, бачить noindex або не може завантажити важливий ресурс, виправлення роблять на сайті. Повторне подання того самого sitemap без зміни причини не дає нового результату.
Як це застосовано на Montana WebStudio
Sitemap Montana WebStudio генерується з фактичної indexability HTML. Сторінки з noindex, redirects або canonical-конфліктами не повинні потрапляти у список, а UA/EN пари отримують взаємні мовні посилання.
Після кожної контентної зміни файл перевіряється разом із robots.txt, canonical і внутрішніми посиланнями. Це дозволяє зменшити кількість сторінок у sitemap, коли матеріал потребує доопрацювання, не видаляючи сам URL із сайту.
Часті запитання
Чи гарантує sitemap індексацію сторінки?
Ні. Він допомагає виявити URL і показує бажані адреси, але Google окремо оцінює доступність, canonical, якість і самостійну користь сторінки.
Чи потрібно додавати noindex сторінки в sitemap?
Ні. Це суперечливі сигнали: файл пропонує URL для пошуку, а сторінка забороняє індексацію.
Коли змінювати lastmod?
Після суттєвої зміни основного контенту, структури або важливих даних. Зміна року у footer не є достатньою причиною.