Полное руководство о директивах Robots.txt

• Введение

• Базовый синтаксис robots.txt

• Расширенные директивы

• Примеры настройки

  • Интернет‑магазин

  • Блог/новостной сайт

  • SPA/React‑приложение

• Лучшие практики и частые ошибки

• Тестирование и мониторинг

• FAQ – Частые вопросы

• TL;DR – краткое резюме

Введение

Robots.txt – это текстовый файл в корне сайта, с помощью которого владелец указывает поисковым роботам, какие разделы можно или нельзя сканировать (crawl). Проще говоря, он сообщает ботам, куда им ходить не следует[1]. Основная цель – разгрузить сайт от лишних запросов и предотвратить индексацию заведомо незначимых страниц. Важно понимать, что robots.txt – это рекомендация, а не принудительный запрет: поисковые роботы добровольно соблюдают эти правила, но не все боты в интернете им подчиняются[2]. Поэтому не следует рассматривать robots.txt как инструмент безопасности или гарантированного сокрытия контента.

Файл robots.txt появился в 1994 году как соглашение между веб-разработчиками и поисковыми системами (Robots Exclusion Protocol). Лишь в 2019 году Google инициировал стандартизацию REP через IETF, и в 2022-м этот протокол получил статус официального стандарта (RFC 9309)[3]. Сейчас все крупные поисковые системы (Google, Яндекс, Bing и др.) поддерживают базовые директивы robots.txt и, как правило, соблюдают их[4]. Однако у каждой поисковой системы есть нюансы в реализации. Например, Google публично заявляет, что поддерживает только четыре поля: User-agent, Allow, Disallow и Sitemap[5]. Директивы вроде Crawl-delay или Host Google игнорирует. У других поисковиков поведение отличается: Bing и некоторые другие учитывают Crawl-delay[6], а Яндекс поддерживает ряд своих расширений (Host, Clean-param, Noindex и др.), о которых расскажем ниже. Разница в поведении означает, что при настройке robots.txt важно учитывать требования каждой важной для вас поисковой системы.

Наконец, подчеркнём: robots.txt – не средство исключить страницу из поисковой выдачи. Если вы хотите гарантированно убрать страницу из результатов поиска, одного запрета на сканирование недостаточно. URL, запрещённый в robots.txt, всё ещё может быть проиндексирован «по ссылкам» – поисковик просто не увидит содержимого страницы, но может показать её адрес в выдаче без описания[7]. Для полного исключения страницы нужно использовать мета-тег noindex или другие методы, о которых также упомянем.

Базовый синтаксис robots.txt

Файл robots.txt состоит из набора правил (директив), оформленных строками вида <поле>: <значение>. Каждая запись обычно начинается с указания User-agent – имени робота, для которого предназначены следующие правила. Например:

javascript">User-agent: Googlebot Disallow: /private/ 

В этом примере правила применяются только к Googlebot (поисковому роботу Google) и запрещают ему сканировать раздел /private/. Если вместо конкретного бота указано * (звёздочка), то правила относятся ко всем роботам:

User-agent: * Disallow: /private/

Можно перечислять несколько User-agent подряд, чтобы один набор правил охватывал сразу несколько роботов. Группы правил для разных ботов отделяются пустой строкой. Например:

User-agent: Yandex User-agent: Googlebot Disallow: /secret/
User-agent: * Disallow: /tmp/

Здесь для Яндекса и Google задана общая группа правил (они не будут сканировать /secret/), а для остальных роботов действует более общее правило – запрет на /tmp/. Поисковик определяет, какую группу применять, исходя из наибольшего соответствия имени бота. Более специфичный User-agent имеет приоритет над *. В примере выше Yandex и Googlebot используют первую группу, а все прочие – вторую. При этом группы не объединяются: каждый бот следует только одной, самой подходящей группе[8][9].

Директивы Disallow и Allow задают соответственно запрет или разрешение на сканирование определённых путей. Пути указываются относительно корня сайта (должны начинаться со слеша /). Например, Disallow: /private/ запретит обход всего, что находится в каталоге /private/. Директива Allow обычно используется, чтобы сделать исключение из запрещающего правила. Например:

User-agent: * Disallow: /archive/ Allow: /archive/2025-07.html

Этот пример запрещает роботам сканировать весь раздел /archive/, кроме конкретной страницы 2025-07.html внутри него (она разрешена к обходу). В ситуациях конфликта (когда один и тот же URL подходит под правило Disallow и Allow) поисковые системы, как правило, применяют наиболее специфичное правило – то есть правило с более длинным и точным совпадением URL. Проще говоря, если запрещён весь раздел, но явно разрешён отдельный файл, то доступ к нему будет открыт[10].

Robots.txt поддерживает простейшие шаблоны для указания сразу групп URL. Символ внутри пути соответствует любому количеству любых символов. А символ $ используется в конце шаблона, чтобы указать конец URL. Например, Disallow: /.pdf$ запретит индексировать все URL, оканчивающиеся на .pdf (то есть сами PDF-файлы)[11]. А запись Disallow: /downloads/* запретит всё, что лежит в каталоге /downloads/, независимо от названия файлов внутри.

В файле можно (и нужно) использовать комментарии для понятности. Комментарий начинается с символа #; всё, что следует после # до конца строки, игнорируется роботами. Также допустимы пустые строки для визуального разделения блоков. Пространство в начале и конце строки не существенны – они игнорируются. Файл чувствителен к регистру символов: /Folder/ и /folder/ – это разные пути.

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

User-agent: * Disallow:

Данный файл ничем не ограничивает работу поисковых роботов: директива Disallow без указания пути означает, что запретов нет (роботы проигнорируют пустое значение правила)[12]. Эквивалентно можно вообще не иметь файл robots.txt – отсутствие файла трактуется как разрешение краулить весь сайт[13]. Однако наличие явного файла (пусть даже пустого) помогает зафиксировать ваше намерение и избавляет от лишних ошибок (например, в случае временной недоступности файла robots.txt некоторые поисковики могут приостановить обход сайта из предосторожности).

Расширенные директивы

Помимо основных User-agent, Disallow/Allow и Sitemap, существуют дополнительные директивы robots.txt. Эти расширения не входят в изначальный стандарт 1994 года, но были предложены и реализованы отдельными поисковыми системами. Рассмотрим наиболее распространённые из них, их поддержку разными поисковиками и случаи применения.

Как видно из таблицы, Google поддерживает лишь базовые команды – все прочие директивы для него «невидимы»[5]. Яндекс и Bing в разное время внедряли собственные расширения. Яндекс-робот понимает директивы Host, Clean-param, а также устаревшую Noindex в файле robots.txt (хотя в большинстве случаев Яндекс тоже рекомендует вместо неё использовать мета-тег на странице или X-Robots-Tag). Директива Crawl-delay раньше учитывалась в Яндексе, но в настоящее время Яндекс советует управлять скоростью обхода через настройки в Яндекс.Вебмастере – фактически Crawl-delay можно считать устаревшей и в Яндексе[17]. Bing, напротив, признаёт Crawl-delay и уважает эту паузу между запросами. Остальные нестандартные поля (включая Visit-time, Request-rate и др.) встречаются крайне редко или больше не применяются активно.

Рассмотрим подробнее некоторые расширенные директивы и ситуации, когда они могут пригодиться:

• Crawl-delay: задаёт задержку между запросами робота. Полезно, если бот (чаще всего Bing или менее популярные поисковики) слишком нагружает ваш сервер частыми запросами. Например, Crawl-delay: 5 попросит бота делать паузу не менее 5 секунд между скачиванием страниц. Учтите, что Google эту директиву игнорирует[22], а для Яндекса сейчас предпочтительно ограничение через Вебмастер. В Bing при наличии Crawl-delay в robots.txt она даже переопределяет настройку скорости в интерфейсе Bing Webmaster Tools[23]. Значение задержки обычно целое число секунд (Bing принимает 1–30 сек). Слишком большое значение (например 20–30) может замедлить обход вашего сайта, поэтому используйте с осторожностью и только при реальных проблемах с нагрузкой.

• Host: используется только Яндексом. Указывает основной домен сайта, если сайт доступен по разным адресам. Классический пример: ваш сайт открывается и на example.com, и на www.example.com. Для избегания «дублей» Яндекс рекомендует либо настроить редирект с дубля на основной, либо прописать в robots.txt директиву Host: example.com на предпочитаемый вариант[18]. Если в файле указано несколько Host, Яндекс-робот учтёт только первую из них. Другие поисковые системы просто проигнорируют эту строку, она не вызовет ошибки. Директива Host полезна для Яндекса в ситуации зеркал, но она не заменяет 301-редиректы – при возможности лучше всё же настроить переадресацию на основной домен.

• Clean-param: специальная директива Яндекса для борьбы с дублирующимися страницами из-за URL-параметров. Синтаксис: Clean-param: параметры раздел. Например, Clean-param: sort&view /catalog/ означает, что параметры sort и view не влияют на содержимое страниц в разделе /catalog/ и Яндекс может их игнорировать[24]. Это приведёт к объединению сигналов со всех вариаций URL (с разными параметрами) на одну «чистую» страницу. Применять Clean-param стоит, когда у вас есть множество страниц, отличающихся лишь несущественными GET-параметрами (например, порядком сортировки, параметрами трекинга UTM и т.п.). Важное ограничение: Clean-param действует только для Яндекса. Аналоги у Google – использование канонических ссылок (rel="canonical") или настройка параметров в Google Search Console вручную. Также будьте внимательны: не указывайте в Clean-param параметры, которые реально влияют на контент, иначе робот может проигнорировать важные различия страниц.

• Noindex (в robots.txt): нестандартный способ запретить индексирование страницы через файл robots.txt. Работает только в Яндексе. Пример использования:

  User-agent: Yandex Noindex: /secret-page.html

  Это укажет Яндексу не индексировать данную страницу вообще (не показывать её в результатах поиска). Однако Google и другие на эту строчку не отреагируют. В общем случае, вместо Noindex в robots.txt предпочтительно использовать мета-тег непосредственно на странице или HTTP-заголовок X-Robots-Tag: noindex[25]. Проблема в том, что если страница запрещена к краулингу (Disallow), Google до неё не доберётся и не увидит мета-тег, но при наличии внешних ссылок всё равно может добавить её URL в индекс. В таких случаях помогает отдельный инструмент удаления URL в Google Search Console. В общем, директиву Noindex в robots.txt можно рассматривать как исторический атрибут Яндекса; для надёжного результата лучше комбинировать методы (давать поисковику просканировать страницу и увидеть на ней noindex).

• Visit-time: позволяла задавать временные окна, когда роботу разрешено обращаться к сайту (например, чтобы краулинг шёл только ночью, в непиковые часы нагрузки). Формат – указание интервала UTC, например Visit-time: 0300-0600 (с 3:00 до 6:00 по UTC). Эта директива была частью расширенного стандарта 1996 года. На практике её поддерживал разве что чешский Seznam и некоторые старые боты. На сегодняшний день популярные поисковики не используют Visit-time; вместо неё лучше регулировать скорость обхода (crawl rate) другими способами или через файрвол/серверные настройки.

Примеры настроек robots.txt

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

Пример для интернет‑магазина

Интернет-магазины часто сталкиваются с проблемами индексации из-за множества дублирующихся страниц (например, страницы фильтров товаров, сортировки, версии страниц для разных валют или языков и т.д.). Также есть технические разделы (корзина, панель администратора, страница оформления заказа), которые не имеют смысла в поиске. Ниже – условный robots.txt для e-commerce сайта:

# Разрешаем Яндекс-роботу доп. возможности User-agent: Yandex Disallow: /admin/ # запрет административной панели Disallow: /cart/ # запрет страницы корзины Disallow: /checkout/ # запрет оформления заказа Clean-param: sort&filter&view /catalog/ # игнорировать параметры фильтра и сортировки в каталоге Host: example.com # основной домен сайта для Яндекса
Правила для всех остальных роботов (Google, Bing и др.)
User-agent: * Disallow: /admin/ # не индексировать админку Disallow: /cart/ Disallow: /checkout/ Disallow: /search # внутренний поиск магазина
Заметим: страницы фильтров не запрещены для Google, вместо этого они канонизируются внутри сайта
Sitemap: https://example.com/sitemap.xml

Что происходит в этом примере:

• Мы создали отдельную группу правил для Yandex, потому что используем директивы, специфичные для него (Clean-param и Host). В эту же группу продублировали и важные Disallow для Яндекса (чтобы он тоже не сканировал /admin, /cart и т.д.).

• В глобальной группе User-agent: * задали запрет на сканирование типичных технических разделов, не нужных в поиске: административная часть (/admin/), корзина покупателя (/cart/), страница чекаута (/checkout/), а также страницу поисковой выдачи по сайту (/search, если таковая есть). Эти страницы не несут ценности для поисковых пользователей и лишь расходуют краулинговый бюджет.

• Страницы каталога товаров с фильтрами (например, параметры сортировки, фильтр по цене и т.д.) в примере не запрещены для всех. Вместо этого мы показали использование Clean-param для Яндекса, чтобы тот обходил дублирующиеся URL. В случае с Google, подобные дубли должны обрабатываться через канонические URL или в Google Search Console (инструмент URL Parameters) – здесь это комментировано в тексте.

• В конце указан Sitemap – ссылка на XML-карту сайта с перечислением всех товаров и страниц магазина. Это хорошая практика: так поисковик быстрее узнает о новых товарах и обновлениях на сайте.

Заметим, что мы нигде не блокировали файлы CSS, JS или изображения. Поисковым роботам нужно видеть ресурсы сайта, чтобы корректно его индексировать (Google прямо рекомендует не запрещать в robots.txt статические файлы, важные для отображения страниц[26]). В результате представленный конфиг закрывает от индексации только действительно лишнее, не мешая роботам полноценно рендерить витрину магазина и сканировать нужный контент.

Пример для блога/новостного сайта

Для контентного сайта (блог, новостной портал) задача robots.txt – не допустить индексации дублирующихся или вспомогательных страниц. К ним можно отнести страницы пагинации архивов, страницы тегов или разделы с параметрами сортировки. Вот пример:

User-agent: * Disallow: /wp-admin/ # запрет административной панели WordPress Allow: /wp-admin/admin-ajax.php # разрешаем важный AJAX-файл (для работы некоторых функций) Disallow: /search Disallow: /tag/ Disallow: /archive/ Disallow: /page/ # например, общая страница всех постов Sitemap: https://example.com/sitemap.xml

Пояснение к этому файлу:

• Для WordPress-сайтов принято закрывать от обхода административный раздел /wp-admin/. Мы так и сделали, добавив разрешение для admin-ajax.php – это стандартное исключение, позволяющее скрипту AJAX работать (он может использоваться для динамического функционала на фронтенде).

• Запрещаем раздел /search – страницы результатов внутреннего поиска по сайту. Они, как правило, не нужны в Google, так как дублируют навигацию и могут содержать любые случайные запросы пользователей.

• Запрещаем индексацию всех страниц тегов (/tag/). В некоторых блогах страницы тегов ценны, но чаще они представляют собой дубли рубрик или просто списки ссылок без уникального контента. Если на вашем сайте теги важны – вы можете не закрывать их. В нашем примере считаем, что теги решили исключить из поиска.

• Аналогично закрываем /archive/ – предположим, это раздел с архивами по датам (например, по месяцам). Часто такие архивы повторяют контент рубрик или тегов и не несут отдельной ценности для поиска.

• /page/ – условно запретили какой-то технический раздел, например страницу-сводку или дубль главной. В WordPress, кстати, суффикс /page/2/, /page/3/ используется для пагинации главной и рубрик. Их целиком блокировать не обязательно (Google умеет работать с пагинацией через rel="next/prev", хотя сейчас это меньше влияет). Но в некоторых случаях вебмастера предпочитают закрыть от индексации вторые и последующие страницы пагинации, чтобы не было «размывания» веса. Это можно сделать через Disallow: /page/, как в примере, но тогда убедитесь, что ценные статьи на глубинных страницах всё равно найдены через sitemap или внутренние ссылки.

• В конце опять же указываем Sitemap – это особенно полезно для новостных сайтов и блогов, где постоянно появляются новые страницы. По sitemap поисковик быстрее узнает о новом контенте.

Таким образом, robots.txt для контентного сайта помогает сфокусировать индексацию на самих статьях/новостях, не тратя ресурс на промежуточные навигационные страницы (архивы, теги, поиск). Многие из этих страниц можно также закрывать мета-тегом noindex (что даже надёжнее для Google), но тогда их всё равно придётся сканировать. Решение через robots.txt экономит краул-бюджет, сразу не давая ботам заходить в заведомо бесполезные разделы.

Пример для SPA/React‑приложения

Современные веб-приложения на фреймворках вроде React, Vue или Angular часто представляют собой SPA (Single Page Application) – единая страница, которая динамически подгружает контент через JavaScript. Для SEO такие приложения могут использовать предрендеринг (prerendering) или серверный рендеринг, чтобы поисковики смогли видеть содержание. В контексте robots.txt для SPA есть два важных момента:

• Не блокировать статические файлы, необходимые для отображения сайта (JS, CSS, API-запросы).

• Закрыть от индексации технические эндпоинты, которые не предназначены для прямого просмотра (например, API-бэкенда, приватные кабинеты, черновые страницы и т.д.).

Пример robots.txt для условного React-приложения:

User-agent: * Disallow: /api/ # запрет прямого обхода REST API Disallow: /admin/ # админ-раздел (если есть) Disallow: /account/ # личные кабинеты пользователей
Важно: не запрещаем разделы /static/ или отдельные файлы .js/.css!
Поисковики должны загружать ваши JS и CSS для корректного рендеринга страницы.
Sitemap: https://exampleapp.com/sitemap.xml

Здесь мы заблокировали для всех ботов:

• URL типа /api/ – предположим, приложение имеет REST API по этому пути. Сами по себе ответы API не представляют ценности для поисковика (это данные в формате JSON/XML), поэтому их можно не пускать роботов. К тому же, некоторые боты могут случайно находить ссылки на API (например, в исходном коде) – незачем тратить на них бюджет.

• /admin/ – как и раньше, администрация или страница администрирования, если таковая существует, должна быть закрыта.

• /account/ – личный кабинет пользователя, профиль, корзина и прочие индивидуальные разделы, которые не должны индексироваться (они уникальны для каждого пользователя и бесполезны для других).

При этом мы специально отметили в комментарии, что не закрываем в robots.txt служебные статические файлы (каталог /static/, /assets/, URL скриптов и стилей). Поисковые системы, особенно Google, теперь умеют рендерить JavaScript-приложения, но для этого им нужен доступ к вашим .js и .css файлам. Если их заблокировать, велика вероятность, что бот не сможет увидеть ваш контент полностью, и страница не попадёт в индекс или отобразится некорректно[26].

Также, если вы используете систему предрендеринга (например, рендерите копию страницы на сервере для ботов), убедитесь, что URL предрендеренной версии не запрещён. В прошлом для AJAX-краулинга использовались хэши #! и специальныеescaped фрагменты, но сейчас Google от этого отказался. В общем, для SPA правилом хорошего тона является как можно меньше ограничивать бота в robots.txt. Если контент доступен только через взаимодействие (например, после логина), лучше реализовать заглушки или публичные версии страницы для поисковых систем, чем пытаться что-то играть с robots.txt.

Лучшие практики и частые ошибки

1. Проверяйте файл robots.txt на ошибки перед загрузкой. Одна лишняя косая черта или опечатка в названии директивы может привести к непредвиденным последствиям. Например, нередкий случай – когда хотят закрыть только часть сайта, а по ошибке закрывают весь. Допустим, вы имели в виду Disallow: /catalog/temp/, а написали Disallow: /catalog – в результате весь раздел каталога выпал из поиска. Всегда просматривайте файл глазами и прогоняйте через валидаторы.

2. Используйте инструменты от поисковиков для отладки. У Google есть встроенный тестер robots.txt в Search Console (в разделе «Файлы robots.txt»), который показывает, как Googlebot прочитал ваш файл, и позволяет протестировать отдельные URL на предмет «разрешён/запрещён». Яндекс.Вебмастер также предоставляет инструмент «Анализ robots.txt», где можно увидеть предупреждения и проверить, какой раздел закрыт, а какой открыт. Эти инструменты помогут сразу выявить синтаксические ошибки или слишком общие правила.

3. Не закрывайте то, что не уверены, что нужно закрыть. Казалось бы, очевидно, но некоторые вебмастера по привычке блокируют в robots.txt целые папки (например, все изображения или весь раздел с CSS). Ранее практиковалось блокирование /wp-includes/ или /Images/, но сейчас это считается плохой практикой. Как мы отмечали, блокировка CSS/JS может ухудшить понимание вашего сайта поисковиком[26], а блокировка изображений лишает ваш сайт трафика из поиска по картинкам. Закрывайте в robots.txt только то, что действительно не должно и не нужно сканировать и показывать пользователям.

4. Учитывайте краулинговый бюджет. Под «crawl budget» понимается ограничение на количество страниц, которое бот сканирует на вашем сайте за единицу времени. У больших сайтов бюджет ограничен, и лучше, чтобы он расходовался на важные страницы, а не на бесконечные вариации URL. Грамотно настроенный robots.txt помогает распределить бюджет: закрыв бесполезные страницы (фильтры, дубли, параметры, результаты поиска), вы направите бот на основные разделы. В Google Search Console есть отчет «Статистика сканирования», где можно видеть, сколько страниц в день Googlebot скачивает. Если там большая доля – это страницы, которые вы бы не хотели видеть, подумайте о закрытии их через robots.txt или другие методы. Но и перегибать палку нельзя: если закрыть слишком много, бот может не найти значимый контент. Всегда оставляйте открытыми пути к ключевым страницам, либо предоставьте их через sitemap.

5. Разграничивайте robots.txt и мета-теги (или HTTP-заголовки) для индексации. Robots.txt контролирует только сканирование (crawl). Мета-тег robots контролирует индексацию (index). Эти механизмы дополняют друг друга. Частая ошибка – закрыть страницу через Disallow и одновременно прописать на ней noindex. В результате бот вообще не зайдёт на страницу и не увидит ваш noindex, а страница может остаться в индексе по внешним ссылкам (без содержимого). Правильнее в таком случае либо убрать Disallow, чтобы бот зашёл и применил noindex, либо вовсе удалить страницу, либо использовать инструменты удаления URL. Другой пример – nofollow в мета-теге не заставит робота не сканировать страницу, если она не запрещена в robots.txt. В общем, если цель – не индексировать страницу, используйте noindex (а страницу не запрещайте для сканирования). Если цель – не сканировать (чтобы даже контент не тянул), тогда robots.txt ваш выбор. В сложных случаях можно комбинировать: например, сначала открыть страницу для сканирования, дождаться, когда бот увидит noindex и уберёт её из выдачи, а потом закрыть.

6. Регулярно обновляйте и следите за robots.txt. Сайт – вещь динамичная: появляются новые разделы, меняется структура. Не забывайте править robots.txt, если вы, скажем, завели новый раздел и не хотите его индексировать (или наоборот, открыли ранее закрытую часть). Рекомендуется хранить комментарии в файле с датой или пометками, кто и зачем вносил изменения – чтобы через год вы сами поняли логику. Также полезно мониторить ошибки в том же Search Console: если Googlebot натолкнулся на Disallow для страницы, которую вы хотели бы видеть в поиске, он покажет предупреждение в отчёте «Индексация страниц» («страница отправлена, но заблокирована файлом robots.txt»). Такие сигналы стоит устранять, исправляя настройки.

7. Размер и доступность файла. Файл robots.txt должен быть размещён по чётко определённому адресу: https://вашсайт/robots.txt. Убедитесь, что он отдаётся с кодом ответа 200 (OK). Если robots.txt временно недоступен (например, сервер даёт 503), многие поисковые системы на всякий случай приостановят сканирование вашего сайта, чтобы не рисковать. Поэтому важна бесперебойная отдача этого файла. Максимальный размер файла неофициально ограничен – Google читает первые 500 Кб robots.txt[27], Яндекс также имеет ограничения по объёму. Обычно вписаться в этот размер не проблема (500 Кб – это огромное число правил), но всё же не стоит включать в robots.txt тысячи строк без крайней необходимости.

Тестирование и мониторинг

После настройки robots.txt важно удостовериться, что всё работает, как задумано. Вот несколько способов проверить и отследить влияние файла:

• Онлайн-валидаторы и инструменты от поисковиков: как уже упоминалось, используйте Google Search Console – там есть инструмент проверки robots.txt, который подсвечивает ошибки синтаксиса и позволяет тестировать доступность URL для Googlebot. В Яндекс.Вебмастере аналогичный сервис покажет, как Яндекс воспринимает ваш файл (и даже подскажет, какие страницы исключены директивами вроде Clean-param или Noindex).

• cURL или аналогичные утилиты: вы можете вручную скачать свой robots.txt, выполнив в терминале команду вида curl -I https://example.com/robots.txt (ключ -I для получения заголовков ответа). Проверьте, что код ответа 200, корректная кодировка (файл должен быть в UTF-8) и содержимое совпадает с вашим последним вариантом. Это помогает исключить кэширование или случай, когда вы изменили файл, а раздаётся старый из-за CDN.

• Анализ логов сервера: копните серверные логи (access logs) – какие User-agent запрашивают ваш robots.txt и когда. Обычно Googlebot обращается к robots.txt довольно часто (при каждом новом обходе сайта, но не чаще раза в сутки как правило). Если вы видите участившиеся запросы robots.txt или ошибки при его отдаче – это сигналы обратить внимание. Также в логах можно отследить, ходят ли боты в запрещённые разделы. Идеальный случай – Googlebot запросил robots.txt, затем ни разу не попытался зайти в закрытые им разделы (это будет означать, что всё настроено правильно). Если же видите, что бот всё равно лезет в Disallow-разделы, возможно, он нашёл туда ссылки и очень «хочет», или это какой-то недобросовестный бот, не следующий правилам.

• Отслеживание индексации и трафика: спустя некоторое время после изменений проанализируйте, как они повлияли. Например, у вас было много дублей в поиске – убрались ли они (например, страницы тегов исчезли из индекса после их закрытия)? Как изменился «Количество проиндексированных страниц» в Яндекс.Вебмастере и соответствующий отчёт «Coverage» (Индексация) в GSC? Также посмотрите на показатель «Вычтено из индекса» – нет ли там важных страниц, случайно выпавших из-за robots.txt. Если у вас большой сайт, стоит сравнить и статистику обхода: уменьшилось ли общее число запросов бота (если вы закрыли огромный пласт ненужных URL, то бот может тратить меньше времени, и это хорошо). В целом, любое существенное изменение robots.txt желательно сопровождать через пару недель анализом метрик индексации.

И последнее: храните исходник вашего robots.txt (в системе контроля версий или хотя бы резервной копией). Бывают случаи, когда при деплое сайта robots.txt перезаписывается на дефолтный или на тот, что был на стадии разработки (например, с Disallow: / для всего сайта!). Такие инциденты могут быть очень болезненны для SEO, поэтому всегда имейте под рукой правильную версию файла, чтобы быстро восстановить её на сервере при необходимости.

FAQ – Часто задаваемые вопросы

1. Можно ли с помощью robots.txt скрыть от поисковика файлы CSS или JavaScript?
   Технически вы можете запретить любые файлы, указав их пути в Disallow. Но Google и другие поисковые системы не рекомендуют скрывать CSS/JS. Эти файлы нужны роботу, чтобы правильно отобразить и понять вашу страницу. Блокировка CSS/JS может привести к тому, что Googlebot «не увидит» контент так, как видит его пользователь, и это негативно скажется на ранжировании[26]. Например, если CSS скрывает какой-то элемент или JS подгружает данные, а бот не может их получить – страница может считаться менее качественной. Так что не закрывайте в robots.txt директории типа /assets/, /static/, /js/, /css/. Исключение – если у вас есть совершенно незначимые файлы, которые точно не влияют на визуализацию и вы хотите сэкономить ресурс (но такое встречается редко).

2. Как работать с поддоменами? Нужен ли отдельный robots.txt для каждого субдомена?
   Да, для каждого поддомена необходим свой файл robots.txt. Правила с example.com/robots.txt не распространяются на shop.example.com или m.example.com – каждый из них считается отдельным «сайтом» в контексте обхода[28]. Поэтому, если у вас, скажем, основной сайт на example.com и блог на blog.example.com, нужно разместить robots.txt и там, и там (с учётом специфики каждого). Что касается директивы Host, она может быть полезна, когда у вас есть зеркала на разных доменах или поддоменах и нужно указать Яндексу главный. Но всё равно рекомендуется настроить 301-редиректы между дублями. Кстати, поддомены www. и без www – тоже рассматриваются как разные хосты. Если вы обслуживаете оба, файл robots.txt должен быть доступен по обоим (или один редиректит на другой). В общем, следите, чтобы на http(s)://sub.example.com/robots.txt всегда было то, что вы задумали для этого субдомена.

3. Если страница запрещена в robots.txt, попадёт ли она в индекс?
   Часто думают, что нет – ведь бот её не прочитает. Однако URL может оказаться в индексе, если на него есть ссылки с других страниц. Поисковик в таком случае знает о существовании страницы и может проиндексировать сам адрес. Но поскольку сканировать контент ему нельзя, в выдаче такая страница появится без описания (с пустым сниппетом или текстом вроде «Описание недоступно из-за файла robots.txt»)[7]. Для Google это стандартное поведение. Яндекс, возможно, вообще постарается не показывать такую страницу, но лучше на это не рассчитывать. Вывод: Disallow предотвращает сканирование, но не гарантирует отсутствие URL в поиске. Если нужно исключить страницу полностью, используйте мета-тег noindex или функцию удаления URL у поисковиков.

4. Что произойдёт, если сайта не будет файла robots.txt?
   Поисковые роботы попробуют его запросить – получат код ответа 404 или 403 – и интерпретируют это как отсутствие ограничений. Согласно стандарту, отсутствие robots.txt равно полному разрешению на обход сайта[13]. Так что ничего катастрофического: ваш сайт просто будет открыт для индексирования весь. Для маленьких сайтов это обычно ок. Но во-первых, поисковики могут выдавать предупреждения в консолях вебмастера (мол «мы не нашли файл robots.txt» – это не ошибка, но уведомление). Во-вторых, лучше всё-таки его иметь, хотя бы пустой, чтобы явно указать свои правила и избежать двусмысленности. К тому же файл robots.txt – привычное место, где люди ищут контактную информацию (некоторые оставляют там ссылки на «sitemap» или «humans.txt»). И последнее: если по какой-то причине ваш сервер начнёт отдавать не 404, а например 500 ошибку на запрос robots.txt, то, как мы упоминали, поисковик может приостановить краулинг. Так что следите, чтобы либо файл корректно отдавался, либо уж отдавался честый 404/410, который трактуется как «нет ограничений».

5. Есть ли ограничения на размер или количество правил в robots.txt?
   Жёстких ограничений в спецификации нет, но на практике есть рекомендации. Google читает первые 500 Кб файла[27]. Это очень много – примерно 50 тысяч строк правил. Яндекс раньше упоминал ограничение около 100 Кб, но официально не подтверждает сейчас. В любом случае, стремитесь держать файл как можно более компактным и логичным. Лучше 100 правил, чётко покрывающих все случаи, чем 1000 правил на каждую страницу – от такого ползут глаза и легко допустить ошибку. Если у вас огромный сайт с миллионами URL и очень сложными правилами, подумайте, может, проблему дублирования или индексации лучше решать в самом сайте (канонические URL, мета-теги и т.д.), а не плодить бесконечный robots.txt. Также учтите, что некоторые боты могут иметь меньшие лимиты на размер. Например, Baidu когда-то читал только первые 256 Кб. И ещё: некоторые поисковики могут игнорировать файл, если он слишком «тяжёлый» для них по времени скачивания.

6. Как запретить индексацию всего сайта разом?
   Для этого в robots.txt прописывается правило:

   User-agent: * Disallow: /

   Такая конструкция говорит всем роботам не ходить никуда на сайте. Учтите, что если сайт уже был проиндексирован, поисковики не мгновенно удалят все страницы. Google, например, увидев такое правило, перестанет сканировать страницы, но оставит их в индексе (как мы выяснили, URL могут сохраняться). Со временем, если бот будет видеть, что сайт длительно закрыт, он может убрать их из выдачи. Если же сайт изначально в поиске не был, то Disallow: / просто предотвратит попадание новых URL. В Яндексе при закрытом полностью сайте в Вебмастере появится предупреждение. В целом, иногда так делают на этапе разработки или если сайт на реконструкции. Но для постоянного решения это плохой вариант – пользователи не найдут ваш сайт вообще. Альтернатива для приватных ресурсов – закрыть их авторизацией (логином/паролем) или в крайнем случае использовать директиву noindex (у Google – через X-Robots-Tag в заголовках), чтобы точно ничего не «засветилось».

7. Можно ли разрешить сканирование сайта только определённым ботам, а остальным запретить?
   Да, с помощью нескольких групп User-agent. Например, если мы хотим разрешить только Googlebot, а всем остальным запретить, robots.txt может выглядеть так:

   User-agent: * Disallow: /
   User-agent: Googlebot Disallow:

   Здесь мы сначала закрываем всё для всех, а затем для Googlebot делаем исключение (пустой Disallow означает отсутствие запретов, то есть полное разрешение обхода). Благодаря тому, что для Googlebot есть более специфичная группа, он будет следовать ей и проигнорирует запрет из глобальной группы[8]. Аналогично можно вписать и других ботов, которым вы доверяете (Яндекс: User-agent: Yandex, Bing: User-agent: bingbot и т.д.), дав им свои правила. Но учтите: полностью исключить «плохих» ботов этим способом не получится – те, кто игнорирует robots.txt, всё равно будут лазить. Против них нужны другие методы (блокировка по User-Agent на уровне сервера, капчи, системы антибот).

TL;DR – краткое резюме

• Robots.txt управляет только сканированием: он говорит поисковому роботу, что можно или нельзя обходить на сайте. Но он не гарантирует исключение страниц из индекса – для этого нужны noindex и другие методы[29][30].

• Базовые директивы – четыре кита: задайте User-agent (для кого правило), используйте Disallow для запрета разделов, при необходимости Allow для исключений внутри запрещённого, и Sitemap – чтобы указать путь к карте сайта. Этого достаточно в большинстве случаев[5].

• Учитывайте особенности поисковиков: Google понимает только Allow/Disallow, игнорируя прочие поля вроде Crawl-delay[5]. Яндекс и Bing поддерживают некоторые расширения (например, Host, Clean-param у Яндекса, Crawl-delay у Bing[6]). Настраивая robots.txt, ориентируйтесь на требования тех поисковых систем, откуда у вас основной трафик.

• Не «ломайте» сайт случайно: перед выкладкой robots.txt убедитесь, что важные разделы не попали под запрет. Используйте инструменты проверки в Google Search Console и Яндекс.Вебмастере, чтобы протестировать ваш файл. Одна ошибка – и поисковики могут перестать видеть ваш контент.

• Не блокируйте CSS/JS и нужные ресурсы: поисковики должны иметь доступ к статическим файлам для рендеринга страниц. Блокировка этих файлов в robots.txt может ухудшить индексацию и ранжирование[26].

• Robots.txt – не панацея от дублей: закрывая дублирующиеся страницы (фильтры, теги, архивы) в robots.txt, вы экономите crawl-бюджет, но сами дубли могут оставаться в выдаче без сниппета. Рассмотрите дополнительно использование rel="canonical" или мета-тегов, чтобы устранить дублирование содержимого.

• Следите за актуальностью: пересматривайте свой robots.txt при изменениях на сайте. Новый раздел – проверьте, не надо ли его запретить или наоборот открыть. Удалили раздел – уберите лишние правила. Регулярный аудит файла (раз в несколько месяцев) помогает держать его эффективным и чистым от устаревших директив.