Sitemap.xml для Яндекса и Google: как собрать правильно и где обычно ломают

Как устроена карта сайта, какие лимиты и форматы реально проверяются поисковиками, что лежать в sitemap должно, а что нет, и почему «правильный» sitemap чаще всего ломает один-единственный неправильный lastmod

Простой формат, в котором всё равно ошибаются

Sitemap.xml — один из самых незатейливых файлов, которые отдаёт сайт. Открытая спецификация на десять страниц, формат поддерживают все поисковики с середины 2000-х, валидаторов и генераторов — полтора десятка. Сделать «правильный» sitemap, на первый взгляд, проще, чем настроить .htaccess.

На практике — нет. Аудиты показывают одно и то же: файл валидный, лимиты соблюдены, robots.txt отдаёт правильный путь, в Search Console зелёный статус — а половина URL не индексируется, переобход тормозит, новые страницы по 3–6 часов ждут в очереди. Чаще всего причина не в самом XML, а в одном из трёх мест: что именно вы туда положили, как часто меняется lastmod и совпадает ли он с реальностью. Такие расхождения быстрее всего вскрывает регулярный SEO-аудит.

Дальше — что такое sitemap по существу, какие лимиты и форматы реально проверяются Google и Яндексом, что должно быть в файле, а чего быть не должно, как поле lastmod становится сигналом доверия или быстро его теряет, и подробный разбор десяти самых частых ошибок.

Что такое sitemap.xml и зачем он нужен

Sitemap.xml — это XML-файл, в котором сайт сам перечисляет поисковику свои значимые URL и сообщает, когда они обновлялись. Формат описан в открытой спецификации sitemaps.org, его поддерживают Google, Яндекс, Bing и все остальные крупные поисковики.

Минимальный sitemap выглядит так:

Обязательное здесь — только тег <loc> с абсолютным URL. Всё остальное (lastmod, changefreq, priority) технически опционально, но именно вокруг этих полей крутится большинство ошибок и заблуждений.

Распространённый вопрос: «поисковики и так найдут мои страницы по ссылкам, зачем sitemap?». Найдут — но не все, не сразу и не в том порядке, который вам нужен. Sitemap особенно важен, если:

• сайт большой и часть страниц лежит глубоко (3+ кликов от главной);
• сайт новый, на него ещё мало внешних ссылок;
• контент обновляется часто (новости, маркетплейс, агрегатор);
• есть страницы без перелинковки (одиночные landing, фильтры, теги);
• сайт работает на JavaScript-фреймворке, и часть навигации поисковику не видна без рендеринга.

Жёсткие лимиты, которые легко пропустить

На один файл sitemap есть два лимита, и оба сформулированы поисковиками одинаково:

Два момента, которые часто упускают:

1. Лимит 50 МБ — это распакованный размер. gzip разрешён и приветствуется (Google и Яндекс читают .xml.gz), но 50 МБ считаются именно по исходному XML. Если ваш sitemap в gzip весит 5 МБ, а в распакованном виде — 70 МБ, поисковик просто не прочтёт его.

2. Один URL в среднем весит около 100–200 байт. На практике лимит 50 МБ всегда упирается в количество URL раньше, чем в размер. Если вы вышли за 50 000 URL — пора разбивать на несколько sitemap.

Sitemap index: как разбить большой сайт

Если сайт перевалил за 50 000 URL, нужен sitemap index — XML-файл, который перечисляет другие sitemap-файлы:

Внешний файл обычно называют sitemap.xml и кладут в корень, а тематические — sitemap-products.xml, sitemap-blog.xml, sitemap-2026-05.xml и так далее. Логика разбиения может быть какой угодно: по разделам, по дате, по типу контента.

Чего нельзя делать: вкладывать sitemap index в другой sitemap index. Спецификация это запрещает, и поисковики не пойдут глубже одного уровня. Если у вас получается «индекс индексов», значит, структуру надо упрощать.

Полезный паттерн для интернет-магазинов и каталогов: один sitemap на 10–20 тысяч URL, а не на 50 тысяч. Тогда переобновление одного раздела не дёргает индексацию всего сайта, и поисковику легче определить, какие именно подмножества URL обновились.

Какие URL должны быть в sitemap, а какие — нет

Главное правило, из которого следует половина оптимальной стратегии: в sitemap кладутся только канонические, индексируемые, рабочие URL. Всё остальное — либо вредит, либо бесполезно.

Должны быть:

• страницы, отвечающие 200 OK;
• только каноническая версия (та, на которую указывает rel="canonical");
• страницы, открытые для индексации (не noindex, не закрытые в robots.txt);
• тот же протокол и хост, что у самого файла sitemap (нельзя класть http:// URL в sitemap, лежащий по https://);
• кириллические домены — в punycode (xn--80akhbyknj4f.xn--p1ai), кириллица в пути — percent-encoded.

Не должны быть:

• URL, отдающие 301/302 — кладите сразу финальный адрес, без редиректов;
• URL с 404, 410, 5xx;
• URL с noindex или X-Robots-Tag: noindex;
• страницы, закрытые в robots.txt (конфликт: вы одновременно говорите «индексируй» и «не ходи»);
• страницы с UTM-метками, сортировками, фильтрами, пагинацией — обычно это дубли канонической;
• служебные страницы (личный кабинет, корзина, страницы поиска);
• тестовые поддомены и stage-окружения.

lastmod — поле, которое почти все портят

Из трёх опциональных полей (lastmod, changefreq, priority) только одно реально влияет на работу поисковика — это lastmod. И именно его чаще всего ставят неправильно.

Формат строгий: либо дата (2026-05-17), либо полная дата-время в W3C datetime (2026-05-17T14:32:10+03:00). Никаких dd.mm.yyyy, Unix timestamp’ов или «вчера» — парсер просто проигнорирует поле.

Google публично подтвердил, что использует lastmod как сигнал для приоритизации обхода — но только если доверяет сайту в этом. Доверие зарабатывается тем, что дата действительно соответствует последнему значимому изменению контента. Доверие теряется одним выстрелом: если поисковик пришёл и обнаружил, что заявленных изменений нет.

Что считается «значимым изменением»:

• изменился основной текст материала;
• добавились или удалились ключевые блоки (товары в категории, ответы под вопросом);
• поменялись цена, наличие, основные характеристики (для коммерческих страниц);
• обновился заголовок, лид, meta-теги.

Что не считается изменением:

• появился новый комментарий или отзыв;
• обновился счётчик просмотров, лайков, шеров;
• пересобрался футер или сквозной блок «похожие материалы»;
• сменился JS-бандл или версия CSS.

Главный антипаттерн — история из начала статьи: ставить lastmod = now() при каждом запросе. Это самый быстрый способ заставить поисковик игнорировать поле и обходить сайт по своему графику.

changefreq и priority — реликты

Эти два поля остались в спецификации с 2005 года, и они почти не работают.

changefreq (значения: always, hourly, daily, weekly, monthly, yearly, never) — подсказка, как часто страница меняется. Google официально его игнорирует. Яндекс рекомендует указывать, но в реальном расписании обхода это поле тоже скорее декоративное.

priority (значения от 0.0 до 1.0) — относительный приоритет URL внутри сайта. Google игнорирует. Яндекс декларативно учитывает, но никаких подтверждений влияния на ранжирование никогда не было.

На практике: смело пропускайте changefreq и priority. Они никому не помогают, занимают место в файле и создают ложное чувство контроля. Оставьте только loc и lastmod — этого хватит.

Как отдать sitemap поисковикам

Готовый файл нужно «представить» Google и Яндексу — иначе он будет просто XML на сервере, который никто не читает. Способов три, и их желательно использовать одновременно.

1. Через robots.txt. Самый надёжный способ — и единственный, который работает «сам по себе» для всех поисковиков сразу:

URL обязательно абсолютный. Можно перечислить несколько строк Sitemap: — например, отдельно для основного контента и отдельно для изображений.

2. Через Google Search Console. Раздел «Файлы Sitemap» → добавить URL. Google покажет, сколько URL обработано, сколько проиндексировано, какие ошибки нашёл.

3. Через Яндекс.Вебмастер. «Индексирование» → «Файлы Sitemap» → добавить URL. Логика та же: статус, статистика, диагностика.

HTTP-требования: статус, заголовки, скорость

Sitemap должен быть доступен по конкретным правилам. Любое отклонение — и поисковик считает его «битым».

Проверить заголовки можно одной командой:

Если в ответе видите 301 Moved Permanently или Content-Type: text/html — sitemap нужно чинить, прежде чем класть в Search Console.

Специализированные sitemap: image, video, news, hreflang

Кроме основной карты сайта спецификация предусматривает несколько расширений с дополнительными namespace’ами. Они нужны не всем, но в нужных случаях дают заметный прирост к видимости.

Image sitemap. Позволяет явно указать поисковику изображения, к которым относится страница — полезно, если картинки подгружаются JavaScript’ом или важна Яндекс.Картинки/Google Images. Подключается прямо в основном sitemap:

Video sitemap. То же самое для видео: длительность, миниатюра, описание, рейтинг. Нужно, если у вас есть собственный видеохостинг или важна выдача в Google Videos.

News sitemap. Отдельный формат для сайтов, подключённых к Google News. Содержит только материалы за последние двое суток, без lastmod, зато с обязательным publication_date. Если у вас не СМИ — этот sitemap не нужен.

hreflang в sitemap. Если у сайта несколько языковых версий, языковые альтернативы можно объявить прямо в sitemap через xhtml:link rel="alternate" — это удобнее, чем дублировать теги на каждой странице.

Топ-10 ошибок, которые встречаются в большинстве sitemap

За годы аудитов набирается узнаваемый список грабель. Если вы только что собрали или перенастроили sitemap — пройдитесь по нему как по чек-листу.

1. lastmod равен текущей дате на каждом запросе. Самая дорогая ошибка из всех. Поисковик быстро перестаёт доверять полю и начинает игнорировать его на всём сайте.

2. В sitemap есть страницы, закрытые в robots.txt. Конфликт сигналов: вы одновременно говорите «вот мои важные страницы» и «не ходи на них». Поисковик в лучшем случае проигнорирует sitemap, в худшем — снизит общее доверие.

3. В sitemap есть URL, отдающие 301/302. Поисковик пройдёт цепочку редиректов, но это медленно и расходует crawl budget. Кладите сразу финальный URL.

4. В sitemap есть URL с noindex. То же, что пункт 2: противоречивые сигналы. Если страница в noindex — её не должно быть в sitemap.

5. Не та каноническая версия. В sitemap — https://www.example.ru/page, а каноническая — https://example.ru/page (без www). Каждая такая запись — впустую потраченный обход.

6. Sitemap сам отдаётся через 301. Часто бывает на старых сайтах: http://example.ru/sitemap.xml редиректит на https://example.ru/sitemap.xml, а в robots.txt прописан старый URL. Search Console честно покажет ошибку, а вы будете гадать, почему «всё валидно, но не работает».

7. Файл больше 50 МБ распакованного. Часто прилетает после миграции на новый каталог. Лечится разбиением на sitemap index.

8. Sitemap не указан в robots.txt. Если он есть только в Search Console / Вебмастере, его не увидят боты других поисковиков (Bing, DuckDuckGo, Mail.ru). robots.txt — единственный универсальный канал.

9. Кириллица не закодирована. URL в sitemap должны быть либо в ASCII, либо в percent-encoding. https://сайт.рф/раздел/ вылетит с ошибкой, нужно https://xn--80aswg.xn--p1ai/%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB/. Большинство современных фреймворков делает это автоматически, но самописные скрипты часто забывают.

10. Sitemap собирается «на лету» и отдаётся 15+ секунд. Когда в sitemap 80 000 URL и каждый запрос идёт в БД, поисковик может просто отвалиться по таймауту. Лечится: кэшировать готовый XML на диск и перегенерировать раз в N часов фоном — а не на каждый запрос.

Как проверить, что sitemap живой

Минимальный набор проверок, который имеет смысл прогонять и при выкатке, и периодически — вручную или через автоматическую проверку SEO-параметров:

Локально:

• открыть https://yoursite.ru/sitemap.xml в браузере — должен показаться XML, без ошибок парсинга;
• curl -I https://yoursite.ru/sitemap.xml — статус 200, Content-Type правильный;
• curl -s https://yoursite.ru/sitemap.xml | xmllint --noout - — валидация XML на синтаксис;
• прогнать через любой онлайн-валидатор sitemap (Google «XML Sitemap Validator»).

В поисковых системах:

• Google Search Console → Sitemaps: статус «Success», количество обнаруженных URL близко к ожидаемому;
• Яндекс.Вебмастер → Индексирование → Файлы Sitemap: статус «ОК», ошибок нет;
• в обоих сервисах посмотреть динамику: количество URL «в индексе» vs «обнаружено в sitemap».

В работе: sitemap — такой же критический ресурс, как и главная страница. Если он отвалился на 12 часов, поисковик не получит обновлений и индексация просядет. Поэтому имеет смысл мониторить его доступность и валидность отдельной проверкой в сервисе мониторинга сайтов — ровно тем же способом, которым следите за самим сайтом. В Пруфене для этого подходит обычная проверка GET с подстрокой <urlset или <sitemapindex в теле ответа: если файл вдруг отдаст HTML с заглушкой или ошибку — вы узнаете об этом за минуты, а не когда позиции начнут проседать.

Коротко: что сделать сегодня

• Откройте свой sitemap в браузере и проверьте, что он валидный XML.
• Убедитесь, что lastmod — это настоящая дата последнего изменения, а не текущая дата.
• Уберите из sitemap всё, что отдаёт 301/302/404 или закрыто в robots.txt и noindex.
• Пропишите абсолютный URL в robots.txt: Sitemap: https://….
• Добавьте sitemap в Google Search Console и Яндекс.Вебмастер, дождитесь статуса «успешно обработан».
• Если URL больше 50 000 — разбейте на sitemap index с тематическими файлами.
• Уберите changefreq и priority, если они там есть. Не несут смысла, только засоряют файл.
• Поставьте sitemap на мониторинг доступности — не реже раза в 5–10 минут.

Sitemap.xml — технически простой инструмент, но он работает только когда сделан честно. Половина проблем с индексацией, которые годами «непонятно почему», лечится одним правильным lastmod и чистым списком канонических URL. Сделайте это один раз аккуратно — и поисковик ответит вам быстрой и предсказуемой индексацией.