Robots.txt: какие URL запрещать к обходу, а какие оставить открытыми

Обход, индексирование, удаление и защита данных - разные задачи

Я считаю robots.txt коммерчески значимой конфигурацией: ошибка в одной маске может затронуть страницы, в которые уже вложены разработка, контент и продвижение.

Фразу «закрыть страницу от индексации» лучше не использовать в технической задаче без уточнения. За ней могут скрываться четыре разных результата.

Обход начинается, когда робот запрашивает URL. Файл robots.txt сообщает совместимому роботу, какие запросы владелец сайта разрешает, а какие запрещает. Это добровольно исполняемое правило, а не сетевой экран.

Для индексирования содержимого поисковику обычно нужно получить и обработать документ. Сам URL может стать известен и появиться в поиске без обхода содержимого, например по внешней или внутренней ссылке. Google прямо разделяет управление сканированием и исключение URL из поиска, а Яндекс предупреждает, что ограниченные в robots.txt страницы могут участвовать в поиске.

Удаление требует долгосрочного сигнала о состоянии URL. Для исчезнувшего документа это корректный 404 или 410; для переехавшего документа - прямой постоянный redirect на эквивалентную замену; для доступной пользователям страницы - noindex, если она не должна участвовать в поиске.

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

Дерево выбора: какой механизм нужен для URL

Выбор начинается не с директивы, а с роли URL. Последовательность ниже помогает не использовать Disallow для чужой задачи.

1. Содержимое должно быть недоступно посторонним. Используйте авторизацию и права доступа. Дополнительный запрет обхода не заменяет защиту.
2. Страница доступна, но не должна участвовать в поиске. Передайте noindex в HTML или HTTP-заголовке и оставьте URL доступным роботу. Это правило описано у Google и Яндекса.
3. Документ удален без замены. Верните 404 или 410, уберите URL из Sitemap и лишних ссылок. Disallow помешает роботу получить этот статус.
4. Документ переехал. Настройте прямой постоянный redirect и обновите ссылки, canonical и Sitemap. Правила обхода не заменяют обработку redirect.
5. Несколько URL дублируют содержание. Согласуйте canonical, redirects, ссылки и Sitemap. Блокировка дубля может скрыть canonical; Google не рекомендует использовать robots.txt для нормализации URL.
6. Роботу действительно не нужно получать URL. Здесь уместен Disallow, но сначала убедитесь, что на адресе нет нужного noindex, canonical, redirect, ссылок или ресурсов рендеринга.
7. Параметр не меняет содержание. Для Яндекса можно рассмотреть Clean-param; для Google нужны согласованные canonical, ссылки, Sitemap и архитектура параметров. Самостоятельную посадочную нельзя объявлять незначащей.
8. Нужно управлять специальным клиентом или AI-функцией. Сверьте product token, HTTP User-Agent, применение * и затронутые функции по спискам Google и Яндекса. Политику AI-роботов рассматривайте отдельно от поискового обхода.

Если роль URL не определена, результат классификации - «недостаточно данных», а не новая маска в файле.

Владелец бизнеса или маркетинга утверждает поисковую роль URL и допустимый коммерческий риск. SEO-специалист и разработчик доказывают совпадения правил, проверяют ресурсы, выпускают изменение и готовят откат. Такая граница ответственности не дает принять технически корректную маску, которая противоречит задаче бизнеса. Как эти роли соединяются в общем процессе, разобрано в материале о SEO под ключ.

Как описать класс URL до написания правила

Класс URL - не любое множество адресов с общей частью пути, а страницы с одинаковой функцией, поисковой ролью и ожидаемым поведением робота. /catalog?sort=price может только менять порядок товаров, а /catalog?color=green - формировать полезную категорию. Маска по символу ? сотрет это различие.

Адреса собирают не только из меню, но и из CMS, Sitemap, краулера, логов и отчетов поисковых систем. Если хотя бы один URL класса должен индексироваться, отдавать redirect или показывать canonical, широкую маску не выпускают: класс разделяют по устойчивому признаку.

Где находится robots.txt и на какие URL он действует

Файл размещают по адресу /robots.txt в корне конкретного origin. Origin здесь означает сочетание протокола, хоста и порта. Правила из https://example.com/robots.txt действуют для https://example.com/catalog/item, но не распространяются автоматически на:

• http://example.com/catalog/item, потому что отличается протокол;
• https://shop.example.com/catalog/item, потому что отличается поддомен;
• https://example.com:8443/catalog/item, потому что отличается нестандартный порт.

Для каждого рабочего origin проверяется собственный файл. Запись по адресу https://example.com/files/robots.txt не управляет сайтом, потому что находится не в корне. Базовые требования к расположению, кодировке UTF-8 и текстовому формату закреплены в RFC 9309, а область действия протокола, хоста и порта подробно показана в спецификации Google.

Открытие файла в браузере и ответ 200 OK подтверждают только доступность. Они не доказывают, что нужный робот выбрал ожидаемую группу, что маски совпали с правильными URL и что важные ресурсы остались открыты.

Как устроены группы User-agent

Строка User-agent начинает группу правил для одного или нескольких роботов. User-agent: * используется как общая группа для роботов, которым не подошла более специфичная группа.

User-agent: *Disallow: /site-search/User-agent: GooglebotAllow: /

В этом примере Googlebot выбирает свою специфичную группу и может обходить /site-search/. Общая группа * к ней не добавляется. Робот Яндекса, если отдельной группы для него нет, использует * и не обходит /site-search/.

Это частая причина неожиданных разрешений. Команда добавляет исключение для Googlebot или Yandex, но рассчитывает, что все запреты из * продолжат действовать. Их нужно явно повторить в специфичной политике либо отказаться от отдельной группы, если различия не нужны. Google описывает выбор и объединение групп, а Яндекс - приоритет конкретного User-agent над *.

Google объединяет правила нескольких групп одного product token. Для Яндекса безопаснее держать его правила в одной секции и проверять итог анализатором. Группа * к специфичной группе не добавляется.

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

Как работают Disallow, Allow и приоритет правил

Disallow запрещает обход совпавшего пути. Allow разрешает более узкий путь внутри широкого запрета. Значение записывается от корня, начиная с /; протокол и хост в эти директивы не включают.

Сопоставление чувствительно к регистру пути. /Private/ и /private/ считаются разными значениями. При конфликте применяется наиболее специфичное, то есть самое длинное совпавшее правило. Порядок строк сам по себе не задает приоритет. Если совпавшие Allow и Disallow одинаково специфичны, Google и Яндекс выбирают разрешение. Это поведение подтверждают Google и Яндекс.

Точные примеры показывают границы лучше, чем описание маски:

Символ * означает любую последовательность символов, включая пустую. Символ $ фиксирует конец совпадения. Символ # начинает комментарий до конца строки. Фрагмент URL после # браузер не отправляет серверу, поэтому управлять такими фрагментами через robots.txt нельзя.

К каждой маске нужны как минимум положительный и отрицательный тесты. Для широкого правила полезны еще пограничные URL: другой регистр, похожий префикс, параметр в другой позиции, URL без завершающего слеша и URL с дополнительным суффиксом.

Строка вида Noindex: /path/ не является переносимым способом запрета индексирования. Google не поддерживает noindex внутри robots.txt; директиву размещают в meta robots или HTTP-заголовке и оставляют документ доступным для обхода. Это ограничение указано в документации Google о noindex.

Для Яндекса к концу правила неявно добавляется *, если совпадение не зафиксировано символом $. Поэтому Disallow: /example запрещает и /example, и /example.html, а Disallow: /example$ запрещает только первый адрес. Подробные примеры приведены в справке Яндекса по Allow и Disallow.

Что делают Sitemap и Clean-param

Sitemap указывает полный URL файла Sitemap или его индекса:

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

Эта строка не относится к одной группе User-agent. Она помогает роботам обнаружить Sitemap, но не гарантирует обход или индексирование перечисленных страниц. В Sitemap должны находиться выбранные канонические URL, а сам файл должен быть доступен роботу.

Clean-param поддерживает Яндекс. Директива сообщает, что один или несколько GET-параметров не меняют содержание. Например, если ref используется только для источника перехода и не влияет на товар, правило может выглядеть так:

Clean-param: ref /catalog/

Clean-param является межсекционной директивой Яндекса, поэтому в простом случае ей не нужна отдельная группа. Если в файле уже есть специфичная группа User-agent: Yandex, в ней перечисляют полный набор предназначенных для Яндекса правил: общая группа * автоматически не дополнит ее.

Перед применением сравнивают содержимое URL с параметром и без него. Если параметр меняет категорию, город, характеристики, наличие или другой значимый блок, Clean-param использовать нельзя. Disallow имеет приоритет над Clean-param, поэтому сочетание двух директив способно лишить Яндекс доступа к странице. Длина одного правила ограничена 500 символами; префикс пути регистрозависим и допускает только A-Z, a-z, цифры и символы ., -, /, *, _. Актуальный синтаксис и ограничения приведены в справке Яндекса о Clean-param.

Google Clean-param не поддерживает: в его перечне распознаваемых строк robots.txt такой директивы нет. Для параметрических URL Google рекомендует управлять архитектурой фасетной навигации, ссылками, canonical и доступностью комбинаций по их поисковой роли. Общая маска для любого ? опасна: вместе с сортировкой она может закрыть фильтры, которые должны быть самостоятельными посадочными.

Когда Disallow вообще уместен

Disallow уместен для однородного класса URL, который не должен получать поисковый трафик и не нужен роботу для noindex, canonical, redirect, ссылок или рендеринга. Общая маска не подходит посадочным, URL с noindex или redirect, дублям с canonical, неклассифицированным параметрам и конфиденциальным данным.

Если содержание зависит от JavaScript, проверьте доступность скриптов и API: Google не обрабатывает заблокированные страницы и JavaScript, а модель ресурсного робота Яндекса описана в официальном списке. Когда URL создаёт CMS или модуль, сначала найдите генератор; платформенные границы разобраны в материале про SEO на разных CMS.

Матрица решений по типам URL

Матрица переводит разговор «что обычно закрывают» в проверяемое решение для конкретного класса.

Практическая строка матрицы должна содержать еще четыре поля: реальные примеры URL, ожидаемый User-agent, доказательство теста и владельца решения. Без них категория остается предположением.

Минимальный учебный пример

Ниже показана только форма файла. Пути вымышлены и не являются шаблоном для CMS или готовой рекомендацией.

User-agent: *Disallow: /site-search/Sitemap: https://example.com/sitemap.xml

Пример запрещает всем подходящим роботам обход URL, начинающихся с /site-search/, и указывает абсолютный адрес Sitemap. Он не закрывает публичные разделы, не использует Host, Crawl-delay или noindex.

Перед копированием нужно доказать, что на конкретном сайте /site-search/ действительно является ненужным для обхода классом, не содержит индексируемых посадочных и не нуждается сначала в удалении через noindex. Даже имя пути в реальном проекте может означать другую функцию.

Чем поведение Google отличается от Яндекса

Обе системы поддерживают базовые группы User-agent, правила Allow и Disallow, спецсимволы * и $, комментарии и выбор наиболее специфичного совпадения. Переносить остальные особенности автоматически нельзя.

Текущие детали Google о лимите, поддерживаемых строках, кодах ответа и кеше собраны в официальной спецификации. Требования Яндекса к размеру и доступности находятся в справке по robots.txt. Отдельно Яндекс подтверждает, что Crawl-delay не учитывается, а Host можно удалить или оставить без эффекта.

Сценарии ошибок нельзя переносить между системами. Google отдельно описывает обработку 4xx, 429, 5xx, сетевых ошибок и кешированной версии в спецификации robots.txt и инструкции по снижению частоты обхода. Справка Яндекса не обещает тот же почасовой сценарий. Поэтому команда фиксирует три разных события: публикацию файла, получение новой версии роботом и фактическое изменение обхода.

Процедура изменения robots.txt

Для меня задача готова к выпуску только тогда, когда команда проверила не сам файл, а реальные URL: какие страницы обязаны оставаться открытыми, какие должны блокироваться и как быстро вернуть предыдущую версию.

Работа с файлом состоит из инвентаризации, проектирования, тестирования, выпуска, приемки и наблюдения. Редактирование строк находится в середине процесса, а не в начале.

1. Зафиксировать задачу и владельца

Запишите цель изменения, затронутые origin и классы URL, нужных роботов, владельца поисковой роли, выпускающего и ответственного за откат. Формулировка «почистить индекс» недостаточна. Результат должен быть проверяемым: например, технический поиск перестает обходиться, а карточки товаров и ресурсы рендеринга остаются доступны.

2. Снять исходное состояние

До правки сохраните текущий файл, ответ сервера, дату получения в панелях и выборку логов по всем рабочим origin. Для каждого класса соберите реальные совпадающие и пограничные URL: другой регистр, похожий префикс, параметры в ином порядке и адрес без завершающего слеша.

3. Сопоставить URL с другими сигналами

У каждого тестового адреса проверьте HTTP и redirect, robots-директивы, canonical, Sitemap, внутренние ссылки, ресурсы рендеринга и текущее участие в поиске. Так обнаруживается конфликт, при котором новый Disallow перекрывает старый URL с redirect или страницу с noindex.

4. Составить минимальное правило

Каждая строка должна соответствовать одному подтвержденному классу URL. Широкую маску не используют только ради короткого файла. Отдельную группу робота добавляют, когда политика действительно отличается и полный набор правил для этой группы понятен.

Черновик сначала проверяют в анализаторе или локальном парсере, затем на реальных URL нужного origin. Не выпускайте правило, пока для него нет положительного и отрицательного теста.

5. Проверить тестовую матрицу

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

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

6. Выпустить изменение с готовым откатом

Перед публикацией сохраните последнюю рабочую версию и способ быстрого восстановления. После выпуска проверьте /robots.txt на каждом origin, HTTP и текстовое содержимое, все строки матрицы, доступность индексируемых страниц, ресурсов и Sitemap. Проверяется фактически опубликованный файл, а не версия в репозитории.

В Google Search Console отчет о robots.txt показывает последнюю полученную версию, ошибки и предупреждения; проверка URL помогает установить, блокируется ли конкретный адрес. В Яндекс Вебмастере инструмент «Анализ robots.txt» проверяет текст файла и список URL. Запрос повторного сканирования robots.txt в Google используют для критичного изменения, а не как обязательный ритуал после каждой правки.

7. Наблюдать фактическое поведение

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

Приемка и откат

Изменение принимается, когда выполнены все применимые условия:

• файл доступен в корне каждого нужного origin;
• сервер возвращает ожидаемый успешный ответ и текст в пределах лимитов систем;
• каждый робот выбирает ожидаемую группу;
• совпадающие URL блокируются, а пограничные и индексируемые страницы остаются открытыми;
• CSS, JavaScript, изображения и API основного содержания доступны;
• noindex, canonical, redirects и Sitemap доступны роботу там, где это требуется;
• предыдущая версия сохранена, владелец отката известен;
• панели получили актуальный файл, а логи не показывают незапланированного эффекта.

Повод для немедленного отката - блокировка важной страницы или ресурса, публикация файла не на том origin, ответ HTML или 5xx вместо текста, неожиданное совпадение широкой маски либо расхождение факта с утвержденной матрицей.

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

Частые мифы о robots.txt

Универсальный шаблон без карты страниц создает ложное чувство порядка. Файл может выглядеть аккуратно и при этом закрывать важный для бизнеса раздел.

Миф: Noindex: /page внутри robots.txt удалит страницу. Переносимого запрета индексирования в файле нет. noindex передают в HTML или X-Robots-Tag, оставляя URL доступным.

Миф: нижняя строка всегда важнее верхней. Для Allow и Disallow решает специфичность совпадения. Перестановка строк не исправляет неверную маску.

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

Миф: успешный валидатор означает безопасную настройку. Он подтверждает синтаксис, но не знает роли URL. Нужны реальные совпадения и пограничные тесты.

Миф: шаблон подходит любой CMS. Одинаковые пути могут выполнять разные функции, а модули создают собственные URL. Шаблон даёт гипотезы, а не готовую политику.

Миф: robots.txt сам улучшает позиции. Файл меняет обход, но не гарантирует индексирование, ранжирование, трафик или AI-цитирование.

Как выглядит хороший результат

Хороший результат — не длинный robots.txt, а короткий набор объяснимых правил, тестовая матрица и отсутствие случайно закрытых посадочных.

Хороший robots.txt не обязательно длинный. Его качество определяется объяснимостью правил и отсутствием случайно закрытых страниц. Для каждого запрета известен класс URL, важные страницы и ресурсы доступны, а команда может показать тест, владельца и рабочий откат.

Если инвентаризация затрагивает параметры, JavaScript-рендеринг, дубли, миграцию и несколько поисковых систем, изменение уже выходит за рамки редактирования одного файла. Такой объем разумно включать в техническую часть SEO-работ Медиакода: сначала определить поисковую роль URL, затем согласовать механизмы и только после этого менять правила обхода.