Google не обязан находить все страницы сайта сам: робот идёт по ссылкам, и если раздел вложен глубоко или на него ведёт одна ссылка из подвала, обнаружение затянется на недели. Карта сайта решает эту задачу — но только если она корректно передана в Search Console и принята без ошибок.
Разберём три способа передать файл Google, что означает каждый статус в отчёте «Файлы Sitemap» и что делать с самыми частыми ошибками обработки. Если нужно сначала разобраться, как устроен сам файл, это в материале про sitemap и его структуру.
Зачем сайту нужен файл Sitemap для Google
Поисковый робот находит новое, переходя по внутренним связям. Если материал ни с чем не связан или лежит глубоко в структуре, его обнаружение затягивается. Карта сайта Google даёт прямой перечень и сокращает дорогу к обнаружению.
В руководстве Центра Google Поиска у карты статус скромный: это подсказка, не команда. Никто не обещает, что робот вообще заберёт документ и пустит его в дело, а на очерёдность строк внутри он не смотрит.
Второй эффект связан с краулинговым бюджетом. Он ограничен по объёму, и часть уходит на дубли, служебные разделы и цепочки переадресаций. Аккуратная карта показывает, что важно, поэтому силы распределяются разумнее.
При этом карта не даёт преимущества при ранжировании. Она влияет на обнаружение, а не на позиции в выдаче. Правильная структура, внутренняя перелинковка и корректные служебные директивы входят в технические требования к современному ресурсу наравне с картой.
Требования Google к файлу Sitemap: форматы, теги, лимиты
Google поддерживает три формата карты. XML самый универсальный, он расширяемый и содержит больше всего сведений, включая расширения для изображений, видео, новостей и локализованных версий. RSS, mRSS и Atom 1.0 – это фиды, которые CMS создаёт автоматически, минус в том, что они несут информацию только о свежих публикациях. Текстовый вариант с расширением .txt хранит по одной записи на каждой строчке и ограничен HTML и другим индексируемым контентом в виде текста.
Ни одному из форматов Google не отдаёт предпочтения, поэтому выбирают по возможностям движка и по составу данных, ведь изображения, видео и новости описывает только XML.
Потолок у всех трёх форматов один и тот же: 50 000 URL на карту при весе до 50 МБ в несжатом виде. При превышении любого из двух лимитов перечень делят на части и сводят индексом Sitemap; поисковику отправляют уже этот индекс. Отдельно протокол требует своего от кодировки и от самих записей:
- Кодировка только UTF-8, ничего другого протокол не допускает.
- Записи полные и абсолютные, вида https://example.com/page.html, а не /page.html.
- Расположение на корневом уровне, при котором карта действует на весь ресурс.
- Обязательные элементы карты: urlset, url и loc с адресом публикации.
- Необязательный lastmod указывает дату последнего значительного изменения.
- Значения priority и changefreq игнорируются, поэтому проставлять приоритет обновления смысла нет.
Тег lastmod учитывается, только если дата гарантированно точная, то есть её проверяют сравнением с последней изменённой версией материала. Отметка, которую CMS переставляет при каждой мелкой правке, доверия не добавляет.
Как создать карту сайта
Способ создания на этом этапе не принципиален — Google одинаково принимает любой валидный файл. В большинстве CMS карта собирается штатным модулем или плагином и обновляется автоматически, для остальных случаев есть онлайн-генераторы и краулеры вроде Screaming Frog. Подробно все способы разобраны в материале про устройство и создание sitemap, а для популярных систем — в отдельных инструкциях по Битриксу и WordPress. Дальше исходим из того, что файл уже готов и доступен по адресу вида site.ru/sitemap.xml.
Как добавить карту сайта в Google Search Console
Начинают не с карты, а с самого ресурса: его заводят в консоли и доказывают, что он ваш. Способов подтверждения доступно несколько – HTML-файл в корне, метатег на главной, уже стоящий код Google Аналитики или Менеджера тегов, а для доменного ресурса запись у провайдера доменных имён.
Здесь же учитывают, что версии с префиксами http и https, с www и без считаются разными ресурсами. Карта видна только в своём, поэтому в консоль обычно добавляют все варианты доменного имени. Иначе отправленный файл просто не найдётся в таблице.
«Отправить» карту означает сообщить, где она лежит. Сам файл никуда не загружается. Зато в таблице видно дату получения и перечень сбоев, поэтому такой путь удобен для контроля.
Отправка через отчёт «Файлы Sitemap»
Отправить карту таким путём может только пользователь с правами владельца. Без них карту указывают строкой в robots.txt. Порядок выглядит так.
- Опубликовать готовую карту, соблюдая требования к формату, кодировке и расположению.
- Проверить синтаксис валидатором: ошибка разметки остановит обработку.
- Прогнать адрес через инструмент проверки URL: робот должен видеть «Да» в поле «Сканирование разрешено?» и «Успешно» в поле «Получение страницы».
- Скопировать этот же адрес в поле «Добавьте файл» отчёта «Файлы Sitemap» и подтвердить кнопкой «Отправить».
- Вернуться к таблице и раскрыть свежую строку: там указан статус последнего запроса.
Файл получается сразу, а сканирование перечисленных в карте страниц занимает время и может пройти не полностью. На это влияют трафик, размер проекта и другие факторы.
Дальше карту проверяют время от времени. Если стоит не «Успешно», открывают сведения и разбирают причину.
У Яндекса процедура и статусы отличаются — разбор в статье про sitemap в Яндекс Вебмастер.
Через robots.txt и Search Console API
Второй способ не требует прав владельца. В любом месте служебного файла размещают строку с полной ссылкой на карту, и она найдётся при очередном сканировании.
Sitemap: https://example.com/karta.xml
Количество таких строк не ограничено. Там перечисляют столько карт, сколько их заведено. Директива общая для всех поисковых роботов: её достаточно указать один раз, и путь увидят и Google, и Яндекс.
Минус в том, что найденные так карты в таблицу не попадают, и за их обработкой не проследить.
Третий способ, Search Console API, поддерживает те же функции, что и интерфейс, и подходит там, где карты пересобираются программно: файл уходит запросом из скрипта.
Строка в robots.txt остаётся базовой страховкой и работает без прав владельца. Отправка через интерфейс добавляет контроль над обработкой, а API берут там, где карт много.
Отчёт о файлах Sitemap: статусы и что они значат
В таблицу попадают только карты, отправленные через сам отчёт или API. Найденные иначе туда не входят, но их можно отправить повторно, чтобы следить за сканированием.
По каждой строке видно тип файла, дату отправки, дату последней обработки, статус последнего запроса и количество выявленных страниц.
- «Успешно»: разбор прошёл без замечаний, все перечисленные в карте страницы встали в очередь на обход. Делать ничего не нужно.
- «Обнаружены проблемы»: разбор дошёл до конца лишь частично, хотя всё вычитанное в очередь попало. Раскройте строку и посмотрите перечень замечаний.
- «Не получено»: скачать документ не вышло вовсе. Устраняете причину и отправляете карту заново.
Сколько страниц из карты проиндексировано, эта таблица не показывает. Для этого сводку об индексировании фильтруют по конкретной карте. Там видно, что попало в индекс, а что исключено.
Повторная отправка и удаление файла
Успешно обработанная карта дальше переобрабатывается вне обычного расписания обхода. Если правки нужно учесть немедленно, её отправляют повторно новым запросом.
Когда карту забрать не удаётся, поисковик продолжает попытки несколько дней, а затем прекращает их. Тогда исправляют причину и отправляют файл заново.
При удалении карты она исчезает из таблицы, но поисковик запоминает и её, и все перечисленные в ней ссылки. Чтобы роботы перестали заходить на страницы, нужны правило в robots.txt, удаление самих разделов или директива noindex. Для самого файла Sitemap её задают заголовком ответа сервера.
Ошибки Sitemap в Search Console и как их исправить
Ошибки делятся на две группы. Первая мешает поисковику забрать файл, вторая возникает при разборе уже скачанной карты.
Диагностику начинают со строки карты в таблице: там раскрывается название проблемы и её описание.
Ошибки получения файла
Статус «Не получено» означает, что до карты не добрались. Причин обычно четыре: файл заблокирован правилом в robots.txt, к ресурсу применены «меры, принятые вручную», указана неверная ссылка (404) или сервер был недоступен.
Первые две лечатся точечно. Снимают запрещающее правило, а по мерам смотрят одноимённый отчёт и устраняют нарушение.
Проверить доступность помогает инструмент проверки URL. Ссылку на карту вставляют в поле, запускают проверку и раскрывают раздел «Доступность страницы». Там смотрят те же два поля, что и при отправке. Часть сбоев носит краткосрочный характер: если сервер отвечал с перебоями, проблема уходит при следующей попытке.
Ошибки обработки файла
Здесь поисковик получил карту, но не смог разобрать её целиком. Типовые случаи и что с ними делать:
- «Нельзя использовать URL». В перечень попали чужой домен, уровень выше самого файла либо другой префикс www и протокола. Решается приведением всех записей к домену и протоколу карты.
- «Недопустимый URL». Внутри записи оказались пробел, кавычка или опечатка вида htp:// вместо http://. Спецсимволы экранируем, опечатки правим.
- «Неправильно введена дата». Значение lastmod не уложилось в формат W3C. Пишем его как 2005-02-21, часы и минуты дописывать не обязательно.
- «Превышен максимальный размер файла Sitemap». Несжатый документ превысил 50 МБ. Дробим на части и собираем их индексом.
- «Пустой Sitemap». Внутри не оказалось ни одной страницы: чаще всего генератор отработал вхолостую.
- «Неполные URL в файле индекса Sitemap». В индексе стоят относительные пути. Прописываем вложенным картам полные адреса.
- «Недопустимый XML: слишком много тегов». В записи задвоился тег, например два loc подряд. Лишний убираем по номеру строки из сообщения.
- «Отсутствует тег XML». В записи не хватает обязательного элемента. Проверяем шаблон генерации и дописываем пропущенное.
Отдельно стоит «Переход по URL не выполнен». Сбой возникает из-за длинных цепочек переадресаций и относительных путей. Робот останавливается, не дойдя до цели. В карте оставляют конечные адреса, переадресации делают постоянными и отказываются от переходов через JavaScript и метатег refresh.
Ещё один частый конфликт возникает, когда карта содержит URL, заблокированные в robots.txt. Каждая её ссылка должна быть разрешена для сканирования, иначе робот видит противоречие: одна инструкция зовёт страницу обойти, другая запрещает.
Согласование карты, служебных правил и кодов ответа входит в SEO-аудит и решается на стороне разработчика, а не настройками консоли.
Какие страницы включать в Sitemap и как поддерживать файл
Внутри перечня место есть лишь у канонических URL, которые должны показываться в выдаче. Если один и тот же контент доступен по нескольким адресам, выберите основную версию и впишите в карту только её. Мобильная и десктопная версии доступны по разным адресам, и, как правило, берут какую-то одну.
Все страницы карты должны отвечать кодом 200. Записи с переадресацией 301 и ошибкой 404 из неё удаляют.
- Включать: главную, разделы товаров и услуг, карточки, статьи блога и посадочные под запросы.
- Исключать: служебные страницы (авторизацию, корзину, внутренний поиск, «спасибо за покупку»), а также дубли с параметрами фильтров и сортировок.
- Обновлять: при добавлении и удалении материалов, а также при смене структуры адресов.
Дальше карта живёт в фоновом режиме. Плагин CMS пересобирает её сам, а вебмастеру остаётся раз в месяц заглядывать в консоль. Изменился ли статус, не выросло ли число сбоев, совпадает ли количество выявленных страниц с реальным объёмом каталога.
Расхождение в разы даёт повод проверить, что генератор потерял или, наоборот, добавил лишнего.
Отдельно следят за согласием карты с остальной технической частью. Закрыли раздел от индексирования — уберите его и отсюда; сменили пути при переезде — пересоберите перечень целиком. Иначе поисковик получает два противоречивых сигнала и тратит обход впустую.
