SEO-Studio
Блог · SEO

robots.txt типичные ошибки и как их избежать

Разбирает типичные ошибки robots.txt, разницу между Disallow и noindex и даёт чек проверки в Search Console после каждой правки.

~3 мин чтения SEO

Файл robots.txt на сервере с пометками Disallow и Sitemap

Синтаксис robots.txt без сюрпризов

Пример корректного User-agent Disallow Allow и строки Sitemap
User-agent, Disallow, Allow и Sitemap — четыре базовые директивы. Ошибка в одном символе ломает правило для всего блока.

robots.txt — текстовый файл в корне домена, который подсказывает краулерам, что можно сканировать. Официальные правила в документации Google о robots.txt.

Минимальный рабочий шаблон для WordPress:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml
  • Каждый User-agent начинает новый блок правил.
  • Disallow запрещает префикс пути. Пустой Disallow ничего не блокирует.
  • Allow сужает Disallow — полезно для admin-ajax и отдельных подпутей.
  • Регистр и слеши важны. /page и /page/ — разные правила.

Файл должен отдаваться с HTTP 200 и типом text/plain. Редирект с www на non-www не должен ломать путь к robots.txt.

Disallow против noindex и crawl budget

Схема конфликта Disallow и noindex когда бот не видит HTML
Disallow блокирует сканирование, но не убирает страницу из индекса. Noindex в HTML бот не увидит, если URL закрыт в robots.txt.

Самая частая путаница. Disallow говорит «не заходи сканировать», но не гарантирует удаление из индекса. noindex в HTML/meta говорит «не показывай в выдаче», но бот должен увидеть страницу. Подробнее о разнице noindex и robots.txt.

  • Закрыли noindex-страницу в Disallow — Google может не прочитать директиву и держать URL в выдаче.
  • Надеетесь, что Disallow «сэкономит» crawl budget — бот часто всё равно тратит обход на проверку, а страница остаётся в индексе.
  • Блокируете CSS/JS (/wp-content/, /_next/static/) — ломается рендер и индексация SPA.
  • Дублируете противоречивые правила для разных user-agent без теста.
  • Забыли убрать Disallow со staging после переноса на прод.

Правильная схема для служебных URL. Сначала разрешить сканирование, поставить noindex в шаблоне, затем при необходимости ограничить только то, что точно не должно попасть в индекс и не требует проверки.

Проверка в Search Console

Интерфейс тестера robots.txt в Google Search Console
После каждой правки прогоняйте критичные URL через тестер в Search Console и URL Inspection.

После каждого изменения robots.txt проверяйте не «в целом ок», а конкретные URL.

  1. Откройте тестер robots.txt в Search Console. Подайте пути главной, категорий, sitemap, wp-admin.
  2. В URL Inspection проверьте «Page fetch» и «Indexing allowed?» для эталонных страниц.
  3. В отчёте Page indexing ищите «Blocked by robots.txt» для важных шаблонов.
  4. Сверьте live-версию файла (curl -I https://site/robots.txt) с тем, что редактировали в CMS/CDN.
  5. Если есть кеш CDN — сбросьте его после правки, иначе Google видит старую версию.

Строка Sitemap и приоритеты обхода

Строка Sitemap в robots.txt и связь с crawl budget
Sitemap в robots.txt не заменяет чистую структуру URL, но помогает Google быстрее найти карту после изменений.

Директива Sitemap: указывает на XML-карту сайта. Она не заменяет внутренние ссылки, но ускоряет нахождение карты после миграций.

  • Указывайте абсолютный URL с https и правильным доменом (www или без).
  • Для мультиязычных сайтов — индексную sitemap или отдельные строки на каждый язык.
  • Не добавляйте в sitemap URL, закрытые Disallow — сигналы противоречат друг другу.
  • После больших релизов проверьте, что новая sitemap доступна и не возвращает 404.

Заключение

robots.txt управляет сканированием, а не индексацией напрямую. Не путайте Disallow с noindex, не режьте статику, тестируйте критичные URL в Search Console и держите Sitemap актуальной. Если нужен аудит robots.txt вместе со структурой сайта, команда SEO-Studio поможет найти конфликты до того, как они ударят по индексации.