Карта сайта и robots.txt: ошибки, которые режут трафик, и как их найти

Robots.txt — это пара десятков строк, sitemap.xml обычно генерируется сам. Кажется, что ломаться тут нечему. На практике именно эти файлы чаще всего становятся причиной внезапных провалов трафика: одна строка, перенесённая с тестового сервера, способна за несколько дней убрать сайт из поиска, а карта, набитая редиректами и дублями, годами отвлекает робота от важных страниц. Хорошая новость в том, что оба файла проверяются за полчаса. Ниже — как они устроены, где обычно ошибаются и как настроить контроль, чтобы ошибка не повторилась.

Эти файлы часто путают, хотя у них противоположные задачи. Robots.txt говорит роботу, куда ходить не нужно. Sitemap.xml перечисляет страницы, которые вы считаете важными и хотите видеть в поиске. Первый ограничивает, второй подсказывает. Ни один из них не заставляет поисковую систему что-то проиндексировать: решение принимает она сама, оценивая качество и уникальность страниц.

Robots.txt управляет обходом, а не индексацией

Это самое важное и самое неочевидное правило. Директива Disallow запрещает роботу загружать страницу, но не гарантирует, что адрес не окажется в выдаче: если на страницу ведут ссылки, поиск может показать её без описания. Чтобы страницы точно не было в индексе, нужен мета-тег robots со значением noindex или HTTP-заголовок X-Robots-Tag — для файлов вроде PDF. При этом сама страница должна оставаться открытой для обхода, иначе робот просто не увидит запрет. Логика подробно описана в документации Google по robots.txt, у Яндекса принцип тот же.

• Файл должен лежать строго в корне: site.ru/robots.txt. В подпапке его никто не ищет.
• Правила действуют для конкретного хоста и протокола: у поддомена и у версии сайта на другом протоколе свой robots.txt.
• Если файл отдаёт 404, роботы считают, что ограничений нет, и обходят всё подряд.
• Если файл отдаёт ошибку сервера (5xx), Google временно прекращает обход сайта. Нестабильный сервер может незаметно тормозить индексацию.

Что в синтаксисе работает, а что устарело

• User-agent, Disallow, Allow, Sitemap — базовые директивы, их понимают и Яндекс, и Google.
• Символ * означает любую последовательность символов, $ — конец адреса. Disallow: /*.pdf$ закрывает все PDF-файлы.
• При конфликте правил побеждает более конкретное, то есть более длинное. Это позволяет закрыть раздел и открыть внутри него нужную подпапку через Allow.
• Clean-param — директива Яндекса для параметров, которые не меняют содержимое страницы: UTM-метки, идентификаторы сессий, метки рекламных систем. Google её не поддерживает.
• Host — устаревшая директива Яндекса: главное зеркало теперь определяется по 301-редиректу, строку можно удалить.
• Crawl-delay Google никогда не поддерживал, а Яндекс перестал учитывать; скорость обхода в Яндексе настраивается в Вебмастере.
• У Google есть ограничение на размер файла — 500 КиБ; всё, что дальше, игнорируется. Для обычного сайта это не проблема, но для автоматически сгенерированных файлов — повод проверить.

Ошибки в robots.txt, которые убирают трафик

• Disallow: / на рабочем сайте. Классика после переноса с тестового сервера. Сайт начинает пропадать из выдачи в течение нескольких дней.
• Закрыты CSS, JavaScript или папка с изображениями. Робот не может отрисовать страницу так, как её видит пользователь, и хуже оценивает её удобство, особенно мобильную версию.
• Через Disallow пытаются убрать страницы из индекса. Адреса так и остаются в выдаче, только без описания, а noindex на них робот уже не прочитает.
• Слишком широкие шаблоны. Правило Disallow: /*? закрывает не только мусорные параметры, но и, например, пагинацию или фильтры, которые вы продвигаете как посадочные страницы.
• Отдельные блоки для Yandex и Googlebot, которые со временем разошлись. Робот, для которого есть свой блок, читает только его и игнорирует общий блок User-agent: *.
• Нет строки Sitemap. Не критично, если карта добавлена в Вебмастер и Search Console, но это лишний шанс, что робот её не найдёт.
• Файл генерируется CMS или плагином, и его правка на сервере перезаписывается при обновлении. Изменение «вроде внесли», но оно не живёт дольше недели.

Что закрывать, а что нет

Цель — не спрятать как можно больше, а не тратить внимание робота на страницы, которые не нужны в поиске. Условный пример для интернет-магазина выглядит так.

• Закрыть: корзину, оформление заказа, личный кабинет, страницы входа и восстановления пароля.
• Закрыть: результаты внутреннего поиска по сайту — их можно генерировать бесконечно, и в поиске они обычно выглядят как мусор.
• Закрыть: сортировки и служебные параметры, которые не меняют набор товаров (например, Disallow: /*?sort=), а метки вроде UTM — убрать через Clean-param.
• Не закрывать: категории, карточки товаров, посадочные страницы фильтров, которые вы продвигаете, статьи, страницы контактов и доставки.
• Не закрывать: файлы стилей, скриптов и изображения, которые нужны для отображения страниц.
• Тестовую копию сайта закрывать не через robots.txt, а паролем на уровне сервера. Так строка с запретом не переедет на рабочий сайт вместе с файлами.

Ниже — условный пример для небольшого сайта услуг с блогом и личным кабинетом. Это иллюстрация логики, а не шаблон для копирования: пути на вашем сайте будут другими.

• User-agent: * — правила для всех роботов одним блоком, без отдельных секций, если в них нет реальной необходимости.
• Disallow: /cabinet/ — личный кабинет клиентов.
• Disallow: /search — результаты поиска по сайту.
• Disallow: /*?utm_ — ссылки с рекламными метками; для Яндекса дополнительно можно описать такие параметры через Clean-param.
• Sitemap: https://site.ru/sitemap.xml — полный адрес карты сайта.
• Всё остальное — открыто: услуги, статьи, контакты, стили, скрипты и изображения.

Что должно быть в sitemap.xml и что там лишнее

Карта сайта — это список адресов, которые вы считаете каноническими и полезными. Каждый URL в ней — это обещание роботу: страница существует, отдаёт код 200, открыта для индексации и является основной версией. Если обещание нарушается регулярно, доверие к карте падает.

• Только канонические адреса: без параметров, без версий для печати, без дублей со слешем и без него.
• Только страницы с кодом 200: никаких редиректов и удалённых страниц.
• Ни одной страницы с noindex или закрытой в robots.txt — это противоречивый сигнал.
• Абсолютные адреса с правильным протоколом и доменом — тем, который является главным зеркалом.
• Ограничения формата: до 50 000 адресов и до 50 МБ в несжатом виде на один файл. Крупные сайты делают индексный файл со ссылками на несколько карт.
• Для многоязычных сайтов в карте можно указать языковые версии страниц через атрибуты hreflang.

Отдельно о служебных полях. Google прямо пишет в документации, что игнорирует priority и changefreq, и рассчитывать на заметный эффект от них в Яндексе тоже не стоит — тратить время на тонкую настройку не нужно. Значение имеет lastmod, но только если оно честное: дата должна меняться, когда меняется содержимое страницы. Частая ошибка — при каждой сборке сайта всем страницам ставится текущая дата. Робот быстро обнаруживает, что изменений нет, и перестаёт доверять этому полю для всего сайта.

Разбивка карты как инструмент диагностики

Даже если адресов меньше лимита, полезно делать отдельные файлы под типы страниц: категории, товары или услуги, статьи, статические страницы. Тогда в Вебмастере и Search Console видно, какая группа индексируется плохо. Условный пример: из 4 000 карточек в индексе треть, а из 40 категорий — почти все. Значит, проблема не в сайте целиком, а в карточках: дубли описаний, тонкий контент, ошибки в каноникалах. Без разбивки такая картина не видна. Что делать с найденным разрывом, разобрано в статье про индексацию сайта.

Генерация: вручную нельзя

Карта, которую контент-менеджер обновляет руками раз в квартал, устаревает на следующий день. Она должна строиться автоматически из тех же данных, из которых строятся страницы: опубликовали услугу — адрес появился в карте, сняли товар с продажи — исчез. В большинстве CMS для этого есть встроенные механизмы или модули. В проектах на Next.js и robots.txt, и sitemap.xml удобно генерировать кодом прямо в приложении: файлы robots и sitemap в каталоге app собираются из той же базы, что и страницы, и тестовое окружение может отдавать свой вариант без риска перепутать.

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

Чек-лист после каждого релиза

• Открыть /robots.txt в браузере и прочитать глазами. Полминуты, которые могут сэкономить месяцы восстановления позиций.
• Проверить файл в инструменте анализа robots.txt в Яндекс Вебмастере на нескольких важных адресах: главной, ключевой услуге или категории, свежей статье.
• Открыть sitemap.xml: он доступен, отдаёт код 200, валиден, количество адресов похоже на правду.
• Выборочно проверить несколько адресов из карты: открываются без редиректа, без noindex, с корректным canonical.
• Сравнить число адресов в карте с числом страниц в индексе. Заметное расхождение, которое растёт, — повод разобраться.
• Раз в неделю заглядывать в отчёты об индексировании в Вебмастере и Search Console: всплеск исключённых страниц виден там раньше, чем падение трафика.

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

Переезд, редизайн и внезапное падение трафика

Больше всего ошибок в этих файлах появляется при смене движка, дизайна или структуры адресов. Новый сайт выкатывается с тестовым robots.txt, карта содержит старые адреса, которые теперь отдают редирект, или наоборот — новые адреса без перенаправлений со старых. Если вы готовите обновление сайта, заложите проверку robots.txt и sitemap.xml в план запуска отдельной строкой; подробный порядок работ мы описали в статье про редизайн без потери позиций.

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

• Сравните текущий robots.txt с предыдущей версией из резервной копии или истории изменений в репозитории: не появилось ли лишних запретов.
• Откройте в Яндекс Вебмастере отчёт о страницах в поиске, а в Google Search Console — отчёт об индексировании страниц: какие адреса выпали и с какой причиной.
• Проверьте, не стоит ли noindex в шаблоне страниц — такая ошибка выглядит похоже, но живёт не в robots.txt, а в коде.
• Посмотрите логи сервера: заходят ли поисковые роботы и какие коды ответа получают.
• После исправления отправьте важные страницы на переобход в Вебмастере и запросите индексирование ключевых адресов в Search Console. Восстановление занимает время — от нескольких дней до нескольких недель, — поэтому чем раньше найдена ошибка, тем дешевле она обходится.

Вывод

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