robots.txt: полное руководство по файлу для сайта — синтаксис, проверка, примеры

Коротко: robots.txt — текстовый файл в корне сайта, который сообщает поисковым роботам, какие URL им можно обходить. Он управляет краулингом, но не индексацией: закрытая в robots.txt страница всё равно может попасть в выдачу — без описания. Синтаксис описан в RFC 9309: User-agent, Disallow, Allow плюс расширение Sitemap.

Что такое файл robots.txt и как его читает поисковый робот

robots.txt — это обычный текстовый файл, лежащий строго по адресу https://example.com/robots.txt. Никаких других имён, никаких вложенных папок: робот запрашивает именно этот путь и ничего не ищет дальше. Внутри — набор строк вида «директива: значение», разделённых переводом строки.

Порядок работы краулера выглядит так:

1. Перед обходом хоста робот делает запрос GET /robots.txt к тому же хосту, схеме и порту.
2. Полученный файл разбирается и кешируется — обычно на срок порядка суток, но кеш может жить дольше, если сервер отдаёт заголовки кеширования.
3. Для каждого URL робот выбирает одну подходящую группу правил и проверяет по ней путь.
4. Если путь запрещён — робот не запрашивает страницу. Он о ней знает, но контент не получает.

Ключевое свойство протокола — добровольность. robots.txt не блокирует запросы технически: это не файрвол, не .htaccess и не авторизация. Крупные поисковики (Google, Яндекс, Bing) правила соблюдают, потому что им это выгодно. Скраперы, парсеры контента и сканеры уязвимостей — нет. Соответственно, robots.txt решает ровно одну задачу: экономит краулинговый бюджет и убирает мусорные URL из очереди обхода.

robots.txt — это просьба, а не запрет. Всё, что действительно нельзя показывать, закрывается авторизацией или отдаётся 403/404 на уровне сервера. Файл robots.txt при этом остаётся публичным и читается любым человеком в браузере.

Зачем вообще ограничивать обход, если поисковик и так разберётся? Затем, что у робота есть лимит на количество запросов к вашему сайту в единицу времени. Если этот лимит съедают 200 000 URL сортировок и фильтров, до карточек товаров робот доходит редко. Убрав мусор из обхода, вы перераспределяете бюджет на страницы, которые действительно должны ранжироваться.

Синтаксис robots.txt: директивы стандарта и то, что в него не входит

Долгие годы robots.txt существовал как «соглашение 1994 года» без формальной спецификации, поэтому парсеры расходились в деталях. Сейчас протокол зафиксирован в RFC 9309 «Robots Exclusion Protocol». Он описывает ровно три вещи: строку User-agent и правила Allow и Disallow. Всё остальное — расширения разной степени поддержки.

Базовые правила разбора

• Одна директива — одна строка. Формат: имя, двоеточие, значение.
• Имена директив регистронезависимы: Disallow, disallow и DISALLOW одинаковы. Имена роботов в User-agent — тоже.
• Значения путей регистрозависимы: /Admin/ и /admin/ — разные пути. Это самая частая причина «правило написал, а оно не работает».
• Комментарий начинается с # и действует до конца строки.
• Файл должен быть в UTF-8. Символы вне допустимого набора парсер может отбросить.
• Пустое значение Disallow: означает «ничего не запрещено» — это разрешающее правило, а не ошибка.

Минимальный корректный файл

# Минимальный рабочий robots.txt
User-agent: *
Disallow:

Sitemap: https://example.com/sitemap.xml

Этот файл разрешает обход всего сайта и указывает карту сайта. Формально сайту без ограничений robots.txt вообще не нужен, но пустой 404 на этом пути — не лучшая идея: некоторые инструменты аудита считают его дефектом, а строку Sitemap всё равно удобно держать именно здесь.

Что не является частью стандарта

Директивы ниже вы встретите в чужих файлах и в старых инструкциях. Ни одна из них не входит в RFC 9309, и поддержка у них разная.

• Crawl-delay — просьба выдерживать паузу между запросами. Google эту директиву никогда не поддерживал и молча игнорирует. Яндекс от неё отказался: скорость обхода настраивается в Вебмастере. Bing её учитывает. Практический вывод: как средство снижения нагрузки она ненадёжна — лучше чинить причину на стороне сервера.
• Host — исторически указывала Яндексу главное зеркало сайта. Яндекс от директивы Host отказался: главное зеркало теперь определяется 301-редиректом и настройками в Вебмастере. Оставлять её в файле бессмысленно, вредом это не является, но путает тех, кто файл читает.
• Clean-param — расширение Яндекса: сообщает, какие GET-параметры не меняют содержимое страницы, чтобы робот склеивал такие URL. Работает только у Яндекса, Google её не понимает.
• Noindex: внутри robots.txt — не работает. Такой директивы в протоколе нет, поисковики её не исполняют. Для запрета индексации нужен мета-тег или HTTP-заголовок.
• Request-rate, Visit-time — реликты, которые сейчас никем не учитываются.

Справочник директив

Директива	Поддержка	Что делает	Типовая ошибка
User-agent	Стандарт, все роботы	Открывает группу правил и задаёт, к какому роботу она относится	Имя робота с опечаткой — группа не применяется ни к кому, а робот берёт секцию *
Disallow	Стандарт, все роботы	Запрещает обход URL, начинающихся с указанного префикса	Путь без ведущего слеша; /admin вместо /admin/ и попутная блокировка /administration
Allow	Стандарт (Google, Яндекс, Bing)	Явно разрешает обход префикса внутри запрещённой области	Расчёт на «порядок строк»: приоритет определяется длиной правила, а не позицией
Sitemap	Расширение, поддержано широко	Указывает абсолютный URL карты сайта	Относительный путь Sitemap: /sitemap.xml — строка игнорируется
Crawl-delay	Bing; Google — нет; Яндекс отказался	Просит паузу между запросами	Используется как замена нормальному кешированию и рейт-лимиту
Host	Устарела, Яндекс отказался	Указывала главное зеркало	Файл выглядит «настроенным», хотя строка ни на что не влияет
Clean-param	Только Яндекс	Склеивает URL, различающиеся незначащими параметрами	Ожидание, что её увидит Google
Noindex	Не поддерживается никем	Ничего	Страница остаётся в индексе, владелец уверен в обратном

Правило групп: как несколько User-agent делят один блок правил

Файл robots.txt — это не плоский список, а набор групп. Группа состоит из одной или нескольких подряд идущих строк User-agent и следующих за ними правил Allow/Disallow. Первое же правило после блока имён закрывает список имён: следующая строка User-agent начнёт уже новую группу.

# Одна группа на трёх роботов: правила общие
User-agent: Googlebot
User-agent: Yandex
User-agent: bingbot
Disallow: /cart/
Disallow: /search

# Другая группа — для всех остальных
User-agent: *
Disallow: /cart/
Disallow: /search
Disallow: /api/

Здесь Googlebot, Yandex и bingbot получают два запрета, а все прочие роботы — три. Обратите внимание: группа * к трём перечисленным роботам не применяется вообще. Это главная ловушка групп.

Робот выбирает ровно одну группу

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

User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /search
Disallow: /*?utm_source=

User-agent: Yandex
Clean-param: sort&view /catalog/

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

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

Дубли групп и пустые строки

Если один и тот же User-agent встречается в файле дважды, современные парсеры (в частности, Google) объединяют такие группы в одну. Но полагаться на это не стоит: разные инструменты аудита и старые парсеры ведут себя иначе.

Отдельная тема — пустая строка. В исходном соглашении 1994 года записи разделялись именно пустой строкой, и часть парсеров до сих пор трактует её как конец группы. Современный парсер Google пустые строки игнорирует. Итог: внутри одной группы пустых строк быть не должно. Держите группы монолитными, а пустой строкой разделяйте разные группы — тогда файл читается одинаково всеми.

# Плохо: часть парсеров оборвёт группу на пустой строке
User-agent: *
Disallow: /admin/

Disallow: /cart/

# Хорошо: группа монолитна, пустая строка только между группами
User-agent: *
Disallow: /admin/
Disallow: /cart/

User-agent: AhrefsBot
Disallow: /

Как robots.txt сопоставляет пути: wildcards и приоритет Allow над Disallow

Сопоставление по префиксу

Значение Disallow сравнивается с путём URL как префикс, а не как полный путь и не как имя директории. Disallow: /admin запрещает /admin, /admin/, /admin/users и заодно /administrator и /admin-guide.html — всё, что начинается с этих семи символов. Если нужна именно директория, ставьте закрывающий слеш: Disallow: /admin/.

Сопоставляется путь вместе со строкой запроса. Disallow: /*?sort= сработает для /catalog/?sort=price. Схема и хост в сравнении не участвуют.

Wildcards * и $

• * — любая последовательность символов, включая пустую. Disallow: /*/print закроет /catalog/print и /blog/2026/print.
• $ — якорь конца URL. Disallow: /*.pdf$ закроет /docs/manual.pdf, но не тронет /docs/manual.pdf.html и не тронет /file.pdf?v=2 — потому что после .pdf идут другие символы.
• Символы ?, ., & — обычные, никакого регулярного значения у них нет.
• Оба символа поддерживают Google, Яндекс и Bing. Это де-факто стандарт, хотя в RFC 9309 из спецсимволов описаны именно они.

Правило	URL	Результат
Disallow: /admin	/administrator/login	Запрещён — совпал префикс
Disallow: /admin/	/administrator/login	Разрешён
Disallow: /*.pdf$	/docs/a.pdf?v=2	Разрешён — $ требует конца строки
Disallow: /*?	/catalog/?page=2	Запрещён — закрыты все URL с параметрами
Disallow: catalog/	/catalog/	Не сработает — нет ведущего слеша
Disallow:	любой	Разрешён — пустое значение ничего не запрещает

Приоритет: побеждает самое длинное правило, а не первое

Самое распространённое заблуждение — «что написано ниже, то и главнее» или «Allow всегда сильнее Disallow». На деле правило одно: применяется наиболее специфичное правило, то есть с самым длинным значением пути. Порядок строк в файле не имеет значения. Если длины совпали, побеждает менее ограничивающее — то есть Allow.

User-agent: *
Disallow: /catalog/
Allow: /catalog/hits/

Для URL /catalog/hits/lamp подходят оба правила. Длина /catalog/hits/ — 14 символов, длина /catalog/ — 9. Побеждает Allow, страница обходится. Переставьте строки местами — ничего не изменится.

# Обратный случай: Allow короче, побеждает Disallow
User-agent: *
Allow: /catalog/
Disallow: /catalog/private/

# /catalog/private/doc — запрещён (18 > 9)

При подсчёте длины символы * и $ учитываются как обычные знаки. Из-за этого правила с масками иногда неожиданно «перевешивают» — при сомнениях проверяйте конкретный URL в валидаторе, а не считайте в уме.

Главное заблуждение: robots.txt не убирает страницу из индекса

Это тот пункт, из-за которого чаще всего страдают живые сайты. robots.txt запрещает обход, а не индексацию. Разница принципиальная.

Если на закрытую в robots.txt страницу ведут внешние или внутренние ссылки, поисковик может добавить её URL в индекс. Контент он не видел, поэтому в выдаче будет либо голый URL, либо заголовок, собранный из анкоров ссылок, и пометка вида «Нет описания для этой страницы — из-за ограничений в robots.txt». Страница в выдаче есть. Убрать её вы этим способом не убрали.

Классическая ловушка: страница закрыта в robots.txt и на ней стоит <meta name="robots" content="noindex">. Робот не может зайти на страницу, значит, не может прочитать noindex, значит, никогда его не исполнит. Два «запрета» гасят друг друга, и URL остаётся в выдаче годами.

Правильный порядок вывода страницы из индекса

1. Откройте страницу в robots.txt — уберите соответствующий Disallow.
2. Поставьте <meta name="robots" content="noindex, follow"> или HTTP-заголовок X-Robots-Tag: noindex.
3. Дождитесь переобхода. На это уходят недели, ускорить можно переобходом в панелях вебмастеров.
4. Только после того как URL пропал из индекса, при желании закрывайте путь в robots.txt — чтобы не тратить на него бюджет обхода.

Подробнее о мета-тегах, включая robots и его директивы, — в разборе title, description и мета-тегов. Если страница, наоборот, не появляется в поиске, причины разбираются в материале почему сайта нет в поиске.

Какой инструмент решает какую задачу

Задача	Правильный инструмент	Почему не robots.txt
Закрыть админку от обхода	robots.txt + авторизация	robots.txt экономит бюджет, но доступ закрывает только авторизация
Убрать страницу из индекса	noindex в мета-теге или X-Robots-Tag	Закрытую в robots страницу робот не прочитает и noindex не увидит
Закрыть тестовый домен	HTTP Basic Auth (401)	robots.txt на стейджинге легко уезжает в прод и убивает индексацию боевого сайта
Убрать дубли фильтров и сортировок	canonical, а при большом объёме — Disallow на параметры	Закрытый в robots дубль не передаст сигнал канонизации: робот его не увидит
Убрать из индекса PDF и файлы	X-Robots-Tag: noindex в заголовке	В файл мета-тег не вставишь, а robots.txt индексацию не снимет
Скрыть конфиденциальные данные	Авторизация, 403/404, вынос за пределы веб-корня	robots.txt публичен и работает как оглавление «интересных» путей
Пустить или не пустить AI-краулеров	robots.txt по именам ботов; для контента — llms.txt	Это разные задачи: доступ и курирование контента
Снизить нагрузку от бота	Рейт-лимит на сервере, кеш, настройка скорости в Вебмастере	Crawl-delay Google не поддерживает, а Яндекс от неё отказался

Как закрыть сайт от индексации в robots.txt — и когда это стреляет в ногу

Полное закрытие сайта выглядит так:

# Закрыть весь сайт от всех роботов
User-agent: *
Disallow: /

Обратите внимание на разницу, из-за которой ломаются сайты:

• Disallow: / — закрыт весь сайт.
• Disallow: — не закрыто ничего.

Один символ. Опечатка в этом месте — самая дорогая опечатка в SEO.

Где Disallow: / действительно уместен

• Технический домен, зеркало, поддомен под тесты, который всё равно не должен ранжироваться.
• Сайт на этапе разработки, который ещё ни разу не индексировался.
• Домен-заглушка, купленный под редирект.

Почему это плохой способ «спрятать» сайт

Во-первых, если сайт уже в индексе, Disallow: / его оттуда не выведет — вернитесь к предыдущему разделу. Более того, вы отрежете роботу возможность увидеть noindex, и страницы застрянут в выдаче в виде URL без описаний.

Во-вторых, стейджинг с Disallow: / — мина замедленного действия. Файл лежит в репозитории, кто-то выкатывает ветку в прод, и боевой сайт закрывается целиком. Обнаруживается это обычно через две-три недели, когда трафик уже просел.

В-третьих, robots.txt закрытого стейджинга публичен и прямо говорит: «здесь есть сайт, но его прячут». Для сканеров это приглашение.

Тестовый контур закрывается авторизацией, а не robots.txt. Отдавайте 401 всем, кроме своей команды: тогда ни один робот физически не получит контент, а файл robots.txt перестаёт быть точкой отказа при выкладке.

# nginx: закрыть тестовый домен по-настоящему
server {
    server_name staging.example.com;

    auth_basic           "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # подстраховка на случай, если авторизацию когда-нибудь снимут
    add_header X-Robots-Tag "noindex, nofollow" always;
}

После каждого релиза полезно проверять, что боевой robots.txt не подменился. Простейшая защита — мониторинг содержимого файла: если в нём появилась строка Disallow: /, вы узнаете об этом в тот же день, а не через месяц.

Sitemap в robots.txt: как правильно указать карту сайта

Директива Sitemap — расширение, описанное на sitemaps.org, и поддержанное Google, Яндексом и Bing. Правила у неё свои, отличные от остальных директив.

• URL только абсолютный. Sitemap: /sitemap.xml — нерабочая строка, её просто пропустят. Нужно Sitemap: https://example.com/sitemap.xml.
• Строк может быть несколько. Указывайте столько карт, сколько есть: товары, статьи, изображения.
• Директива не принадлежит группе. Она глобальна: не важно, до каких User-agent она стоит. Но для читаемости её принято выносить в самый конец файла или в самое начало, отдельным блоком.
• Схема и хост должны совпадать с рабочими. Если сайт на HTTPS, а в Sitemap указан http://, вы отправляете робота на редирект без необходимости.
• Путь к карте нельзя закрывать. Комбинация Disallow: /*.xml$ и Sitemap: https://example.com/sitemap.xml — рабочий способ выстрелить себе в ногу.

User-agent: *
Disallow: /cart/
Disallow: /search
Disallow: /*?utm_source=

Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap-products.xml
Sitemap: https://example.com/sitemap-images.xml

Если карт много, лучше указать одну индексную карту, а внутри неё перечислить остальные — файл robots.txt останется коротким. Как устроены индексные карты, приоритеты и lastmod, разобрано в руководстве по sitemap.xml.

Где должен лежать файл robots.txt и что должен отдавать сервер

Один хост — один файл

Правило действует строго: robots.txt относится к комбинации схема + хост + порт. Из этого следуют неочевидные вещи:

• https://example.com/robots.txt и https://shop.example.com/robots.txt — разные файлы. Поддомену нужен свой, корневой на него не распространяется.
• https://example.com и http://example.com формально тоже разные источники. На практике сайт отдаёт один и тот же файл по обеим схемам — так и должно быть.
• https://example.com:8443/ — снова отдельный файл.
• В подпапке файл не работает: /blog/robots.txt роботом не запрашивается вообще.
• Правила из robots.txt не действуют на другие хосты. Если ваша статика лежит на CDN-домене, ограничивать её нужно в robots.txt этого домена.

Коды ответа и как их понимает робот

Ответ на /robots.txt	Поведение краулера	Риск
200 + текст	Файл разбирается и применяется	Штатно
404 или другой 4xx	Считается, что ограничений нет: разрешено всё	Обходится весь сайт, включая служебные разделы
401, 403	Трактуется как отсутствие файла — обычно разрешено всё	Часто возникает при закрытии сайта авторизацией целиком
5xx	Файл считается недоступным — робот исходит из того, что запрещено всё	Полная остановка обхода на время аварии
3xx	Редиректы отслеживаются, но их количество ограничено (порядка пяти)	Цепочка редиректов или петля — файл не получен
Таймаут, обрыв	Как 5xx: обход приостанавливается	Нестабильный сервер тормозит индексацию

Самая недооценённая авария: сайт падает, и /robots.txt начинает отдавать 500 вместе со всем остальным. Для поисковика это означает «сайт закрыт целиком». Если пятисотки держатся долго, обход останавливается полностью. Поэтому robots.txt имеет смысл отдавать статикой, а не генерировать в приложении.

Сводка по значениям кодов и их SEO-последствиям — в справочнике кодов состояния HTTP.

Размер, кодировка, Content-Type

• Размер. RFC 9309 обязывает парсер обрабатывать как минимум 500 КиБ. Всё, что за этим порогом, может быть отброшено. Файл на 2000 строк — почти всегда признак того, что параметры пора закрывать канониклами, а не перечислением.
• Кодировка. Только UTF-8. Кириллица в комментариях допустима, но в путях лучше использовать процентное кодирование — так, как URL реально выглядит в запросе.
• BOM. Файл сохраняйте без BOM. Google лидирующий BOM игнорирует, но не все парсеры такие: три невидимых байта приклеиваются к первой строке, и User-agent: * перестаёт распознаваться. Симптом характерный — «первая директива не работает, остальные работают».
• Content-Type. Файл должен отдаваться как text/plain. Если фреймворк отдаёт его как text/html (типично, когда robots.txt отрисовывает контроллер), часть роботов файл не обработает.
• Переводы строк. Годятся и LF, и CRLF. А вот HTML внутри файла — нет: никаких <pre>, никакой обёртки страницы.

robots.txt для сайта на WordPress, Tilda и Битрикс

Общий принцип для любой CMS: закрываем служебные разделы, внутренний поиск, корзину и URL с параметрами. И не закрываем CSS, JavaScript и картинки — без них робот не отрисует страницу и не поймёт вёрстку, в том числе мобильную.

Блокировка /wp-includes/, /bitrix/ или /assets/ целиком — это не «безопасность», а сломанный рендеринг. Поисковик увидит страницу без стилей и скриптов и оценит её соответственно.

robots.txt для WordPress

У WordPress есть особенность: если физического файла в корне нет, движок отдаёт виртуальный robots.txt. Он существует только в ответе сервера, на диске его нет. Содержимое по умолчанию закрывает /wp-admin/ и открывает admin-ajax.php.

Отсюда две практические вещи. Первая: любой физический файл robots.txt в корне полностью перекрывает виртуальный. Вторая, и куда более неприятная: галочка Настройки → Чтение → Попросить поисковые системы не индексировать сайт подменяет виртуальный файл на User-agent: * и Disallow: /. Её ставят на время разработки и забывают снять. Если сайт внезапно выпал из поиска — проверяйте эту галочку первой.

# robots.txt для WordPress
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /xmlrpc.php
Disallow: /?s=
Disallow: /search/
Disallow: /*?replytocom=
Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=
Disallow: /*?fbclid=
Disallow: /*?gclid=

# CSS, JS и медиа оставляем открытыми
Allow: /wp-content/uploads/
Allow: /wp-includes/js/
Allow: /*.css$
Allow: /*.js$

Sitemap: https://example.com/wp-sitemap.xml

Чего в этом файле сознательно нет: запрета на /wp-content/plugins/ и /wp-includes/ целиком. Плагины отдают часть стилей и скриптов фронтенда, и их блокировка ломает рендер. Отдельно отметим, что теги, архивы и пагинацию правильнее регулировать мета-тегами, а не robots.txt — иначе робот не увидит ни noindex, ни canonical.

robots.txt для сайта на Tilda

Tilda генерирует robots.txt на своей стороне, и при публикации на собственный домен файл отдаётся автоматически. Отредактировать содержимое можно в настройках сайта — платформа даёт поле для собственной версии файла.

Особенности, о которых стоит помнить:

• Стили и скрипты Tilda подгружаются со своих статических доменов. Ваш robots.txt на них не влияет — и запрещать их не нужно и невозможно.
• Публикация на служебный поддомен платформы — это отдельный хост со своим robots.txt, которым вы не управляете. Индексацию тестовой версии контролируйте не файлом, а тем, что вы просто не даёте на неё ссылок и не подключаете её в панелях вебмастеров.
• Основное, что имеет смысл добавить своими руками, — строка Sitemap и запрет служебных страниц вроде «спасибо за заявку».

# robots.txt для сайта на Tilda
User-agent: *
Disallow: /thanks
Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=

Sitemap: https://example.com/sitemap.xml

robots.txt для 1С-Битрикс

В Битриксе файл генерируется модулем поисковой оптимизации (Маркетинг → Поисковая оптимизация → Настройка robots.txt), и сгенерированный по умолчанию вариант закрывает /bitrix/ целиком. Именно здесь и нужна ручная правка: в /bitrix/ лежат js, templates и собранные css-кеши — то есть ровно то, что роботу нужно для рендера.

# robots.txt для 1С-Битрикс
User-agent: *
Disallow: /bitrix/
Disallow: /local/
Disallow: /auth/
Disallow: /personal/
Disallow: /cart/
Disallow: /search/
Disallow: /upload/
Disallow: /*PAGEN_
Disallow: /*?print=
Disallow: /*?set_filter=
Disallow: /*?clear_cache=
Disallow: /*?utm_source=

# Возвращаем роботу вёрстку и скрипты
Allow: /bitrix/js/
Allow: /bitrix/templates/
Allow: /bitrix/cache/css/
Allow: /bitrix/cache/js/
Allow: /local/templates/
Allow: /upload/iblock/
Allow: /*.css$
Allow: /*.js$

Sitemap: https://example.com/sitemap.xml

Про /upload/: закрывать его целиком нельзя, если в нём лежат картинки товаров — тогда сайт исчезает из поиска по картинкам. Поэтому в примере /upload/iblock/ открыт обратно.

Умный фильтр — отдельная боль Битрикса: он порождает комбинаторный взрыв URL. Закрывать их через Disallow: /*?set_filter= имеет смысл, но параллельно на страницах фильтра должен стоять корректный canonical, а по-настоящему ценные комбинации фильтров лучше выносить в отдельные посадочные страницы с ЧПУ и не закрывать вовсе.

Отдельные секции для Яндекса и Google: когда они действительно нужны

По умолчанию отдельные секции не нужны. Одна группа User-agent: * покрывает все поисковики, и чем короче файл, тем меньше в нём ошибок. Именные секции оправданы в четырёх случаях.

1. Нужна Clean-param. Её понимает только Яндекс, поэтому она физически может жить только в его группе.
2. Правила действительно разные. Например, вы отдаёте Google отдельный набор изображений или закрываете от одного поисковика раздел, который открыт другому.
3. Управление AI-краулерами. У Google обучающий агент отделён от поискового (Google-Extended), у Яндекса дополнительный обход тоже вынесен в отдельного бота. Их правила задаются именно именными группами.
4. Ограничение SEO-сканеров. Боты сервисов ссылочного анализа обходят сайт довольно жадно; их часто закрывают целиком.

User-agent: *
Disallow: /cart/
Disallow: /search
Disallow: /*?utm_source=

User-agent: Yandex
Disallow: /cart/
Disallow: /search
Disallow: /*?utm_source=
Clean-param: sort&view&utm_source /catalog/

User-agent: Google-Extended
Disallow: /

User-agent: AhrefsBot
Disallow: /

Sitemap: https://example.com/sitemap.xml

Заметьте: группа Yandex повторяет все три общих запрета. Без этого повторения Яндекс получил бы пустой набор правил. И ещё: имя Yandex покрывает всех роботов Яндекса; для Google базовое имя — Googlebot. Точные имена проверяйте в официальной документации поисковика, а не по чужим примерам — устаревших имён в интернете больше, чем актуальных.

robots.txt и безопасность: закрытая директория становится публичной подсказкой

robots.txt читается кем угодно и первым делом запрашивается любым сканером. Строка

Disallow: /backup-2026/
Disallow: /old-admin/
Disallow: /internal-reports/

работает как оглавление: «вот три места, куда точно стоит заглянуть». Поисковый робот их не тронет, а автоматический сканер уязвимостей — обязательно.

Правило без исключений: если раздел нельзя показывать посторонним, он закрывается авторизацией или отдаёт 403/404. Упоминание такого пути в robots.txt не защищает, а рекламирует его.

Что делать вместо этого:

• Закрывайте служебные разделы на уровне сервера или приложения — по сессии, по IP, по Basic Auth.
• Если раздел всё-таки нужно убрать из обхода, используйте маску вместо точного имени: Disallow: /*/reports/ раскрывает меньше, чем полный путь.
• Не перечисляйте в robots.txt бэкапы, дампы и архивы. Их вообще не должно быть в веб-корне.
• Не полагайтесь на «неугадываемое» имя директории — она всё равно утечёт через логи, реферер или чужой краулер.

robots.txt и llms.txt: чем отличаются и как сосуществуют

Это два разных файла с разными задачами, и один не заменяет другой.

	robots.txt	llms.txt
Задача	Разрешить или запретить обход URL	Показать модели, что на сайте главное, и дать это в удобном виде
Формат	Директивы «имя: значение»	Markdown: заголовок, описание, списки ссылок
Статус	RFC 9309, поддержан всеми поисковиками	Проект соглашения, поддержка добровольная и неполная
Характер	Ограничивающий	Рекомендательный, «витрина»
Расположение	/robots.txt, строго корень хоста	/llms.txt, тоже корень
Что будет, если файла нет	Обход разрешён полностью	Ничего — модель просто читает сайт как обычно

Сосуществуют они просто: robots.txt решает, пустить ли конкретного AI-бота, а llms.txt — что показать тому, кого вы пустили. Если вы закрыли бота в robots.txt, наличие llms.txt ничего не изменит: файл нужно ещё скачать, а на это нужен доступ.

# Пустить AI-краулеров к контенту, но не в служебные разделы
User-agent: *
Disallow: /cart/
Disallow: /personal/
Disallow: /search

User-agent: GPTBot
Disallow: /cart/
Disallow: /personal/
Allow: /

Sitemap: https://example.com/sitemap.xml

Полный разбор имён AI-ботов и стратегий «пускать / не пускать» — в материале robots.txt и AI-краулеры. Как собрать сам файл — в руководстве по llms.txt.

Как проверить robots.txt

Проверка одной командой

Прежде чем открывать валидаторы, убедитесь, что файл вообще корректно отдаётся. Три вещи: код 200, тип text/plain, содержимое без HTML.

# Заголовки: код ответа и Content-Type
curl -sSI https://example.com/robots.txt

# Содержимое целиком
curl -sS https://example.com/robots.txt

# Проверить, нет ли редиректа и куда он ведёт
curl -sSIL -o /dev/null -w '%{http_code} %{content_type} %{url_effective}\n' \
  https://example.com/robots.txt

# Поиск BOM в начале файла (должно быть пусто)
curl -sS https://example.com/robots.txt | head -c 3 | xxd

# Есть ли в файле фатальное «закрыть всё»
curl -sS https://example.com/robots.txt | grep -nE '^\s*Disallow:\s*/\s*$'

# Тот же файл на поддомене — он отдельный
curl -sSI https://shop.example.com/robots.txt

Если grep нашёл строку Disallow: / на боевом домене — дальше можно не проверять, это авария.

Инструменты enterno.io

• Проверка robots.txt — разбирает файл, показывает группы и правила, подсвечивает синтаксические ошибки и проверяет конкретный URL: разрешён он или запрещён и каким именно правилом.
• Проверка HTTP-заголовков — код ответа, Content-Type, редиректы и заголовок X-Robots-Tag. Здесь же видно, не отдаётся ли robots.txt как HTML.
• SEO-аудит сайта — смотрит robots.txt в связке с остальной технической частью: карта сайта, канониклы, мета-теги, доступность страниц.
• Проверка llms.txt — если вы настраиваете доступ AI-краулеров, полезно убедиться, что второй файл тоже на месте и валиден.

Панели вебмастеров

• Google Search Console. Отдельный «тестер robots.txt» из панели убран; вместо него есть отчёт по robots.txt в настройках ресурса: какие файлы найдены, когда получены, с каким статусом и не было ли ошибок загрузки. Проверить конкретный URL можно инструментом проверки URL — он покажет, заблокирован ли адрес файлом robots.txt.
• Яндекс.Вебмастер. В инструментах есть анализ robots.txt: можно отредактировать содержимое прямо в форме и прогнать список URL, чтобы увидеть вердикт по каждому.
• Bing Webmaster Tools. Есть свой тестер robots.txt с редактором.

Проверяйте не «файл в целом», а конкретные URL: главную, карточку товара, страницу листинга, файл стилей и файл скрипта. Синтаксически валидный robots.txt, закрывающий css, — валидный и вредный одновременно.

Когда нужен X-Robots-Tag вместо robots.txt

Для файлов, в которые нельзя вставить мета-тег (PDF, DOCX, изображения, JSON), запрет индексации задаётся HTTP-заголовком.

# nginx: убрать из индекса документы и служебный раздел
location ~* \.(pdf|docx?|xlsx?)$ {
    add_header X-Robots-Tag "noindex" always;
}

location ^~ /internal/ {
    add_header X-Robots-Tag "noindex, nofollow" always;
}

# Apache: то же самое
# <FilesMatch "\.(pdf|docx?|xlsx?)$">
#   Header set X-Robots-Tag "noindex"
# </FilesMatch>

Важно: чтобы робот увидел этот заголовок, путь не должен быть закрыт в robots.txt. Одновременно применять Disallow и X-Robots-Tag к одному URL бессмысленно.

Типовые ошибки в robots.txt: симптом → причина → проверка → фикс

Симптом	Причина	Как проверить	Фикс
Сайт целиком пропал из выдачи	Disallow: / уехал со стейджинга или включена галочка видимости в CMS	curl -sS https://site/robots.txt	Убрать строку, отправить файл на переобход, проверить настройки CMS
Первая директива не работает	BOM в начале файла	curl -sS … | head -c 3 | xxd	Пересохранить в UTF-8 без BOM
Правило игнорируется у одного поисковика	У робота есть своя именная группа без этого правила	Найти в файле все User-agent	Продублировать полный набор правил внутри именной группы
Закрыт лишний раздел	Disallow: /admin без завершающего слеша совпал с /administration	Проверить конкретный URL в валидаторе	Добавить слеш: Disallow: /admin/
Страницы в выдаче без описания	URL закрыт в robots.txt, но проиндексирован по ссылкам	Поиск по site:, отчёты вебмастера	Открыть в robots.txt, поставить noindex, дождаться переобхода
Мобильная версия оценивается как «неудобная»	Закрыты css и js	Проверить URL стиля и скрипта в валидаторе	Добавить Allow на статику
Карта сайта «не найдена»	Относительный путь в Sitemap или карта закрыта Disallow	Открыть URL карты в браузере, проверить правило	Абсолютный URL, снять запрет
Обход остановился без изменений в файле	/robots.txt отдаёт 5xx во время аварии	Мониторинг кода ответа файла	Отдавать файл статикой, не генерировать в приложении
Файл выглядит правильно, но не применяется	Отдаётся как text/html или лежит не в корне	curl -sSI и проверка пути	Положить в корень, отдать text/plain
Поддомен обходится целиком	У поддомена нет своего robots.txt, а корневой на него не действует	curl -sSI https://sub.site/robots.txt	Создать отдельный файл на поддомене

Три ошибки, которые встречаются чаще всего

Путь без ведущего слеша. Disallow: catalog/ не сработает: значение должно начинаться со слеша, иначе правило либо игнорируется, либо трактуется непредсказуемо.

Расчёт на порядок строк. «Я поставил Allow выше Disallow, значит, Allow главнее» — нет. Работает длина правила. Единственный надёжный способ убедиться — прогнать конкретный URL через валидатор.

Попытка закрыть дубли только через robots.txt. Закрытый в robots дубль остаётся в индексе, если на него есть ссылки, и при этом теряет способность передать canonical. Для дублей первичен canonical, а Disallow подключают, когда объём мусорных URL реально мешает обходу.

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

Обязателен ли файл robots.txt для сайта?

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

Как закрыть сайт от индексации через robots.txt?

Строками User-agent: * и Disallow: /. Но это закрывает обход, а не индексацию: уже проиндексированные URL останутся в выдаче без описаний. Чтобы действительно убрать сайт из поиска, нужен noindex на страницах при открытом robots.txt, а тестовый контур правильнее закрывать авторизацией.

Что значит Disallow в robots.txt?

«Не запрашивай URL, начинающиеся с этого префикса». Значение сравнивается как префикс пути, а не как имя папки, и учитывает строку запроса. Пустое значение Disallow: означает противоположное — ограничений нет.

Как проверить robots.txt онлайн?

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

Нужен ли отдельный robots.txt для поддомена?

Да. robots.txt действует на связку «схема + хост + порт». Файл на example.com не управляет обходом shop.example.com — поддомену нужен собственный файл в его корне.

Почему страница закрыта в robots.txt, но есть в поиске?

Потому что robots.txt запрещает загрузку страницы, а не её попадание в индекс. Если на URL ведут ссылки, поисковик может показать его в выдаче без сниппета. Убирается это только директивой noindex — и только при открытом доступе робота к странице.

Влияет ли Crawl-delay на скорость обхода?

Google эту директиву не поддерживает. Яндекс от её учёта отказался — скорость обхода задаётся в Вебмастере. Bing её понимает. Если нагрузка от роботов реально мешает, надёжнее настроить кеширование и рейт-лимит на сервере.

Можно ли закрыть в robots.txt папку с картинками?

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

Чеклист: правильный robots.txt

• Файл лежит по адресу /robots.txt в корне хоста и отдаёт код 200.
• Content-Type: text/plain, кодировка UTF-8, BOM отсутствует.
• Файл отдаётся статикой и не зависит от работоспособности приложения.
• Строки Disallow: / на боевом домене нет.
• Все пути начинаются со слеша; для директорий слеш есть и в конце.
• Внутри каждой группы нет пустых строк; группы разделены пустой строкой.
• Если есть именные группы (Yandex, Googlebot), в них продублирован полный набор правил.
• CSS, JavaScript, шрифты и изображения из вёрстки открыты для обхода.
• Указана хотя бы одна строка Sitemap с абсолютным HTTPS-URL, и путь карты не закрыт.
• В файле нет путей к бэкапам, дампам и служебным разделам, которые нельзя раскрывать.
• Ни для одного URL одновременно не заданы Disallow и noindex.
• У каждого поддомена есть свой robots.txt.
• Файл проверен на конкретных URL: главная, листинг, карточка, css, js.
• После каждого релиза содержимое файла сверяется с эталоном.

Более широкий срез технических проверок, в который robots.txt входит одним из пунктов, собран в чеклисте SEO-аудита.