640 карточек каталога выпали из индекса из-за спора robots.txt и sitemap.xml

Robots.txt и sitemap.xml спорят, когда один файл запрещает роботу заходить в раздел сайта, а другой продолжает присылать оттуда страницы на индексацию. При таком противоречии Яндекс и Google доверяют запрету: страницы выпадают из индекса, даже если исправно лежат в sitemap. Лечится сверкой обоих файлов и повторной проверкой в Вебмастере после правки.

почему возникает конфликт между robots.txt и sitemap.xml

Оптовая компания по продаже сантехники в Москве переехала на новый домен в мае. Разработчик, который вёл перенос, скопировал robots.txt со старого тестового поддомена — там строка Disallow: /catalog/ закрывала раздел, пока на нём чистили дубли страниц. Sitemap.xml тем временем генерируется автоматически и каждую ночь исправно отправляет в Яндекс все 640 карточек товаров из этого каталога.

Робот в такой ситуации доверяет запрету, а не приглашению: сайт говорит «зайди» через sitemap и «не входи» через robots.txt одновременно, но побеждает запрет. Поэтому карточки каталога одна за другой пропадают из индекса, хотя формально они есть в sitemap.xml и по всем правилам должны показываться в поиске.

Похожие рассинхроны возникают не только при переезде на новый домен. Разработчик добавляет в robots.txt шаблонную строку вроде Disallow: /*?*, чтобы закрыть служебные параметры, — и заодно блокирует страницы фильтров каталога, которые sitemap продолжает исправно перечислять. CMS обновляет sitemap.xml автоматически при каждом изменении каталога, а robots.txt правит человек руками и физически не успевает сверять два файла между собой. Отдельный частый случай — строка Disallow: /sitemap.xml, из-за которой робот вообще не может прочитать файл, на который сама же система ссылается.

Добавляет путаницы то, что правила robots.txt читаются не построчно сверху вниз, а по принципу самого длинного совпадающего пути: если в файле одновременно есть Disallow: /catalog/ и Allow: /catalog/tovar-1/, робот применит более специфичное правило и всё равно откроет один конкретный товар при закрытом разделе. Такие смешанные конфигурации выглядят рабочими при беглом просмотре файла, а на деле открывают одни адреса каталога и закрывают другие без видимой логики.

Пока никто не смотрит в Яндекс.Вебмастер, конфликт не выглядит срочным. Но если каталог из нескольких сотен товаров выпадает из индекса на месяц — это не строчка в отчёте, а упущенные заявки: покупатели, которые искали товар в поиске, находят его у конкурента, потому что карточка вашего магазина туда просто не попала.

как обнаружить конфликт до того, как его найдёт Яндекс

Проверка начинается не с чтения robots.txt построчно, а с отчётов поисковых систем. В Яндекс.Вебмастере это раздел «Индексирование → Диагностика сайта» и вкладка Sitemap — там отдельной строкой показывается количество адресов, которые перечислены в sitemap, но запрещены в robots.txt. В Google Search Console аналогичная метка «Заблокировано robots.txt» видна в отчёте Sitemaps.

Ручная проверка занимает больше времени, но полезна на небольших сайтах: выгружаете список URL из sitemap.xml, построчно сверяете с правилами Disallow в robots.txt и смотрите, какие адреса попадают под запрет. На сайте из нескольких десятков страниц это можно сделать за час; на каталоге из тысяч карточек товаров вручную не сверить — там нужен отчёт из Вебмастера, краулер вроде Screaming Frog в режиме списка адресов или отдельный скрипт, который построчно прогоняет sitemap через правила robots.txt.

Стоит проверить и заголовок ответа сервера: иногда страница разрешена в robots.txt и лежит в sitemap, но сервер параллельно отдаёт HTTP-заголовок X-Robots-Tag: noindex или мета-тег robots со значением noindex в самом html — тогда конфликт прячется не в двух файлах, а в третьем месте, и обычной сверки sitemap с robots.txt недостаточно.

Такую сверку — вместе с ещё восемью направлениями проверки — мы делаем в рамках аудита сайта по 9 направлениям: конфликт robots.txt и sitemap попадает в отчёт вместе с остальными техническими находками, а не всплывает отдельно через три месяца.

как исправить robots.txt и sitemap.xml, если они противоречат друг другу

Исправление всегда сводится к одному из двух решений: либо раздел действительно должен индексироваться, и тогда запрет в robots.txt снимают, либо раздел служебный, и тогда его адреса убирают из sitemap.xml. Оставлять противоречие «на потом» нельзя — робот продолжит получать взаимоисключающую команду при каждом обходе.

порядок действий

• ✓Определить, какой из файлов прав: заглянуть в структуру сайта и решить, должен ли раздел индексироваться.
• ✓Снять лишний Disallow в robots.txt, если раздел рабочий, или удалить адреса раздела из sitemap.xml, если он служебный.
• ✓Проверить, не блокирует ли robots.txt сам файл sitemap.xml строкой вроде Disallow: /sitemap.xml.
• ✓Добавить в конец robots.txt актуальную строку Sitemap: с полным адресом файла, если её там нет.
• ✓Отправить обновлённый robots.txt на переобход в Яндекс.Вебмастере и Google Search Console и через несколько дней проверить отчёт по индексации повторно.

После правки не стоит рассчитывать на мгновенный результат: переобход десятков тысяч адресов занимает время, а не происходит по клику «отправить». Ускорить процесс можно точечно — через инструмент «Переобход страниц» в Яндекс.Вебмастере отправляют на проверку не весь каталог, а конкретные адреса, которые важнее остальных: топовые по марже позиции, сезонные товары, страницы с наибольшим количеством запросов.

что делать, если ошибка повторяется после исправления

Файлы поправили, отчёт в Вебмастере очистился, а через две-три недели проблема возвращается — те же адреса каталога снова помечены как запрещённые. Чаще всего дело не в самой правке, а в том, что её кто-то или что-то откатывает обратно.

На сайтах на 1С-Битрикс robots.txt иногда генерируется модулем при каждом обновлении шаблона и переписывает ручные правки поверх. При деплое через git старая версия файла может подтягиваться из репозитория, если правку внесли только на боевом сервере, а не в код, — тогда следующий релиз откатывает файл к прежнему виду. CDN или кеширующий прокси перед сайтом отдают роботу закешированную версию robots.txt даже после того, как файл на сервере уже обновлён, и Яндекс какое-то время продолжает получать старые правила.

Отдельно стоит проверить тестовый и боевой контуры сайта: если staging и production используют общий шаблон robots.txt, при следующем обновлении шаблона на боевой сервер может попасть строка Disallow: /, предназначенная для того, чтобы поисковики не индексировали тестовую копию. Такая ошибка закрывает от роботов весь сайт целиком, а не один раздел, и обнаруживается обычно уже по резкому падению всего органического трафика.

Проверьте фактическую версию файла прямым запросом к адресу /robots.txt, а не через админку CMS — так видно, что реально получает робот. Если используется CDN, сбросьте кеш для этого файла отдельно после каждой правки. Если генератор sitemap и robots.txt работают независимо друг от друга — в модуле CMS и в отдельном файле, — заведите правило синхронизировать их вручную при любом изменении структуры каталога, а не полагаться на то, что кто-то вспомнит.

Пока причина отката не найдена, повторные правки бессмысленны: индексация не успевает стабилизироваться, а бюджет на новые карточки товара уходит на то, что поисковик всё равно не покажет.

как предотвратить конфликт между robots.txt и sitemap.xml в будущем

Сам конфликт не появляется без причины — его создают правки, которые вносят по отдельности, без сверки одного файла с другим. Три привычки снимают большинство таких случаев.

• ✓Проверять robots.txt и sitemap.xml одним отчётом, а не по памяти — после каждого крупного изменения структуры сайта или переезда на новый домен.
• ✓Держать одного ответственного за оба файла, даже если один генерируется автоматически, а другой правится руками, — иначе решения принимаются вслепую.
• ✓Добавлять сверку файлов в чек-лист перед запуском новой версии сайта, а не искать причину падения трафика постфактум.

Полезно также завести регулярный автоматический контроль: скрипт раз в сутки скачивает robots.txt и sitemap.xml и сравнивает список адресов из sitemap с правилами Disallow, а при расхождении присылает уведомление ответственному. Настройка занимает пару часов работы, а окупается тем, что расхождение находят на следующий день после релиза, а не через месяц по отчёту о падении заявок.

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

сколько стоит устранить конфликт и что входит в аудит

Разбор robots.txt и sitemap.xml — один пункт технического блока в аудите сайта по 9 направлениям: помимо индексации там же проверяют скорость загрузки, безопасность, соответствие требованиям к персональным данным и ещё несколько направлений, которые обычно не видны из панели администратора. По итогам аудита компания получает не список терминов, а перечень конкретных строк в robots.txt и адресов из sitemap, которые нужно поправить, — с этим списком можно идти к своему разработчику или отдать задачу на подряд.

Если конфликт найден, а своего разработчика в штате нет, саму правку файлов и настройку деплоя можно поручить сисадмин-сопровождению — услуга стоит от 3800 руб/час, а на такую задачу обычно уходит один-два часа работы, включая проверку в Вебмастере после правки. Стоимость аудита и других пакетов — на странице тарифов.

❓ Частые вопросы

Может ли конфликт robots.txt и sitemap.xml исчезнуть сам, без правки файлов?

Нет. Поисковый робот при каждом обходе заново читает оба файла и заново применяет запрет из robots.txt к адресам из sitemap.xml. Пока в файле остаётся строка Disallow для раздела, который перечислен в sitemap, конфликт будет повторяться при каждом обходе — вне зависимости от того, сколько раз обновится сам sitemap.

Сколько времени занимает возврат страниц в индекс после исправления файлов?

После снятия запрета в robots.txt страницы обычно возвращаются в индекс в течение нескольких дней — Яндекс и Google переобходят сайт по своему расписанию. Полный охват каталога из нескольких сотен товаров может занять пару недель; ускорить процесс помогает ручная отправка ключевых адресов через инструмент переобхода в Вебмастере.

Обязательно ли указывать строку Sitemap: в robots.txt, если файл уже добавлен в Вебмастер?

Строго не обязательно: если sitemap.xml уже загружен напрямую в Яндекс.Вебмастер и Google Search Console, поисковики и так знают о нём. Но строка Sitemap: в robots.txt помогает другим роботам и сервисам найти файл автоматически, поэтому её стоит оставить даже при ручной загрузке.

Что делать, если сайт работает на конструкторе и нет прямого доступа к файлам?

Большинство конструкторов дают редактировать robots.txt и настройки индексации через раздел SEO в админ-панели без доступа к файловой системе. Если такого раздела нет, стоит обратиться в поддержку конструктора или к разработчику, который вёл интеграцию, — без правки конфликт не устранить.

Как понять, что именно конфликт robots.txt и sitemap.xml мешает индексации, а не что-то другое?

В Яндекс.Вебмастере и Google Search Console расхождение между файлами вынесено отдельной строкой в отчёте по Sitemap — с формулировкой вроде «запрещено в файле robots.txt». Если такой пометки нет, а страницы всё равно не индексируются, причина в другом: дублях, качестве контента или технических ошибках на самой странице.