robots.txt: что блокировать, что разрешать
Один из клиентов прошлой зимой жаловался: «Сайт в Google не находится вообще. По собственному названию бренда — нас нет в выдаче. Что вы сделали?» Сайт месяц назад переехал на новый сервер, всё работало, дизайн новый, контент на месте. Но в индексе — ноль страниц. Совсем ноль.
Открыл https://site.com/robots.txt. Там было четыре строки:
User-agent: *
Disallow: /
Всё. Сайт полностью закрыт от всех поисковиков. Эту настройку оставили со staging-окружения — когда сайт ещё разрабатывали и не хотели, чтобы его индексировали. При деплое на прод файл просто скопировали как есть. Никто не проверил.
Чтобы починить, потребовалось десять секунд: убрать / после Disallow. Чтобы Google обратно проиндексировал сайт — три недели. Чтобы вернуть органический трафик — полгода. Месяц без индексации = потерянные сигналы, потерянные позиции, потерянные пользователи.
robots.txt — один из самых опасных файлов на сайте. Не потому что сложный. Наоборот — потому что слишком простой. Это plain text, четыре директивы, нет валидатора в IDE, нет автотестов. Перепутал слеш, поставил wildcard не в том месте — и пол-сайта пропало из выдачи. Никто не предупреждает. Никто не подсветит ошибку красным. Google молча перестаёт ходить туда, куда ты ему запретил, и ты узнаёшь об этом через две недели, когда позиции уже посыпались.
В этом посте — что делать, чтобы не повторить мою историю.
Что такое robots.txt
Текстовый файл, который лежит в корне домена: https://example.com/robots.txt. Не в подпапке, не в подкаталоге — именно в корне, иначе боты его не найдут. Один файл на один хост. Если у тебя поддомены — у каждого свой robots.txt.
Это часть стандарта REP — Robots Exclusion Protocol. Стандарт древний, 1994 года, родился до того, как поисковики стали тем, чем стали. В 2022 году IETF наконец сделал из него RFC 9309 — формально документированный стандарт. До этого каждый бот интерпретировал robots.txt как хотел.
По сути это инструкция для краулеров: какие пути на сайте они не должны сканировать. Google, Bing, Yandex, DuckDuckGo и большинство нормальных ботов её соблюдают. ChatGPT тоже теперь смотрит на robots.txt — через директивы для GPTBot и ClaudeBot. Скам-краулеры и парсеры её обычно игнорируют, потому что это не запрет, это просьба.
Две вещи, которые robots.txt НЕ делает:
robots.txt — это не безопасность. Любой может открыть site.com/robots.txt и прочитать список того, что ты закрыл. Если ты пишешь там Disallow: /secret-admin-panel/ — ты только что подсветил адрес секретной админки всему интернету. Закрывать приватные пути через robots.txt — то же самое, что вешать табличку «здесь сейф» на дом без замка.
robots.txt — это не noindex. Disallow запрещает ходить на страницу. Но если на эту страницу есть ссылки с других сайтов, Google всё равно может показать её в выдаче — с пустым сниппетом и пометкой «No information is available for this page». Хочешь убрать страницу из индекса навсегда — нужен noindex, не robots.txt.
Базовый синтаксис
Файл состоит из блоков. Каждый блок начинается с User-agent, дальше идут директивы.
User-agent: *
Disallow: /admin/
Allow: /admin/public/
Sitemap: https://example.com/sitemap.xml
User-agent: * — правила для всех ботов сразу. Звёздочка означает «любой краулер».
User-agent: Googlebot — правила только для Google. Если хочешь разные правила для разных ботов, делаешь отдельные блоки. Googlebot читает свой блок и игнорирует блок со звёздочкой. Если для конкретного бота блока нет — он читает общий со звёздочкой.
Disallow: /admin/ — запрещает всё, что начинается с /admin/. То есть и /admin/, и /admin/users, и /admin/settings/permissions. Слеш в конце важен: Disallow: /admin без слеша закроет и /admin/users, и /admin-panel-secret. Не всегда то, что ты хотел.
Allow: /public/ — разрешает путь. Имеет смысл только когда у тебя выше широкое Disallow, а ты хочешь сделать исключение. Без Disallow директива Allow бессмысленная — всё и так разрешено по умолчанию.
Sitemap: https://example.com/sitemap.xml — путь до sitemap. Можно несколько строк, если sitemap'ов несколько. Указывается полный URL, не относительный.
Wildcards: * — любая последовательность символов, $ — конец строки.
Disallow: /*.pdf$
Disallow: /*?session=
Первая строка закроет все PDF-файлы. Вторая — все URL с параметром session в query string.
URL pathы регистрозависимые. /Admin/ и /admin/ — это два разных пути. Если у тебя на сайте такое разделение есть, надо закрывать оба.
Комментарии — через #. Используй их обильно, чтобы через полгода понимать, что и зачем ты тут написал.
Что обычно блокировать
Не всё подряд. Только то, что не должно засорять индекс или потреблять crawl budget впустую.
/admin/, /wp-admin/, /login/, /dashboard/ — внутренние страницы для администраторов и зарегистрированных пользователей. Google там делать нечего, эти страницы либо требуют авторизации, либо вообще для тебя одного.
/cart/, /checkout/, /account/, /order/ — приватные страницы e-commerce. Корзина у каждого пользователя своя, личный кабинет тоже. Индексировать их — плодить дубли и сливать crawl budget.
/search/ — страницы внутреннего поиска по сайту. Каждый поисковый запрос пользователя — это новый URL вида /search?q=.... Если их не закрыть, Google найдёт миллион таких URL через ссылки и попытается все проиндексировать. На выходе — тысячи thin-content страниц, которые потянут вниз весь сайт.
/api/ — JSON-endpointы, REST API. Это не страницы, это данные. Краулер их не должен видеть как контент.
?session=, ?utm_source=, ?ref= — URL с tracking-параметрами. Создают дубли одной и той же страницы. Лучшее решение — canonical, но если canonical настроить сложно, можно частично прикрыть через robots.txt. Только аккуратно: если закрыть ?utm_*, ты заблокируешь и страницы с реальным контентом по этим URL.
/staging/, /preview/, /test/, /dev/ — отдельные окружения. Часто это поддомены (staging.site.com), и тогда у них свой robots.txt, и это правильнее. Но если staging висит на основном домене в подпапке — закрывай.
Старые временные landing'и. Запустил рекламную кампанию, сделал /black-friday-2024/, она отжила своё — заблокируй, пока не удалишь.
Файлы с дублирующимся контентом. PDF-версия страницы, RSS-фид с полными текстами, print-версии — если они дублируют основной контент, держи их вне индекса.
Что НЕ блокировать
Это та часть, где люди стреляют себе в ногу чаще всего.
CSS и JavaScript. С 2014 года Google рендерит страницу как браузер — он загружает HTML, потом подтягивает CSS и JS, выполняет скрипты и смотрит на финальный результат. Если ты заблокируешь /wp-content/themes/ или /static/js/ — Google увидит сайт без стилей и без JS-логики. Mobile-friendly тест провалится. Layout сломается. Контент, который рендерится через JS, не попадёт в индекс. Никогда не закрывай статику.
/sitemap.xml сам по себе. Я видел случай, когда человек добавил Disallow: /sitemap.xml, потому что «не хочу, чтобы конкуренты видели мою структуру». Sitemap — это то, что Google специально читает, чтобы знать, что у тебя есть. Закрыв sitemap, ты сам себе ампутировал индексацию.
Картинки, если хочешь, чтобы они индексировались в Google Images. Закрытие /images/ или /uploads/ — частая ошибка после переезда с конструктора. На картинки идёт отдельный трафик через Google Images, и блокировка убивает этот канал.
PDF и файлы с уникальным контентом. Если у тебя есть PDF-документация, отчёты, технические whitepapers — они могут ранжироваться сами по себе и приводить трафик. Закрывать их в robots.txt — терять видимость.
Страницы с noindex в meta. Это контринтуитивная штука. Если ты хочешь убрать страницу из индекса через noindex meta-тег, Google должен зайти на страницу, прочитать HTML и увидеть этот тег. Если ты дополнительно закроешь её в robots.txt — Googlebot туда не пойдёт, noindex не увидит, и страница может остаться в индексе по внешним ссылкам. Логика обратная: для удаления страницы через noindex нужно её ОТКРЫТЬ в robots.txt.
JSON-LD и structured data, которые лежат отдельными файлами. Если schema.org разметка вынесена в /schema/, эту папку оставь открытой.
robots.txt vs noindex vs canonical
Три разных инструмента. Их часто путают, и из этого рождаются самые красивые баги в SEO.
robots.txt Disallow — это «не ходи». Краулер не зайдёт на страницу. Не значит, что страницы нет в индексе: если на неё ведут внешние ссылки, Google знает о её существовании и может показать её в выдаче. С пометкой «No information is available for this page» или вообще с заголовком из anchor-текста внешних ссылок. Disallow экономит crawl budget, но не гарантирует deindex.
<meta name="robots" content="noindex"> — это «ходи, читай, не индексируй». Googlebot заходит на страницу, видит meta-тег, и страница выпадает из индекса. Это единственный надёжный способ убрать страницу из выдачи. Главное условие: страница должна быть ДОСТУПНА для краулера. Если она закрыта в robots.txt, Google не зайдёт, не увидит noindex, и страница продолжит висеть в выдаче по внешним ссылкам.
<link rel="canonical" href="..."> — это «индексируй вон ту версию вместо меня». Используется, когда у тебя несколько URL с одним и тем же контентом, и ты хочешь сказать Google, какой считать основным. Дубли через параметры, версии для печати, AMP-страницы — всё это решается через canonical, не через robots.txt. См. когда нужен canonical URL.
Связка для типовых задач:
— Хочешь убрать страницу из индекса навсегда: открой её в robots.txt + поставь noindex meta + жди две-четыре недели, пока Google перепросканит и выкинет.
— Хочешь сэкономить crawl budget на ненужных страницах: закрой в robots.txt. Они могут остаться в индексе, но Google перестанет их обходить.
— Хочешь склеить дубли: canonical. Не robots.txt.
— Хочешь полностью убрать страницу: 410 Gone в HTTP-статусе + удалить из sitemap. robots.txt тут только мешает.
Самая частая ошибка: «я закрыл страницу через robots.txt И поставил noindex для надёжности». Это не «для надёжности», это конфликт. Google не сможет прочитать noindex и страница застрянет в индексе.
Как проверить
Самое простое — открыть в браузере или curl'ом:
curl https://site.com/robots.txt
Сразу видно, что отдаёт сервер. Если 404 — у тебя нет robots.txt, что само по себе не катастрофа, но лучше его всё-таки создать.
В Google Search Console есть robots.txt Tester (он переехал, теперь в разделе Settings → Crawling). Туда можно вставить URL и спросить: разрешён ли он для Googlebot. Полезно, когда правила сложные с wildcard'ами.
URL Inspection tool в GSC показывает по конкретному URL, заблокирован ли он, и каким правилом. Идеально для диагностики «почему эта страница не индексируется».
screaming-frog или аналоги при кроле сайта сразу подсветят, что заблокировано в robots.txt. Если перед деплоем гоняешь Frog — увидишь проблему до того, как она попадёт в продакшен.
После каждого изменения robots.txt обязательно перепроверь руками URL ключевых страниц. И через GSC отправь обновлённый robots.txt — Google его перечитает не сразу, обычно в течение суток.
Итог
robots.txt — пять строк текста, которые могут стоить тебе годового органического трафика. Это не место для экспериментов и не место для «сделаю как у соседа».
Базовое правило: закрывай только то, что действительно не должно быть в индексе. Не из паранойи, не «на всякий случай». Каждая директива должна иметь причину, и эта причина должна быть записана в комментарии.
Перед каждым деплоем — открой robots.txt и прочитай его глазами. Это пять строк. Это занимает десять секунд. Это спасает от месяцев восстановления позиций.
И помни: robots.txt блокирует обход, не индексацию. Для индексации есть noindex. Для дублей — canonical. Не путай инструменты. См. также 30+ факторов SEO и hreflang: subdomain vs subdirectory — там тоже много мест, где одной строкой можно положить всю работу за полгода.