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

robots.txt управляет обходом сайта, а не показом в поиске. Это не тонкость, а главная подмена всей темы: страница, закрытая в этом файле, может остаться в выдаче, и об этом прямым текстом пишут оба поисковика. Яндекс — «Ограниченные в robots.txt страницы могут участвовать в поиске Яндекса», Google — «Страницы, сканирование которых запрещено в файле robots.txt, все равно могут показываться в результатах поиска, но без описания».

Чтобы понять, что с этими файлами происходит на практике, я скачал robots.txt у 22 сайтов малого и среднего бизнеса из пяти отраслей — стоматологии, строительные компании, автошколы, юристы, магазины инструмента и крепежа — и разобрал каждый файл построчно кодом. Главный результат: у 10 из 22 стоит директива Host, которую Яндекс не поддерживает, а страницу про неё удалил из справки целиком. Ниже — 15 проверок, собранных из этого замера и из трёх первоисточников, и пояснение, что каждая из них ловит.

01robots.txt запрещает заходить, а не показывать

Ключевая цитата лежит у Яндекса в примечании в самом начале страницы про robots.txt, и вторая её половина важнее первой:

«Ограниченные в robots.txt страницы могут участвовать в поиске Яндекса. Чтобы удалить страницы из поиска, укажите директиву noindex в HTML-коде страницы или настройте HTTP-заголовок. Не ограничивайте такие страницы в robots.txt, чтобы робот Яндекса смог их проиндексировать и обнаружить ваши указания.»

То есть справка прямо требует не закрывать в robots.txt страницы, которые нужно убрать из поиска. Логика механическая: робот обязан зайти на страницу, чтобы прочитать noindex. Закрыли обход — он не зайдёт, запрета не увидит, адрес в выдаче останется. Google объясняет и то, откуда адрес берётся, если страницу вообще не открывали: «Если на определенную страницу ведут ссылки с информативным текстом, размещенные на других сайтах, то робот Googlebot может добавить ее в индекс, даже не открывая», — и называет назначение файла без обиняков: «Файл robots.txt не предназначен для того, чтобы запрещать показ ваших материалов в результатах поиска Google».

Отсюда первая развилка, которую стоит держать в голове всю статью: обход и показ — два разных механизма, и у них разные инструменты.

Последняя строка таблицы — цитата из действующего стандарта, а не моё мнение. RFC 9309, раздел «Security Considerations»: «Listing paths in the robots.txt file exposes them publicly and thus makes the paths discoverable» — перечисление путей в файле делает их публичными и тем самым обнаружимыми. Строка Disallow: /admin-secret/ не скрывает папку, а объявляет её адрес всем, кто откроет файл.

02Что показали 22 живых файла

Все 22 файла я скачивал на диск запросом curl -k -s -L -o <файл> https://<домен>/robots.txt, а потом разбирал построчно: группы User-agent, правила внутри групп, межсекционные директивы. Адреса из строк Sitemap отдельно проверял на код ответа. Замер сделан 6 октября 2026 года.

Размер файла: минимум 16 байт, медиана 1434,5, максимум 8114.

Что в этой таблице стоит увидеть. Ожидаемой катастрофы — закрытого от поиска сайта или пропавшего файла — нет ни одного случая. Зато самая распространённая находка, Host у десяти сайтов из двадцати двух, — это директива, которой в действующем списке Яндекса нет. И любопытная деталь: десять файлов дают шесть разных вариантов написания одной строки — с протоколом и без, с www и без, со слэшем на конце и без. Так выглядит директива, которую никто не проверяет, потому что проверить её больше нечем. Побочный результат замера: у 16 сайтов из 22 платформа читается прямо из robots.txt по характерным путям — /bitrix/ у семи, /wp-admin у семи, /manager/ и /administrator/ ещё у двух. Файл рассказывает о сайте больше, чем владелец предполагает, и это ровно то, о чём предупреждает RFC.

03Host и Crawl-delay: директив больше нет, советы остались

Действующий список директив Яндекса — пять строк, и он приводится на странице про robots.txt целиком: User-agent (помечена как обязательная), Disallow, Sitemap, Clean-param, Allow. Ни Host, ни Crawl-delay в нём нет.

С Crawl-delay всё однозначно, потому что страницу про неё Яндекс сохранил — ровно затем, чтобы написать: «С 22 февраля 2018 года Яндекс перестал учитывать директиву Crawl-delay». Восемь с половиной лет. Вместо неё справка отправляет в Вебмастер, на страницу Индексирование → Скорость обхода, где по умолчанию включена опция «Доверять Яндексу», а ручной режим задаётся ползунком — и там же оговорка, что «заданное вами значение считается рекомендованным для робота». Google про ту же директиву пишет в скобках, перечисляя свои поля: «Google поддерживает следующие поля (другие поля, например crawl-delay, не поддерживаются)».

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

Теперь неприятная часть, объясняющая, откуда Host берётся в живых файлах. Позиции в выдаче Яндекса по запросам «robots txt», «robots txt для сайта» и «как настроить robots txt» я не измерил: запрос к поиску отдаёт 302 на showcaptcha. Поэтому собрал пул из 11 страниц по теме — это пул, а не топ, и порядок в нём ничего не значит; все 11 скачаны сырым curl, заголовки сняты регуляркой по тегам, а не на глаз.

В пуле два сервиса и хостинг-документация до сих пор описывают Host как рабочую директиву — с четырьмя примечаниями по синтаксису, — а про Crawl-delay сообщают читателю, что она учитывается Яндексом, пять страниц из одиннадцати. Корректно закрывает тему Crawl-delay одна страница, тему Host — тоже одна, причём по Host картина чуть лучше не потому, что кто-то объясняет, а потому, что шесть страниц просто молчат. Самый тяжёлый случай — отдельный блок «Когда использовать директиву Crawl-delay» из шести пунктов с «данными исследования» и процентами про скорость сканирования; числа оттуда я не беру, потому что проверить их не смог, а относятся они к директиве, которую не учитывает ни один поисковик.

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

04Allow против Disallow: выигрывает длина, а не порядок строк

Самый частый спор про файл — что главнее, запрет или разрешение. Яндекс отвечает дословно: «Директивы Allow и Disallow из соответствующего User-agent блока сортируются по длине префикса URL (от меньшего к большему) и применяются последовательно… Таким образом, порядок следования директив в файле robots.txt не влияет на использование их роботом». И отдельной врезкой: «При конфликте между двумя директивами с префиксами одинаковой длины приоритет отдается директиве Allow». RFC 9309 говорит то же другими словами — «The most specific match is the match that has the most octets», а при равенстве правил «the "allow" rule SHOULD be used».

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

Disallow: /bitrix/
...
Allow: /bitrix/panel/

Префикс /bitrix/panel/ длиннее, чем /bitrix/, значит разрешение перекрывает запрет именно для админской панели. Сама панель закрыта паролем и ничего страшного не происходит, но её адрес теперь официально объявлен разрешённым к обходу — в файле, который открывается в один клик у любого сайта. Это чистый копипаст из шаблона: вместе с нужными /bitrix/js/, /bitrix/css/ и /bitrix/templates/ в файл приехала панель управления.

Там же, в правилах чтения файла, лежат три ловушки, которые справка называет прямым текстом. Первая: «Недопустимо наличие пустых переводов строки между директивами User-agent, Disallow и Allow» — в моём замере пустая строка внутри группы нашлась у двух сайтов из 22, причём ровно перед блоком разрешающих правил для скриптов и стилей. Вторая: Disallow: /# читается как полный запрет, потому что решётка начинает комментарий, — справка приводит этот пример отдельно. Третья: пустая Disallow: означает «разрешено всё», а пустая Allow: не значит ничего и роботом не учитывается.

И главное про группы, что ломает чтение файла чаще всего: группа User-agent: * действует только на тех роботов, у которых нет своей группы. Если в файле есть User-agent: Yandex, робот Яндекса читает только её и полностью игнорирует звёздочку — в RFC это прямое обязательство. Отсюда и правильное прочтение приёма, который я сначала принял за ошибку: у одного магазина в файле четыре блока вида User-Agent: AhrefsBot плюс Disallow: /. Это не закрытый сайт, а осознанное отсечение SEO-сканеров, жгущих хостинг, и поисковых роботов оно не касается. Если считать все строки Disallow: / подряд, выйдет ложное «один сайт закрыл себя целиком» — поэтому счёт в таблице выше идёт только по группам, в составе которых есть *.

05Параметры: одна строка Clean-param вместо десяти Disallow

Самая массовая находка замера после Host — метки и параметры, закрытые через Disallow: 12 сайтов из 22, и у шести из них Clean-param нет вообще. Крайний случай — магазин, где одни и те же UTM закрыты десятком перекрывающихся правил:

Disallow: /*?utm_source=
Disallow: *utm*=
Disallow: *openstat=
Disallow: /?gclid=
Disallow: /?yclid=
Disallow: */?fbclid=*
Disallow: *?

Девять строк под метки плюс Disallow: *?, закрывающий вообще все адреса с параметрами. Яндекс про такой подход высказывается прямо: «Иногда для закрытия таких страниц используется директива Disallow. Рекомендуем использовать Clean-param, так как эта директива позволяет передавать основному URL или сайту некоторые накопленные показатели». И подробнее на странице про Disallow: «При использовании Disallow может не получиться выявить дублирование адреса ссылки без параметра и передать некоторые показатели запрещенных страниц».

Разница содержательная, а не стилистическая. Disallow говорит «не ходи сюда» — и накопленные страницей показатели остаются на закрытом адресе. Clean-param говорит «этот параметр не влияет на содержимое» — и адрес с меткой склеивается с чистым. Вся замена, по примеру из самой справки, выглядит одной строкой:

User-agent: Yandex
Clean-param: utm

Две тонкости, на которых спотыкаются. Директива межсекционная — «может быть указана в любом месте файла», но если вы вообще заводите отдельную секцию для Яндекса, то все предназначенные ему правила должны лежать в ней: «При этом строка User-agent: * будет проигнорирована». И ограничение длины — 500 символов на правило.

Главное же — Clean-param существует только у Яндекса: в перечне полей Google его нет, а про незнакомые поля там сказано «другие поля не поддерживаются». Для Google эта строка — игнорируемый мусор, и параметры ему надо объяснять каноническими адресами. Причём половина беспорядка с параметрами начинается не в robots.txt, а в рекламе: как собирать UTM-метки, чтобы потом не разбирать в отчётах десять вариантов одной и той же ссылки, я расписывал по шагам — чем меньше вариантов разметки, тем короче список того, что приходится склеивать.

Если разбирать такой файл и пересобирать разметку параметров самому некогда, имеет смысл заказать техническую настройку сайта под поиск вместе с robots.txt, картой сайта и склейкой адресов с метками, чтобы правила ставились под реальную структуру разделов, а не копировались из шаблона для чужой CMS. Чаще всего выясняется, что половину строк в файле можно просто удалить.

06Пять ошибок, которые я нашёл в живых файлах

Домены называю только там, где ошибка видна прямо в файле, а последствие я проверил отдельным запросом. Все проверки — 6 октября 2026 года.

Что здесь видно. Ни одна из этих ошибок не читается как ошибка при взгляде на файл: все строки синтаксически верные, валидатор на них не пожалуется. Ломается не синтаксис, а соответствие файла сайту — страница переехала, раздел наполнили, картинки сложили в другую папку, а правило осталось с тех времён, когда было осмысленным. У той же автошколы стоит Disallow: /zapisatsya.html, и этот адрес сегодня отдаёт 404: правило охраняет страницу, которой нет. Отсюда вывод, которого в советах не встречается: проверять надо не файл, а пары «правило — адрес», прогоняя каждый Disallow на конкретный раздел отдельным запросом.

Честная оговорка про границы замера. Я проверял, что страница существует и закрыта правилом; выпала ли она фактически из поиска — проверить нельзя по той же причине, по которой не измерены позиции. Поэтому вывод формулируется как «страница закрыта от обхода», а не «страницы нет в поиске». И 22 сайта пяти отраслей — это замер, а не исследование рынка: числа вида «10 из 22» надо читать именно так.

Разберём именно
ваш сайт бесплатно

Посмотрю страницу и рекламу, найду,
где теряются заявки, и пришлю план,
что поменять.

Что входит в разбор

• 1
  Где теряются заявкипуть от объявления до формы
• 2
  Что поправить на сайтепервый экран, оффер, формы
• 3
  Что поменять в рекламезапросы, объявления, бюджет

Михаил Лапошинразберу ваш проект лично

Ваше имяТелефонСайт

TelegramWhatsAppЗвонок

Согласен на обработку данных и политику конфиденциальностиПолучить бесплатный разбор

✓ Заявка принята — отвечу в течение часа

07Что происходит, когда robots.txt отдаёт 404 или 500

Это самая опасная ситуация и единственная, где три первоисточника расходятся. Для владельца сайта 404 и 500 на robots.txt выглядят одинаково — «что-то сломалось». Для роботов это противоположные команды.

Дословно противопоставление читается в двух соседних разделах RFC. Про 4xx: «the crawler MAY access any resources on the server». Про 5xx: «the robots.txt file is undefined and the crawler MUST assume complete disallow». Google из второго случая сделал конкретное число — «Не сканирует сайт на протяжении первых 12 часов, но продолжает предпринимать попытки получить файл robots.txt», — то есть полчаса пятисотых на одном файле стоят полдня обхода. Дальше он месяц живёт на последней доступной версии, а если кэша нет, сканирует без ограничений; сетевые проблемы и DNS он к той же категории и относит.

А у Яндекса отдельных формулировок для 404 и 5xx я не нашёл — есть одна общая фраза в требованиях к файлу: «Если файл не соответствует требованиям, сайт считается открытым для индексирования». Искал по всем страницам справки, относящимся к robots.txt; больше ничего нет. Значит, полагаться на то, что падение сервера будет понято двумя поисковиками одинаково, нельзя: различие документировано только у одного.

Сами требования Яндекс приводит списком: размер не больше 500 КБ, TXT-файл с названием robots, корневой каталог, код 200. Плюс три лимита из справочника ошибок, которых не цитирует в пуле никто: не больше 2048 правил, не больше 1024 символов на правило и 500 символов на правило Clean-param. По размеру же три источника расходятся интереснее, чем кажется: RFC пишет «The parsing limit MUST be at least 500 kibibytes» — это нижняя граница обязательства краулера, «читать обязан хотя бы столько», — а Google и Яндекс превратили то же число в верхнюю границу файла.

Кодировка UTF-8 у всех трёх, и отдельно у Яндекса: «Использование кириллицы запрещено в файле robots.txt и HTTP-заголовках сервера», домены — в Punycode. Сайт на конструкторе всю эту часть закрывает сам: файл генерируется платформой и правке не подлежит, поэтому стоит заранее посмотреть, что из технической оптимизации на Тильде вообще доступно вам, а что остаётся на стороне платформы — список короче, чем ожидают, и robots.txt в него не входит.

08Где увидеть, что правило сработало

Это тот самый вопрос, на котором заканчиваются все одиннадцать страниц пула. Между «я записал правило» и «страница ушла из поиска» лежат два отчёта и два срока.

Отчёт называется Индексирование → Страницы в поиске, переключатель — в положение Исключённые страницы; справка оговаривает лимит выгрузки: «до 50 000». Статусы там дословные, и это то, что вы увидите у себя:

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

Сроки два, и путать их не надо. Файл перечитывается в пределах суток — по RFC кэш не дольше 24 часов, у Google «обычно не более суток». А возврат страницы в поиск после снятия запрета Яндекс описывает отдельно: «страница может появиться в поиске в течение двух недель после того, как робот узнает о ее изменении». Если правка не дала результата за три дня, это ещё ничего не значит; смотреть надо не в выдачу, а в статус адреса. Полезно при этом помнить, что технический запрет — только одна из восьми причин, по которым страница выпадает из поиска, и спутать его с «малоценной» страницей легко: подпись в отчёте в обоих случаях короткая, а лечатся они совершенно по-разному.

До выкладки файл проверяется двумя инструментами Вебмастера. Анализ robots.txt работает без подтверждения прав на сайт — то есть проверить можно и чужой файл, достаточно указать адрес; он ищет «синтаксические ошибки или противоречия, которые могут повлиять на индексацию сайта» и отвечает по конкретному URL одной из трёх формулировок, от «Владелец площадки разрешил показ страницы в поиске Яндекса» до «Не удалось провести полную проверку». И отдельная функция, про которую стоит знать заранее: сервис хранит версии файла за последние 6 месяцев, «максимальное количество сохраненных версий — 100». Когда обход просел после чьей-то правки, это единственный способ узнать, что именно изменилось и когда. Второй инструмент — Проверка ответа сервера, им проверяется то самое «отдаёт ли файл 200».

09Чек-лист: 15 проверок своего файла

Открывайте свой https://ваш-домен/robots.txt и идите по списку. В скобках — что проверка ловит и почему она здесь.

1. Файл отдаёт 200 и лежит в корне, имя строчными буквами. Проверяется инструментом «Проверка ответа сервера»: 5xx на этом файле по RFC означает «запрещено всё», у Google — 12 часов без обхода.
2. Кодировка UTF-8, кириллицы нет, домены в Punycode.
3. Есть User-agent — единственная директива, помеченная справкой как обязательная.
4. Нет Host — у 10 сайтов из 22 она есть, а валидатор отвечает «Обнаружена неизвестная директива».
5. Нет Crawl-delay — не учитывается с 22 февраля 2018 года, скорость обхода задаётся в Вебмастере.
6. Каждый Disallow на конкретный раздел проверен запросом. Адрес отдаёт 200 и там живой контент — правило надо снять или объяснить.
7. Папка с картинками не закрыта без разрешающего Allow — одна строка Disallow: /upload/ в Битриксе закрывает все изображения сайта.
8. Нет правил на адреса, которых больше нет. Запрет на страницу с 404 — признак файла, который дописывали, не перечитывая.
9. Метки и параметры закрыты через Clean-param, а не десятком Disallow — так делают наоборот 12 сайтов из 22.
10. Нет Disallow: *?, закрывающего разом фильтры, сортировки, поиск и пагинацию. В замере — 11 сайтов из 22.
11. Нет пустой строки между Disallow и Allow внутри группы — справка запрещает это дословно.
12. Нет Disallow: /# — решётка начинает комментарий, и правило читается как полный запрет на весь сайт.
13. Sitemap указана полным адресом с протоколом, и этот адрес отвечает 200. Карт несколько — перечислены все.
14. Файл укладывается в лимиты: 500 КБ, 2048 правил, 1024 символа на правило, 500 символов на правило Clean-param.
15. Страницы, которые нужно убрать из поиска, в robots.txt не закрыты. Главная проверка списка: для них noindex, X-Robots-Tag, пароль или коды 404, 403, 410 — и справочник ошибок Яндекса сам советует «используйте метатег robots или заголовок X-Robots-Tag на уровне сервера», если закрывать нужно много.

Главный же вывод короче списка: robots.txt почти никогда не бывает причиной роста и довольно часто бывает причиной потерь. Из 22 файлов ни один не улучшал положение сайта, зато пять содержали проверяемые ошибки, каждая из которых отрезала от обхода что-то нужное. Отсюда правильная стратегия — минимализм: пустой файл не сломал ничего ни у одного сайта в выборке, а ломали их лишние строки. Если хотите убедиться, что в вашем такой строки нет, можно прислать свой robots.txt и разобрать его построчно вместе с адресами, которые он закрывает, — в половине случаев разбор заканчивается удалением правил, а не добавлением.

Михаил ЛапошинМаркетолог, руководитель Laposhin Agency

«Делаем сайты и запускаем Яндекс Директ так, чтобы
сайт приносил заявки, а не просто был»

Есть вопрос по статье?Задать вопрос в Telegram