Robots.txt: как создать, настроить и проверить файл
Robots.txt помогает управлять обходом сайта: какие адреса поисковому роботу разрешено запрашивать, а какие нужно пропустить. Для владельца бизнеса это способ согласовать технические URL с задачами продвижения. Важные услуги, товары и статьи должны оставаться доступными, а ненужные для обхода варианты — обрабатываться по понятным правилам.
При настройке важны не количество директив и не похожесть файла на пример конкурента, а фактический результат для нужных страниц. Ниже — последовательность создания и проверки robots.txt: от выбора правил до публикации, тестирования разных URL и контроля изменений. Примеры условные; перед переносом на рабочий сайт их нужно сопоставить с его структурой.
Что делает robots.txt и какие задачи ему не подходят
Файл содержит инструкции для роботов, которые поддерживают Robots Exclusion Protocol. Поисковая система получает его перед обходом и определяет применимые ограничения. Правила не меняют поведение обычного посетителя: запрещённый для обхода URL может по-прежнему открываться в браузере. Они также не обязывают любой сторонний бот соблюдать ваши пожелания.
Robots.txt уместен, когда нужно ограничить запросы к определённым разделам или вариантам адресов. Но сначала сформулируйте назначение: уменьшить обход технических комбинаций, сохранить доступ к полезным страницам или устранить случайный запрет. Само наличие длинного файла не делает сайт лучше для поиска.
Запрет обхода не равен удалению из поиска
Google предупреждает: адрес закрытой от обхода страницы может остаться в результатах, если система узнала о нём из других источников. Актуальная справка Яндекса также допускает участие ограниченных URL в поиске. Поэтому robots.txt нельзя использовать как гарантированную кнопку удаления страницы из индекса.
Если требуется запрет индексирования публичной страницы, применяют подходящий механизм, например noindex в метатеге или HTTP-заголовке. Роботу необходимо получить страницу, чтобы прочитать такое указание. Одновременный запрет обхода способен этому помешать. Строка Noindex: / внутри robots.txt не заменяет корректное правило на самой странице.
Конфиденциальность требует контроля доступа
Личные кабинеты, внутренние документы и служебные данные защищают авторизацией и настройками доступа. Robots.txt публичен, а перечисленные в нём пути может прочитать любой посетитель. В RFC 9309 отдельно указано, что протокол не заменяет защиту содержимого. Не переносите секретные адреса в этот файл в надежде спрятать их.
Где должен находиться файл robots.txt
Для сайта https://example.com/ рабочий адрес файла — https://example.com/robots.txt. Он располагается в корне соответствующего сайта, а не в папке статьи, шаблона или изображений. Имя пишется строчными буквами. Файлы Robots.txt, robots.txt.txt и /blog/robots.txt не следует считать равнозначными правильному адресу.
По инструкции Google по созданию файла правила относятся к определённому сочетанию протокола, хоста и порта. Файл на https://example.com/ не управляет автоматически http://example.com/, https://www.example.com/ и https://shop.example.com/. Для нестандартного порта также проверяют соответствующий адрес файла.
Это особенно важно после подключения поддомена, смены основной версии или переноса сайта. Составьте список реально работающих адресов и уточните, где должен выдаваться каждый robots.txt. Доменный ресурс в поисковой панели может объединять сведения о нескольких хостах, но он не превращает их файлы в один общий набор правил.
Создавайте обычный текстовый файл в UTF-8 и отдавайте его как text/plain. Для редактирования подходит текстовый редактор, а не документ Word с форматированием. Если файл генерируется приложением, физического robots.txt на диске может не быть: важен опубликованный ответ по нужному URL и понятный источник его настройки.
Основные директивы robots.txt
Каждая инструкция занимает отдельную строку: название, двоеточие и значение. Названия директив не чувствительны к регистру, но пути нужно проверять с учётом регистра символов. Используйте единый аккуратный стиль, чтобы следующий специалист мог понять файл без догадок.
| Директива | Назначение | На что обратить внимание |
|---|---|---|
User-agent | Определяет робота или группу, для которых записаны последующие правила | Общая группа обозначается звёздочкой; отдельная группа может изменить применимый набор |
Disallow | Запрещает обход совпадающих адресов | Путь задают относительно корня, а не полным URL |
Allow | Разрешает обход совпадающих адресов, в том числе как исключение | Нужна проверка совместно со всеми подходящими запретами |
Sitemap | Сообщает абсолютный адрес карты сайта | Нужны протокол и хост; строка не отменяет Disallow |
В спецификации Google перечислены поддерживаемые поля. Не добавляйте похожие на команды слова из старых шаблонов, не проверив их назначение. Синтаксически аккуратная строка может не иметь действия, если конкретный робот её не поддерживает.
Пустой Disallow и полный запрет — разные записи
Запись Disallow: без пути не задаёт запрета. Если это единственное правило выбранной группы, обход ею не ограничен. Но пустая строка Disallow не удаляет другие существующие запреты. Напротив, Disallow: / совпадает со всеми путями и при отсутствии применимых разрешающих исключений закрывает их от обхода для соответствующей группы.
Полный запрет нередко остаётся после разработки. Перед запуском проверьте именно рабочий ответ, а не настройку в тестовой среде. При этом один robots.txt не защищает тестовый сайт от посторонних: для закрытой среды всё равно нужен настоящий контроль доступа.
Комментарии и карта сайта
Символ # начинает комментарий до конца строки. Используйте его для короткого объяснения назначения нестандартного правила, но не для хранения паролей, токенов или личных данных. В строке Sitemap указывают полный опубликованный URL карты, например https://example.com/sitemap.xml. Для Google такая строка не привязана к отдельному User-agent и не меняет разрешения на обход.
Как выбираются группы роботов и приоритет правил
Перед анализом конкретного запрета нужно определить, какой блок прочитает робот. Нельзя считать, что все группы файла просто складываются. Создавайте отдельную секцию только тогда, когда для неё есть понятное отличие, и храните нужные правила вместе.
Особенности Google
Google выбирает наиболее подходящую по имени робота группу. Общая секция User-agent: * не дополняет автоматически выбранную специальную секцию. Если для одного подходящего User-agent записано несколько групп, Google объединяет их правила; порядок групп не служит способом задать приоритет. Такое поведение описано в разделе о выборе User-agent.
Практическая ошибка выглядит так: в общей группе закрыт технический раздел, затем добавлена отдельная группа Googlebot только с одним разрешением. Разработчик ожидает наследования всех общих запретов, но выбранный набор изменился. Поэтому после появления новой секции нужно повторно проверить ранее закрытые адреса.
Особенности Яндекса
По документации Яндекса наличие подходящей группы User-agent: Yandex исключает применение общей группы со звёздочкой. Если заданы правила для конкретного робота Яндекса, более общие группы для него не используются. Отдельные служебные роботы имеют особенности, поэтому название агента выбирают по справке, а не угадывают.
Не переносите способ объединения повторных групп Google на другие системы без проверки. Для сопровождаемого файла удобнее одна понятная секция для каждого целевого набора правил. Между группами оставляйте пустую строку, а внутри группы располагайте User-agent и его Allow/Disallow последовательно, без пустых разделителей.
Как разрешается конфликт Allow и Disallow
Для Google и Яндекса имеет значение наиболее конкретное подходящее правило, а не просто последняя строка файла. При равнозначном конфликте соответствующих разрешения и запрета предпочтение отдаётся Allow; Яндекс описывает это через длину совпадающего префикса. Проверяйте итог для реального URL, особенно если используются маски.
Пути, маски, параметры и кириллические адреса
Обычный путь работает как префикс. Например, /draft может затронуть не только /draft, но и /drafts/ или /draft-guide/. Если нужно ограничить конкретную папку, завершающий слеш имеет значение. Адреса /internal-search и /internal-search/ тоже следует проверять отдельно, даже если сайт перенаправляет один в другой.
В поддерживаемых Google и Яндексом масках * обозначает произвольную последовательность символов, включая пустую, а $ фиксирует конец совпадения. Это ограниченный синтаксис, а не полноценный язык регулярных выражений. Круглые скобки и другие конструкции из правил веб-сервера нельзя переносить сюда автоматически.
Почему важны параметры и похожие адреса
Правило для точного URL с $ может перестать совпадать после добавления параметров. В тестовый набор включайте варианты с фильтром, сортировкой и метками, если они используются на сайте. Запрет всех адресов с вопросительным знаком способен закрыть полезные страницы, поэтому решение принимают по назначению конкретного параметра.
У Яндекса есть отдельная директива Clean-param для параметров, которые не меняют содержимое. Она не является универсальной командой для всех поисковиков и не подходит для удаления значимых различий между товарами, языками или валютами. Работа с такими параметрами требует отдельного решения о дублях.
Не добавляйте фрагмент после # как часть правила. Например, Disallow: /#section будет прочитано как запрет /, потому что остальное станет комментарием. Это короткая опечатка с широким последствием; проверяйте не только отсутствие синтаксической ошибки, но и фактический смысл строки.
Кириллица и кодирование
Поддержка не полностью одинакова. Google описывает сопоставление UTF-8 и процентного кодирования, а Яндекс рекомендует кодированные пути и Punycode для доменных имён. Для русскоязычных URL проверяйте опубликованный адрес и его представление в анализаторе. Не считайте визуально похожие строки одинаковыми без проверки результата.
Условный пример robots.txt и ожидаемое поведение
Предположим, на сайте есть раздел внутренних поисковых результатов /internal-search/, обход которого решено ограничить. Внутри него расположена публичная справочная страница /internal-search/help, которую нужно оставить доступной. Условный файл для этой задачи выглядит так:
User-agent: *
Disallow: /internal-search/
Allow: /internal-search/help$
Sitemap: https://example.com/sitemap.xmlЭто учебная модель для роботов, использующих общую группу. Она не предназначена для автоматической установки на любой сайт и не означает удаления уже известных поиску страниц. Если задача состоит в исключении результатов внутреннего поиска из индекса, одного запрета обхода недостаточно: нужно согласовать отдельную политику индексирования.
| Проверяемый путь | Ожидание по этому примеру | Что проверяет строка |
|---|---|---|
/ | Обход разрешён | Главная не закрыта общим запретом |
/catalog/item/ | Обход разрешён | Основной каталог не затронут |
/internal-search/?q=example | Обход запрещён | Префикс охватывает поисковую выдачу |
/internal-search/help | Обход разрешён | Работает точное исключение |
/internal-search/help?mode=compact | Обход запрещён | Параметр не подходит под исключение с $ |
/internal-searching/ | Обход разрешён | Похожее название не попало под префикс папки |
Все результаты таблицы относятся только к показанным правилам. Они не подтверждают HTTP-доступность или включение адресов в индекс. Добавьте к такой матрице конкретного робота, фактический результат анализатора и дату проверки. Если для одного агента есть специальная группа, ожидания нужно пересчитать по ней.
Для своего проекта начинайте с списка примеров, а уже затем пишите маски. Владелец сайта должен понимать, какие страницы должны оставаться открытыми и почему. Так проще согласовать изменение с разработчиком и обнаружить слишком широкий запрет до публикации.
Как создать файл в CMS или конструкторе
Сначала определите, кто отвечает на запрос /robots.txt: веб-сервер, CMS, SEO-модуль, конструктор или промежуточный сервис. Наличие файла на диске ещё не показывает, что посетитель получает именно его. Если на сайте действуют несколько источников, установите один понятный порядок формирования и публикации правил.
- Сохраните текущий опубликованный текст и дату получения.
- Найдите штатное место редактирования в вашей платформе.
- Согласуйте назначения разделов и подготовьте тестовые URL.
- Измените только нужные правила и проверьте весь итоговый файл.
- Опубликуйте изменение предусмотренным способом и снова прочитайте рабочий ответ.
Если используется физический файл, уточните у администратора корень нужного виртуального хоста. Если файл генерируется CMS, сохранение произвольной копии в другой папке не решает задачу. При автоматическом выпуске включите настройку в процесс обновления, чтобы следующий релиз не вернул старые ограничения.
Что учитывать на Wix
В официальной инструкции Wix описан Robots.txt Editor в панели SEO & GEO, в разделе инструментов и настроек. Через него можно просмотреть, изменить и сохранить файл, а при необходимости вернуть состояние по умолчанию. Используйте доступный в текущей панели инструмент и после сохранения проверяйте опубликованный URL.
При сообщении о блокировке проверьте также настройки видимости конкретных страниц, доступ по паролю и разделы для участников. Редактирование robots.txt не должно случайно менять назначение закрытых страниц. Не добавляйте в файл универсальные пути чужой CMS: у вашего конструктора они могут отсутствовать или означать другое.
Как проверить опубликованный файл и ответ сервера
Откройте точный адрес robots.txt в обычной независимой сессии без авторизации. Сверьте содержимое с подготовленной версией. Затем проверьте HTTP-статус, Content-Type и возможные перенаправления. Вместо правил сервер не должен незаметно отдавать главную страницу, сообщение об ошибке или проверку браузера.
При работе через CDN сопоставьте ответ посетителю с источником формирования файла. Если новая версия сохранена в CMS, но снаружи виден старый текст, исследуйте правила кэша и маршрут запроса. Очистка нужной копии может быть частью выпуска, однако сама по себе не подтверждает, что поисковик уже получил обновление.
Что означают ошибки получения robots.txt
Поведение зависит от поисковой системы и вида ошибки. По документации Google, ответ 404 для robots.txt не закрывает весь сайт: он означает отсутствие ограничений из этого файла. Остальные 4xx, кроме 429, обрабатываются так же. Поэтому 401 или 403 на самом robots.txt не служат надёжным способом ограничить обход.
Ошибки сервера и сети рассматриваются иначе: Google может приостановить обход, затем использовать сохранённую успешную версию и продолжать попытки получения. Не подменяйте такую ситуацию выводом «файл отсутствует, значит всё разрешено». Для Яндекса проверяйте его собственные требования к доступному файлу и итоговый ответ после перенаправлений; особенности Google не являются универсальной инструкцией.
Для приёмки нового файла удобен прямой ответ 200 с нужным текстом. Если перенаправление предусмотрено архитектурой, проследите его до конечного robots.txt и проверьте применимость правил к исходному сайту. Случайная переадресация на общую страницу поддержки не заменяет файл.
Почему изменения видны не сразу
Роботы могут хранить полученную версию. Google отдельно описывает кэширование robots.txt, включая продление использования копии при проблемах обновления. Сравнивайте дату последней загрузки в панели с датой выпуска. Обновлённый файл в браузере и обновлённые правила у поисковика — два разных подтверждения.
Проверка robots.txt в Google и Яндексе
Анализатор нужен для проверки синтаксиса и совпадения URL с правилами. Однако название «robots.txt validator» само по себе не говорит, чьё поведение он воспроизводит. Выясните, какой парсер используется, загружается ли живой файл и учитываются ли особенности нужного робота. Результат универсального онлайн-сервиса дополняет официальные инструменты.
Яндекс Вебмастер
Откройте «Инструменты → Анализ robots.txt», выберите нужный сайт или укажите адрес. Можно загрузить опубликованный файл либо проверить подготовленный текст. Затем добавьте разрешённые и запрещённые примеры в блок проверки доступа к страницам. Справка анализатора объясняет проверку директив и отдельных URL.
Сохраните результаты для пограничных случаев: похожая папка, адрес без слеша, параметр, исключение Allow. При ошибке найдите конкретную строку и причину в справочнике ошибок Яндекса. Успех анализа не означает, что страницы уже участвуют в поиске; он подтверждает только проверенную часть настройки.
Google Search Console
Актуальный отчёт robots.txt показывает сведения о получении файлов, дату проверки, ошибки и сохранённые версии. Он доступен для доменного ресурса или URL-префикса на уровне хоста без пути. Охват отчёта ограничен; отсутствие отдельного хоста в общей таблице не доказывает отсутствие его файла.
Сопоставьте загруженную Google версию с опубликованной. Для конкретной страницы используйте проверку URL и отдельно читайте признак разрешённого сканирования. Успешный живой тест не гарантирует индексирование — ограничения описаны в справке инструмента. После исправления критичной ошибки отчёт robots.txt позволяет запросить повторную загрузку файла, но это не обещание немедленного обхода всех открытых страниц.
Как опубликовать изменения и принять результат
Перед выпуском сохраните прежнюю рабочую версию и договоритесь, кто может её вернуть. Для каждого изменения запишите назначение и ожидаемые URL. Если правило затрагивает весь сайт или большой раздел, проверяйте его вместе с ответственным за продвижение, а не только на одном удобном примере.
После публикации повторите матрицу по каждому нужному роботу и хосту. Дополнительно проверьте доступность важных CSS, JavaScript и изображений: блокировка ресурсов может мешать поисковой системе понимать страницу. Не закрывайте все технические папки только по названию; внутри могут находиться необходимые файлы оформления и данные для рендеринга.
- По правильному адресу выдаётся ожидаемый текст и понятный HTTP-ответ.
- Важные публичные страницы и необходимые ресурсы проходят проверку.
- Запланированные ограничения действуют только в согласованных пределах.
- Исключения Allow и параметры проверены на положительных и отрицательных примерах.
- Сохранены дата выпуска, прежняя версия, ответственный и результаты проверок.
- Позднее подтверждено получение новой версии нужной поисковой системой.
При случайном запрете сначала восстановите согласованные правила и проверьте рабочий ответ, затем наблюдайте получение обновления и доступность страниц. Не открывайте все разделы наугад: такая правка может уничтожить другие нужные ограничения. Возврат старого файла тоже нужно проверять, поскольку копия могла относиться к прежней структуре сайта.
Подготовьте URL файла, примеры затронутых страниц и ожидаемое поведение: с такими данными проще сформулировать задачу и оценить результат настройки.
Проверку правил robots.txt дополните регулярным контролем доступности важных публичных страниц. Оцените SiteGuard для мониторинга сайта после публикаций и изменений конфигурации.
Ошибки, которые полезно проверить в первую очередь
| Ошибка | Возможное последствие | Что проверить |
|---|---|---|
| Disallow: / остался после разработки | Важные страницы закрыты от обхода | Применимую группу, исключения и рабочий ответ |
| Слишком короткий префикс | Правило захватывает соседние разделы | Похожие пути, слеш и точное окончание |
| Новая группа робота без прежних правил | Общие ограничения больше не применяются | Полный набор для выбранного User-agent |
| HTML или старый текст вместо файла | Проверяется не та конфигурация | Маршрут, CMS, кэш и конечный ответ |
| Запрет ресурсов оформления | Робот видит неполную страницу | Рендеринг и необходимые CSS, JavaScript, изображения |
| Ожидание удаления URL из индекса | Правила решают другую задачу | Цель ограничения и подходящий способ индексирования |
Исправляйте причину в том месте, где файл реально формируется. Если текст возвращается после каждой публикации, ручная замена готовой копии будет временной мерой. Для устойчивого результата нужен понятный источник правил и проверка после изменений CMS, домена, шаблонов и серверной конфигурации.
Частые вопросы о robots.txt
Нужен ли robots.txt каждому небольшому сайту?
Не обязательно создавать ограничения только ради наличия файла. Если весь публичный сайт предназначен для обхода и лишних технических вариантов нет, сложные запреты могут не понадобиться. Решение принимают по структуре и задачам проекта, а отсутствие файла не означает автоматическое закрытие от Google.
Можно ли скопировать robots.txt у конкурента?
Чужой файл описывает другие пути, платформу и правила. Одинаковые названия папок могут иметь разное назначение. Используйте примеры для изучения синтаксиса, затем составьте собственную матрицу URL и проверьте её. Самая полезная конфигурация — та, которую команда может объяснить и воспроизвести.
Нужно ли добавлять Crawl-delay?
Не используйте его как универсальную настройку скорости: Google не поддерживает эту директиву, а Яндекс также перестал её учитывать. Для управления нагрузкой исследуйте реальные обращения и актуальные инструменты соответствующей поисковой системы.
Почему файл правильный, а страница всё равно не индексируется?
Разрешённый обход — только одно условие. Дальше имеют значение доступность и содержимое страницы, запреты в метатегах или заголовках, выбранный канонический адрес и решение поисковой системы. Не меняйте исправный robots.txt без доказательств: сначала установите, на каком этапе возникает проблема.
Как часто проверять настройки?
Включите проверку в выпуск изменений структуры, поддоменов, SEO-модулей и серверных правил. Дополнительно реагируйте на уведомления о получении файла и неожиданные изменения обхода. Регулярность выбирайте по частоте обновлений проекта; главное — сохранять версии и повторяемый набор проверок.