robots.txt выглядит обманчиво просто — пять строк, три-четыре директивы. Из-за этой простоты к нему относятся небрежно: правят раз в год, не проверяют, доверяют генерации из CMS. А зря. Это один из самых опасных файлов на сайте: одна неправильная строка способна за неделю выкинуть весь домен из индекса Google и Яндекса. В этой статье разберём восемь конкретных ошибок, которые мы регулярно ловим в продакшен-сайтах через наш бесплатный валидатор robots.txt — и как каждую найти за минуту.
1. Disallow: / оставленный со stage
Классика. На stage-сервере вы поставили Disallow: /, чтобы Google случайно не проиндексировал тестовый домен. Через месяц этот же файл скопировался на продакшен (через git, через ручное копирование, через ошибку деплоя). Сайт месяц работает, но Google не видит ни одной страницы. Симптом: трафик стабилен, потом за неделю обнуляется. В GSC появляется warning «Indexed, though blocked by robots.txt». Проверка: откройте /tools/robots-txt-validator, введите ваш domain.com/robots.txt — если первая директива Disallow: /, у вас уже горит лампочка. Решение: убрать Disallow: / и заменить на конкретные служебные пути.
2. Регистрозависимые пути
Пути в robots.txt чувствительны к регистру. Если вы написали Disallow: /Admin, это не закроет /admin, /ADMIN, /aDmIn. Поисковик различает большие и маленькие буквы. Проверка: возьмите URL, который хотите проверить, и протестируйте обе версии в валидаторе. Решение: дублируйте директивы для всех вариантов написания, либо привяжите сервер к единому регистру через 301 редирект на нижний регистр.
3. Allow и Disallow для одного пути
Конфликтующие правила — частая беда. Например: Allow: /products/ + Disallow: /products. Что побеждает? У Google — Allow (более длинный или более специфичный матч), у Яндекса — тоже Allow, но логика немного отличается. Проблема: в разных поисковиках поведение может расходиться, что усложняет диагностику. Наш валидатор показывает оба исхода — что увидит Googlebot и что Yandexbot — в одной таблице. Решение: писать правила однозначно, не полагаться на «приоритет более длинного матча».
4. Закрытие CSS и JS от индексации
Старая привычка — Disallow: /assets/, Disallow: /static/. Идея была в том, что «эти файлы не нужны Google». Но Google использует CSS и JS, чтобы понять, как страница отображается на самом деле — для оценки мобильности, Core Web Vitals, для понимания каркаса DOM. Если вы блокируете CSS, Google видит «голый» HTML и считает страницу плохо свёрстанной. Решение: открыть доступ ко всем статическим ресурсам, оставить блокировку только для административных и пользовательских разделов (/admin, /account, /cart).
5. Неправильный User-agent
Иногда пишут User-agent: GoogleBot или User-agent: yandex (с маленькой буквы). Правильно: User-agent: Googlebot (одно слово, заглавная G), User-agent: Yandex (заглавная Y). Регистр в имени бота тоже важен. Если ошибка — правила игнорируются ботом, и применяется default-блок User-agent: *. Проверка: в нашем валидаторе мы прогоняем тест для каждого популярного бота отдельно — Googlebot, Yandexbot, Bingbot — и показываем, какие правила к каждому применились.
6. Отсутствие ссылки на Sitemap
Не критично, но полезно. Директива Sitemap: https://domain.com/sitemap.xml в robots.txt — это явный способ сказать поисковику, где искать вашу карту сайта. Без неё придётся вручную прописывать в Search Console и Webmaster. С ней — автоматом. Проверьте, что у вас она есть и указывает на актуальный sitemap. Дополнительно: если sitemap-индекс, и у вас несколько дочерних — указывайте именно индекс, а не каждый отдельно.
7. Crawl-delay для Googlebot
Директива Crawl-delay существует, но Google её игнорирует. Если вы написали Crawl-delay: 10 для User-agent: Googlebot, эффект нулевой. Управление частотой обхода Google делается через GSC → Settings → Crawl rate. Яндекс Crawl-delay уважает, но в большинстве случаев лучше управлять через Webmaster. Решение: не полагайтесь на Crawl-delay для Google, используйте его только для Яндекса и второстепенных ботов.
8. robots.txt по HTTPS отличается от HTTP
Если у вас сайт работает и по http, и по https (что само по себе плохо, но бывает в переходный период), robots.txt для каждого протокола применяется отдельно. На http.domain.com/robots.txt должен быть свой файл, на https.domain.com/robots.txt — свой. Часто бывает: добавили правильные правила в https-версию, а http-версия продолжает отдавать старый файл с Disallow: /. Решение: всегда серверная конфигурация должна редиректить http на https, а robots.txt отдавать одинаковый. Проверка через валидатор обеих версий явно покажет расхождение.
Как автоматизировать слежку за robots.txt
Бесплатный валидатор — это разовая проверка. Но robots.txt меняется чаще, чем кажется: новый деплой, новый плагин CMS, ручное вмешательство. В Site Metrics Tool после подключения проекта мы проверяем robots.txt раз в сутки и сравниваем с предыдущей версией. Если файл изменился — приходит алерт на email. Если появились ошибки — алерт срочный. Это превращает «один раз настроили и забыли» в «всегда под контролем». Особенно полезно для команд, где сайтом занимаются 3–5 человек, и кто-то может незаметно перетянуть директиву из staging.
Частые вопросы
Может ли robots.txt полностью удалить сайт из индекса?
Не сразу, но за 2–4 недели — да. Robots.txt блокирует только обход, не индексацию. Однако без обхода Google и Яндекс не могут обновлять данные о страницах, и постепенно выкидывают их из индекса как «не подтверждённые». Чтобы реально удалить страницу — используйте meta robots noindex или X-Robots-Tag заголовок.
Как часто проверять robots.txt?
После каждого деплоя, который мог его задеть (миграция, обновление CMS, ручная правка). Плюс автоматическая проверка раз в сутки через Site Metrics Tool. Минимум — раз в месяц вручную.
Что важнее — robots.txt или meta noindex?
Для исключения страницы из индекса — meta noindex или X-Robots-Tag. Для управления частотой и приоритетом обхода — robots.txt. Это разные инструменты с разными задачами.