Что такое robots.txt в 2026 году: как настроить, проверить и не потерять индексацию

Кратко

robots.txt — текстовый файл в корне хоста, который сообщает совместимым роботам, какие URL можно сканировать. Он не является механизмом безопасности и не предназначен для удаления страницы из поиска. Если нужно запретить индексацию HTML-страницы, обычно используют noindex или авторизацию; робот должен иметь возможность получить страницу и увидеть директиву.

Перед изменением файла проверьте три вещи: правильный адрес /robots.txt, реальный HTTP-ответ и влияние правила на нужный User-Agent. Ошибка в robots.txt может закрыть весь сайт, но и слишком широкое разрешение не решает проблему дублей, canonical или некачественного контента.

Что контролирует robots.txt

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

Google прямо описывает robots.txt как инструмент управления обходом, а не как способ скрыть страницу из поиска. Полная формулировка и ограничения приведены в официальном руководстве Google по robots.txt .

Где должен лежать файл

Файл находится только по адресу /robots.txt на конкретном протоколе, хосте и порту. https://www.site.example/robots.txt не управляет автоматически https://site.example/robots.txt, а файл в /blog/robots.txt не заменяет файл в корне.

Проверьте отдельно варианты, которые реально используются на сайте:

• HTTP и HTTPS;
• с www и без www;
• основной домен и поддомены;
• CDN-адрес и origin, если они доступны извне.

Формат — UTF-8 plain text. В файл можно добавить Sitemap с полным URL. Не помещайте туда HTML-страницу, JavaScript или настройки, которые относятся только к панели CMS.

Как читать HTTP-ответ

Быстрая проверка:

curl -i https://site.example/robots.txt

Оценивайте не только строку 200 OK, но и тело ответа:

Проверьте Content-Type, кодировку и отсутствие HTML-заглушки от CDN. Google умеет разбирать текст, но ошибка маршрутизации или WAF может отдавать не тот файл. Сверяйте также заголовки кеширования: исправление на origin не означает мгновенное изменение копии на CDN.

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

Базовая структура — группа User-agent и правила Allow/Disallow:

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /search
Disallow: /*?sort=

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

Для конкретного робота Google выбирает наиболее специфичную группу User-Agent; глобальная группа * не объединяется с ней автоматически. Внутри применимых правил учитывается наиболее длинное совпадение пути. Поэтому порядок строк сам по себе не исправляет конфликт — важнее, какой User-Agent и какой путь проверяются.

Пустой Disallow: не закрывает путь. Disallow: / закрывает весь хост для выбранной группы и требует особенно внимательной проверки. Директивы вроде crawl-delay не являются универсально поддерживаемым способом управления Googlebot и не должны подменять контроль нагрузки на сервере.

Безопасный пример для сайта

Начинайте с минимального файла и добавляйте правила только после проверки URL:

User-agent: *
Disallow: /admin/
Disallow: /search
Disallow: /*?sort=

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

Не закрывайте автоматически /assets/, .css и .js: если ресурс нужен для понимания страницы, его блокировка ухудшит рендеринг. Не добавляйте одновременно все возможные маски параметров — сначала найдите реальные URL в логах и Search Console.

Для AI-ботов используйте отдельную политику, а не копируйте совет из старой статьи. Например, GPTBot, OAI-SearchBot и ChatGPT-User имеют разные сценарии; разбор их назначения и проверки WAF есть в статье о разделении OpenAI-ботов . Правила конкретного сервиса проверяйте по его текущей документации.

Что закрывать для разных типов сайтов

Canonical не исправляет запрет обхода сам по себе. Если Google не может прочитать страницу, он не увидит её meta robots или canonical. Для директив индексации используйте документацию Google по robots meta tag и X-Robots-Tag .

Проверка после публикации

Проверяйте файл как минимум на одном важном URL каждого закрытого раздела:

1. Получите /robots.txt с внешнего соединения и сохраните код ответа, тело и дату.
2. Проверьте, какой User-Agent должен применять группу правил.
3. Сопоставьте URL с каждой маской: путь, регистр, параметры и кодированный символ могут менять результат.
4. Проверьте, что важные страницы не попали под Disallow, а закрытые URL не остались в sitemap без причины.
5. Посмотрите access log и WAF/CDN: robots.txt не отменяет блокировку на уровне инфраструктуры.
6. Для страницы, которую нужно убрать из поиска, проверьте доступность HTML и наличие noindex; не закрывайте её от робота до проверки.

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

Типичные ошибки

• Disallow: / остался от тестового окружения — весь сайт перестаёт нормально обходиться.
• В robots.txt закрыт /assets/ или .js — робот теряет ресурсы, необходимые для рендера.
• В sitemap перечислены URL, которые одновременно запрещены — карта не отменяет Disallow.
• Для noindex заблокирован сам URL — робот не может прочитать директиву.
• Файл доступен на origin, но CDN отдаёт старую версию или 403.
• В правило добавлены рекомендации для чужого User-Agent без проверки его актуальной документации.

Итоговый чек-лист

• Файл расположен в корне нужного host/protocol/port.
• Ответ стабилен, тело — UTF-8 plain text, без HTML-заглушки.
• Группы User-Agent проверены отдельно.
• Disallow закрывает только подтверждённые служебные URL.
• Важные страницы, ресурсы и sitemap доступны.
• Для удаления из поиска используется noindex или авторизация, а не один robots.txt.
• После публикации проверены CDN, WAF, логи и несколько реальных URL.

Источники

• Google: Introduction to robots.txt
• Google: How Google interprets the robots.txt specification
• Google: Robots meta tag and X-Robots-Tag