Sitemap не ускоряет индексацию. Файл сообщает роботу список адресов и дату их изменения — и всё. Когда прийти и брать ли страницу в индекс, поисковик решает по своим сигналам: ссылкам, истории обхода, качеству контента. Карта на 100 000 URL с одинаковым lastmod в каждой строке ускоряет ровно ничего. Хуже: она приучает Googlebot не верить датам вообще.
Что работает: честный lastmod, который меняется только при правке контента; в файле только канонические адреса с кодом 200; ни одной строки с UTM, сортировкой или session id. Ниже — как это проверить командами и в отчётах Search Console и Вебмастера, а не «на глаз».
Google и Яндекс читают карту по-разному. Google берёт loc и lastmod, а priority и changefreq выбрасывает. Яндекс по справке учитывает все четыре тега, и priority у него влияет на очерёдность загрузки. Одна карта под обоих роботов — норма, но ожидания от неё разные.
Миф про «карту, которая ускоряет»
Миф родился в 2005 году вместе с протоколом Sitemap: тогда файл решал проблему обнаружения — робот физически не находил глубокие страницы каталога. Сейчас узкое место не обнаружение, а очередь: Googlebot знает про страницу, а статус «Обнаружена, не проиндексирована» висит неделями.
Справка Google по сборке sitemap говорит прямо: значения priority и changefreq игнорируются, а lastmod используется, только если он стабильно и проверяемо точен — робот сверяет дату с реальным изменением страницы. В блоге Google Search Central от июня 2023 года, в посте о закрытии ping-эндпоинта, уточнили, зачем это поле нужно: lastmod помогает планировать повторное сканирование уже известных URL.
Отсюда следствие, которого нет в типовых инструкциях. Дата в sitemap — не команда «приди», а заявление, которое проверят. Если генератор пишет в lastmod время сборки файла, каждая регенерация объявляет: «весь сайт изменился». Робот приходит, видит те же байты, и после нескольких таких циклов перестаёт учитывать поле для всего домена. Вы не «не помогли». Вы отключили единственный рабочий сигнал файла.
С canonical то же самое. Справка Google по объединению дублей ранжирует сигналы: редирект и rel=canonical — сильные, включение URL в sitemap — слабый. Карта с чистыми адресами подтверждает canonical, но не заменяет его. Когда в sitemap лежит /catalog/?sort=price, а canonical на странице ведёт на /catalog/, робот получил два противоречащих сигнала — и выберет сам.
Справка Google Search Central, «Создание и отправка файла Sitemap»: Google игнорирует priority и changefreq и использует lastmod, если значение стабильно и проверяемо точное; дата должна отражать последнее существенное изменение страницы.
Справка Яндекс Вебмастера, «Использование файла Sitemap»: робот загружает страницы поочерёдно с учётом наличия и значения priority от 0.0 до 1.0; lastmod и changefreq тоже поддерживаются, лимит на каждое значение — 100 байтов.
Почему sitemap не ускоряет индексацию, а порядок в нём — ускоряет: 7 проверок
Понадобятся: доступ к консоли с curl, Search Console и Яндекс Вебмастер. На сайт до 50 000 URL уходит около часа.
1. Выгрузите все URL из карты и посчитайте их.
Для одиночного файла:
curl -s https://example.ru/sitemap.xml | grep -oP '(?<=<loc>)[^<]+' > urls.txt
wc -l urls.txt
grep -c '?' urls.txtДля индексного файла сначала вытащите список дочерних карт тем же grep, затем прогоните каждую. Если консоли под рукой нет, бесплатный экстрактор URL из sitemap от SpeedyIndex отдаёт тот же список текстом, включая вложенные карты.
Смотреть сразу.
Успех: число строк совпадает с числом страниц, которые вы хотите видеть в индексе, плюс-минус несколько процентов, а grep по знаку вопроса вернул 0.
Провал: строк в 3–7 раз больше, чем страниц в CMS, — генератор тянет фильтры и пагинацию; в файле есть адреса с «?» — шаг 5 делайте раньше остальных.
2. Постройте распределение lastmod.
Одна команда:
curl -s https://example.ru/sitemap.xml | grep -oP '(?<=<lastmod>)[^<]+' | cut -c1-10 | sort | uniq -c | sort -rn | headСмотреть сразу.
Успех: даты размазаны — десятки значений, свежие статьи сверху, старые со старыми датами.
Провал: одна дата на 90 % строк и больше, и это сегодня или день последнего деплоя. Это время генерации, не правки. Дальше — в код генератора: Yoast и Rank Math берут дату из post_modified, там сбой редкость; самописные скрипты и плагины хостинга пишут текущее время в цикле — заменить на дату из базы.
Пока честной даты нет, уберите тег целиком: без lastmod робот придёт по своему расписанию, с ложным — перестанет верить.
3. Сверьте lastmod с реальной правкой на выборке.
Возьмите 10 URL с самым свежим lastmod и снимите заголовки:
curl -sI https://example.ru/blog/post/ | grep -iE 'HTTP/|last-modified'Откройте эти же страницы в CMS и посмотрите дату «Обновлено».
Смотреть сразу.
Успех: lastmod не позже даты правки в CMS и не позже сегодняшнего дня.
Провал: lastmod в будущем — сбита таймзона генератора; lastmod свежее правки — генератор пишет что-то своё. Search Console ругается только на нарушение формата ISO 8601, будущие даты она пропускает молча, но робот их не примет за правду. Заголовок Last-Modified с sitemap не связан — по протоколу это разные источники; но если сервер отдаёт в нём время запроса, чините и его: ломаются условные запросы If-Modified-Since.
4. Прогоните каждый URL на код ответа и canonical.
Скрипт по списку из шага 1:
UA='Mozilla/5.0 (Linux; Android 10) Googlebot'
while read u; do
code=$(curl -s -o /dev/null -w '%{http_code}' -A "$UA" "$u")
can=$(curl -s -A "$UA" "$u" | grep -oP '<link[^>]+rel="canonical"[^>]+href="\K[^"]+')
echo "$code $u $can"
done < urls.txt > audit.txt
awk '$1!=200' audit.txt
awk '$3!="" && $2!=$3' audit.txtСмотреть: тысяча URL — минут десять, крупный каталог — ночью.
Успех: обе выборки пустые, каждый адрес отдаёт 200 и ссылается сам на себя.
Провал делится на виды, и смешивать их нельзя. 301 — в файле старый адрес (http, без слеша, с www): замените строку на конечный URL, для индексации считается только он. 404 и 410 — строку удалить. 200 с noindex в meta или в X-Robots-Tag — удалить: noindex внутри карты противоречит сам себе. 200 с canonical на другой адрес — удалить дубликат и оставить тот, куда ведёт canonical.
UA-строку Googlebot ставьте обязательно: часть CDN отдаёт роботу не то, что человеку.
5. Разложите URL с параметрами по трём корзинам.
Список — из grep на шаге 1.
Корзина А: параметры, не меняющие контент — utm_*, gclid, yclid, ref, sessionid, sort, per_page.
Корзина Б: фильтры, дающие самостоятельные посадочные — /nozhi/?brand=victorinox с собственным H1 и текстом.
Корзина В: пагинация.
Настройка по корзинам:
А — из sitemap вон, rel=canonical на чистый адрес, для Яндекса — Clean-param: utm_source&utm_medium&utm_campaign&yclid&sort в секции User-agent: Yandex;
Б — оставить в карте, self-canonical, собственный текст, иначе это корзина А;
В — из карты убрать, canonical на саму страницу пагинации, не на первую, robots не закрывать.
Наблюдаемый выход: Вебмастер → Инструменты → Анализ robots.txt показывает директиву без ошибки; обычно через 2–4 недели в «Страницы в поиске» → «Исключённые» адреса с параметрами уходят в статус «Неканоническая» или пропадают.
Для Google инструмента «Параметры URL» нет с 2022 года — остаются canonical и внутренние ссылки только на чистые адреса.
Провал: анализатор пишет, что директива не будет учтена — синтаксис (пробел вместо &, параметр со знаком равенства) или директива стоит в общей секции при существующей секции Yandex: тогда Яндекс общую секцию игнорирует.
Disallow на параметры — только для мусора без ссылочного веса: Disallow режет обход, Clean-param склеивает показатели с чистым URL, и справка Яндекса сама советует второе.
6. Переотправьте карту и прочитайте два отчёта.
Search Console → Индексирование → Файлы Sitemap → отправить заново. Смотреть через час и через три дня.
Успех: статус «Успешно», «Обнаружено страниц» равно wc -l из шага 1.
Провал: «Не удалось получить» — файл закрыт в robots.txt, отдаёт 5xx или превышает лимит протокола 50 МБ / 50 000 URL, тогда дробите на индексный файл; обнаружено меньше, чем у вас, — часть строк робот отбросил как невалидные. Затем Индексирование → Страницы: строки «Страница является копией.
Канонический URL, выбранный Google, отличается от выбранного пользователем» и «Обнаружена, не проиндексирована» — по каждой открыть «Проверка URL» и сравнить канонический URL пользователя и Google. В Вебмастере: Индексирование → Файлы Sitemap — статус обработки и дата загрузки; «Страницы в поиске» → «Исключённые» с фильтрами «Дубль» и «Неканоническая».
7. Дожмите остаток руками, а не файлом.
После правок sitemap ничего не переиндексирует — он просто перестал мешать. Для страниц, которые через 14 дней всё ещё в «Обнаружена, не проиндексирована»: Яндекс → Индексирование → Переобход страниц — вставить список в пределах дневной квоты, она видна там же; плюс IndexNow, который Яндекс поддерживает, а Google — нет.
Google → «Проверка URL» → «Запросить индексирование» для приоритетных страниц, либо сторонний сервис отправки с контрольной проверкой через неделю.
Смотреть: Яндекс — обход обычно в течение 1–3 дней, виден в «Статистика обхода»; Google — статус в «Проверка URL» обычно через 3–7 дней. Успех: «URL в индексе Google» / страница в разделе «Страницы в поиске».
Провал: страница вернулась со статусом «Просканирована, но пока не проиндексирована» — это уже не про sitemap, а про контент и ссылки на неё.
Что реально двигает очередь: сравнение методов
| Метод | Кому подходит | Ожидаемая скорость | Риск | Когда НЕ использовать |
|---|---|---|---|---|
| Sitemap с честным lastmod | Любой сайт от 500 страниц | Переобход изменённых страниц раньше остальных; новые URL — по общей очереди | Один ложный цикл — и поле обесценивается для домена | Когда генератор не умеет брать дату из базы: лучше без lastmod |
| Sitemap с lastmod «сегодня на всех» | Никому | Ноль; после 2–3 циклов — минус | Google перестаёт учитывать даты; бюджет уходит на старые страницы | Всегда |
| rel=canonical на чистый URL | Параметры, пагинация, версии с www/слешем | Склейка обычно за 2–6 недель (оценка по практике, не гарантия) | Сильный сигнал, но не приказ — Google может выбрать другой канонический | Когда страницы содержательно разные: canonical на несходный контент Google отвергает |
| Clean-param (Яндекс) | Параметры трекинга и сортировок | Склейка дублей обычно за 2–4 недели после переобхода (оценка) | Лишний параметр в директиве склеит разные страницы | Для фильтров с собственным контентом; для Google — не читается |
| Disallow параметров в robots.txt | Мусорные URL без входящих ссылок | Прекращение обхода сразу | Ссылочный вес на закрытых URL пропадает; Google может индексировать URL без контента | Когда на адреса с параметрами есть внешние ссылки |
| Переобход / URL Inspection | Единичные приоритетные страницы | Яндекс: 1–3 дня; Google: 3–7 дней до статуса (типичные сроки) | Квота в день; на решение «не индексировать» не влияет | Для сотен URL в день — не масштабируется |
| IndexNow | Сайты с частыми обновлениями | Яндекс и Bing — быстрый сигнал об изменении | Ничего не даёт для Google | Как единственный канал под Google |
Типовые сбои: где ломается даже правильный файл
lastmod равен времени генерации. Google сверяет дату с реальным изменением страницы — это в справке. Значит, ложные даты не «бесполезны», а вредны: робот учится не верить. Распространённое утверждение «поставьте lastmod на всех, чтобы робот чаще заходил» работает с точностью до наоборот.
Проверка — команда из шага 2.
Индексный файл с датами, а дочерние карты — без. У индексного sitemap свой lastmod на каждый дочерний файл, и он обозначает, когда менялся сам файл, а не страницы внутри. Утверждение «достаточно lastmod в индексе» ложно: робот по нему решает, открывать ли дочернюю карту, а очерёдность страниц внутри читает из их собственных дат.
Нет дат внутри — нет и приоритета.
Две карты от двух генераторов. SEO-плагин пишет /sitemap_index.xml, панель хостинга — /sitemap.xml, обе указаны в robots.txt. Даты и списки в них расходятся. Вопрос на Хабр Q&A ровно об этом: после смены темы WordPress хостинговый генератор набил карту URL с сортировками, и сотрудник Яндекса в ответе посоветовал отключить лишний генератор и вычистить файл руками.
Проверка: сравните wc -l двух файлов; оставьте один.
Self-canonical на адрес, которого нет. Страница отдаёт 200 по https://example.ru/page/, а в canonical стоит http://example.ru/page — адрес с 301. Робот получает canonical, ведущий на редирект, и такой сигнал он не считает надёжным. В отчёте Search Console это оседает как «Страница является копией. Канонический URL, выбранный Google, отличается от выбранного пользователем».
Проверка — awk '$2!=$3' из шага 4.
Параметры, которые вы не создавали. Практики на форумах отмечают: адреса с yclid и параметрами из рекламных систем появляются в Вебмастере сами, через переходы, а не через ваши ссылки. Тезис «у нас нет параметров, мы их не генерируем» проверяется отчётом «Исключённые» → «Дубль».
Clean-param закрывает класс целиком: Clean-param: yclid&gclid&fbclid без указания пути действует на весь сайт.
Canonical на первую страницу пагинации. Раньше советовали ставить canonical со всех ?page=N на /catalog/. Google это отвергает: контент страниц разный, canonical на несходную страницу робот проигнорирует, а товары со второй и дальше страниц останутся без канонического пути к индексации.
Правильно — self-canonical на каждой странице пагинации и её отсутствие в sitemap.
Вопросы, которые остаются после чтения инструкций
В: Нужно ли вообще писать lastmod в sitemap, если сайт статичный и меняется раз в квартал?
О: Нужно, там он работает лучше всего: даты стоят месяцами, а при правке одной страницы меняется одна строка — робот видит контраст и приходит за ней.
В: Стоит ли класть в sitemap URL с параметрами фильтров, если по ним есть спрос?
О: Да, если у страницы фильтра есть self-canonical, собственный H1 и текст, и она не закрыта в robots.txt. Три условия сразу. Нет любого из них — страница поедет в «Неканоническая» у Яндекса или в «Копия» у Google, и в карте она только шумит.
В: Sitemap и rel=canonical противоречат друг другу. Кто победит?
О: По справке Google включение в sitemap — слабый сигнал, rel=canonical — сильный, редирект — ещё сильнее. Победит canonical, но не всегда: если внутренние ссылки массово ведут на адрес из sitemap, Google может выбрать его. Приведите все три к одному адресу, тогда спорить нечему.
В: Clean-param или Disallow для UTM-меток в Яндексе?
О: Clean-param. Справка Яндекса объясняет разницу: Disallow только запрещает обход, а Clean-param склеивает адреса и передаёт накопленные показатели основному URL. Для рекламных меток, на которые ведут внешние ссылки, потеря веса при Disallow реальна.
В: Что делать с параметрами для Google, если инструмента «Параметры URL» больше нет?
О: Три вещи: self-canonical на чистом адресе и canonical с параметризованных версий на него; внутренние ссылки только на чистые адреса; в sitemap — только чистые адреса. Google сам склеивает большинство трекинговых параметров, но подтверждение с вашей стороны сокращает время склейки.
В: Как понять, что Google перестал верить моему lastmod?
О: Прямого индикатора в Search Console нет. Косвенный: в «Статистике сканирования» пики обхода не совпадают с датами ваших правок, а в «Проверке URL» дата последнего сканирования у свежеобновлённых страниц старше lastmod на недели. Тогда чините генератор и ждите несколько циклов переобхода — сроки возврата доверия поисковик не публикует.
План на 10 минут
Откройте консоль и выполните команды из шагов 1 и 2 для главной карты: два числа — сколько URL и сколько разных дат. Если дат меньше пяти на сайте от тысячи страниц — генератор врёт, и это ваша первая задача на неделю. Затем Search Console → Индексирование → Страницы: посчитайте строки в «Копия, канонический URL выбран Google» и «Обнаружена, не проиндексирована»; запишите цифры с датой — через месяц после правок sitemap и canonical они должны уменьшиться.
И в Вебмастере: «Страницы в поиске» → «Исключённые» → фильтр «Дубль» — если там больше 5 % от числа страниц в поиске, начинайте с Clean-param, а не с sitemap.
