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

Статья:

Robots.txt — текстовый файл в корне сайта, который отвечает не за индексацию, а за доступ роботов к сканированию. Лежит по адресу https://site.ru/robots.txt. Проверить его доступность за 5 секунд можно командой:

curl -IL https://ваш-сайт.ru/robots.txt

Если в ответе не 200 OK и не Content-Type: text/plain — у вас уже проблема: файл отдаётся с 404, редиректит на версию с ошибкой сертификата, или CDN подменяет его страницей-заглушкой. В любом из этих случаев поисковик считает сайт полностью открытым для обхода — это не «безопасный дефолт», а источник неожиданных страниц в индексе.

Главная путаница: сканирование ≠ индексация

Robots.txt не убирает страницы из выдачи. Рабочий сценарий, который встречается регулярно: вы закрываете раздел через Disallow, а через месяц находите его в Google с пометкой «Описание веб-страницы недоступно из-за ограничений в файле robots.txt». Это значит: Google узнал про URL из внешней ссылки или из старого индекса, зайти не может (запрещено), но и выкинуть не торопится — оставляет «слепую» запись в выдаче.

Правило на практике:

• Хотите скрыть страницу из выдачи насовсем → ставьте meta noindex, страница при этом должна остаться ОТКРЫТОЙ для сканирования (иначе робот физически не увидит тег). Подробнее о том, как правильно использовать noindex и nofollow, читайте в статье Noindex и nofollow: как правильно применять и не терять индексацию .
• Хотите сэкономить краулинговый бюджет на служебных URL (фильтры, поиск, корзина, сортировки) → закрывайте через Disallow.
• Никогда не совмещайте Disallow + noindex на одном URL — робот не дойдёт до тега, и мусорный сниппет останется в выдаче на неопределённый срок.

Рабочий пример файла

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

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Allow: /

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

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

Разбор по типам сайтов — что реально закрывать

Живой пример: на Bitrix-магазине фильтр «цвет + размер + бренд + наличие» даёт десятки тысяч комбинаций URL. Диагностика: Search Console → «Настройки» → «Статистика сканирования» → график по типам ответов и датам. Если основная масса запросов идёт на параметрические адреса, а новые карточки товара обходятся раз в 2–3 недели — это симптом слитого краулингового бюджета, а не «Google сам разберётся». Решение — Disallow по маске параметра плюс canonical на чистый URL карточки. Как рационально распределять crawl budget, читайте в статье Crawl budget: где бот тратит время впустую и как это исправить . Если вы сталкиваетесь с тем, что в индексе появляются URL, заблокированные в robots.txt, см. руководство Indexed, though blocked by robots.txt: как найти причину и вычистить статус в 2026 году .

Если у вас несколько сайтов (PBN‑сеть) и нужно быстро свести список закрытых и открытых директив по всем доменам сразу, не открывая каждый robots.txt руками — для массового парсинга своих же URL и правил используют A-Parser: собирает данные по списку доменов за один проход, удобно перед аудитом сети.

AI-краулеры в 2026 году

К классическим ботам добавился отдельный слой AI-краулеров, и каждый ведёт себя по‑своему:

• GPTBot, ChatGPT-User — OpenAI, обучение моделей и живой поиск ChatGPT.
• ClaudeBot, Claude‑Web — Anthropic.
• Google‑Extended — отдельный сигнал для Gemini и AI Overviews, никак не влияет на обычный Googlebot.
• PerplexityBot, Applebot‑Extended, YandexAdditional.

Если хотите попадать в ответы AI‑поиска (ChatGPT Search, AI Overviews) — не блокируйте соответствующего бота. Если не хотите отдавать контент на обучение моделей, но не против попадания в живой поиск — разделяйте GPTBot (обучение) и ChatGPT-User (live‑запросы пользователя) отдельными блоками: это разные боты с разным назначением. Практическую настройку AI‑ботов и взаимодействие с Cloudflare можно посмотреть в статье Блокировать ли AI‑ботов: практическая настройка robots.txt, логов и Cloudflare .

Отдельно проверьте настройки CDN. У Cloudflare с начала 2026 года переключатели живут в разделе AI Crawl Control (бывший AI Audit) — там боты режутся ДО того, как запрос вообще доходит до вашего origin‑сервера и до самого файла robots.txt. Если в панели Cloudflare стоит блокировка бота, а в robots.txt он разрешён — победит Cloudflare. Проверяйте оба места, иначе рискуете чинить несуществующую проблему в robots.txt.

Типичные ошибки — и что делать при каждом симптоме

• Видите Disallow: / на боевом домене → сайт целиком закрыт от сканирования. Обычно это остаток тестового окружения. Действие: убрать директиву немедленно, в Search Console → «Индекс» → «Страницы» проверить, сколько URL получили статус «Заблокировано robots.txt», и запросить повторное сканирование через «Проверку URL» для ключевых страниц.
• Заблокированы /wp-content/, /assets/, .css, .js → поисковик не может отрисовать страницу и может посчитать её пустой или сломанной в отчёте «Просмотреть просканированную страницу». Действие: открыть статику для ботов, оставить закрытыми только реально служебные пути.
• В sitemap.xml есть URL, которые закрыты в robots.txt → поисковик видит конфликт и доверяет robots, карта в этой части игнорируется. Действие: свести список — либо убрать URL из sitemap, либо снять Disallow.
• Кириллица в путях без percent‑encoding → большинство ботов сейчас понимают UTF‑8, но при копировании путей в сторонние сервисы аудита случаются рассинхроны. Действие: кодировать кириллические сегменты в директивах.
• Страница висит в GSC 3+ недели в статусе «Обнаружено, не проиндексировано», хотя доступна в robots → дело обычно не в robots.txt, а в приоритете краулингового бюджета. Проверьте через Rush Analytics — сервис умеет массово проверять статус индексации по списку URL и сразу показать, у скольких страниц раздела реально такая проблема, вместо ручной проверки по одной странице в Search Console.

Как проверить файл у себя

• Google Search Console → «Настройки» → «Сканирование» → отчёт по robots.txt: история последних загруженных версий файла, ошибки парсинга построчно и по конкретному User-agent. Отдельного «robots.txt Tester» как раньше уже нет — актуальный путь именно этот. При проверке обращайте внимание на crawl budget, подробнее в статье Crawl budget: где бот тратит время впустую и как это исправить .
• Яндекс.Вебмастер → «Инструменты» → «Анализ robots.txt»: вставляете конкретный URL, инструмент показывает, какое именно правило его блокирует или разрешает.
• Быстрая проверка вручную: открыть https://ваш-сайт.ru/robots.txt прямо в браузере — если вместо текста видите HTML‑страницу 404 или редирект, файл не работает так, как вы думаете.
• Для точечной проверки одной проблемной страницы — как она реально видна поисковику прямо сейчас, с учётом robots и мета‑тегов — быстрее прогнать URL через экспресс‑анализ Pr‑CY, чем вручную сверять три источника.

После правки: не забудьте про переобход

Открыли раньше закрытый раздел — сам факт правки robots.txt не ускоряет переобход, робот придёт по своему графику, это может занять недели. Если раздел коммерчески важен (например, вернули в индекс категорию каталога), для новых или переоткрытых URL имеет смысл ускорить обход через индексатор SpeedyIndex — это быстрее, чем ждать естественного краулинга, особенно на сайтах, где Googlebot и так заходит редко.

Связанные термины

• meta noindex и X‑Robots‑Tag — управляют индексацией, а не сканированием; главное отличие от robots.txt.
• sitemap.xml — список рекомендуемых для обхода адресов, должен быть согласован с robots.txt, а не противоречить ему.
• crawl budget — лимит запросов, которые поисковик готов потратить на сайт за период; параметрические URL и дубли — главные пожиратели этого лимита.
• IndexNow — отдельный протокол push‑уведомлений о новых и изменённых страницах для Яндекса и Bing, не связан с robots.txt напрямую.