Самая частая причина внезапного выпадения сайта из индекса — директива Disallow: / в корне robots.txt, которая по ошибке закрывает от роботов всё дерево адресов вместо одного технического раздела. Такие сбои проще поймать до публикации, если проверять файл по конкретному алгоритму, а не просматривать его «на глаз» раз в полгода.
Как одна строка в robots.txt блокирует весь сайт
Robots.txt — это не команда на удаление страниц из индекса, а инструкция для поисковых роботов: куда заходить можно, а куда нет. Если директива Disallow закрывает корень сайта («/»), робот прекращает обходить внутренние страницы при каждом визите. Индекс обновляется не сразу: сначала падает частота обхода, затем страницы начинают выпадать из результатов поиска, потому что поисковая система не может подтвердить их актуальность.
Опасность в том, что ошибка в robots.txt редко бросается в глаза. Сайт продолжает открываться в браузере как обычно, формы работают, каталог кликается — единственный сигнал проблемы приходит через отчёты поисковых систем о сканировании или через постепенное снижение трафика.
Disallow: / остаётся после переноса с тестового сервера
Самый частый сценарий — robots.txt с тестового или staging-окружения копируют на продакшен вместе с остальными файлами и забывают заменить. На тестовом сервере строка Disallow: / нужна, чтобы черновую версию не нашли и не проиндексировали; на живом сайте та же строка закрывает всё.
Представим условный интернет-магазин обувь-пример.ru. Команда разработки выкладывает обновлённый каталог на боевой домен и переносит файлы с тестового сервера целиком, включая robots.txt. Через две недели трафик из поиска заметно падает, а в панели вебмастера появляется массовое сообщение о том, что страницы не могут быть просканированы из-за robots.txt. Проверка файла показывает одну строку: Disallow: /. Правка занимает минуту, но на восстановление позиций и повторное сканирование каталога уходит несколько недель.
Неточный User-agent и опечатки в директивах
Вторая по частоте ошибка — директива написана с опечаткой или относится не к тому роботу. Правило User-agent: * действует для всех роботов, но если вместо него указать конкретного робота с ошибкой в названии, остальные продолжат читать правила по умолчанию, а нужный — проигнорирует блок целиком. Похожая путаница возникает, когда после User-agent оставляют пустую строку без Disallow или Allow: часть парсеров воспринимает такой блок как «не трогать», а часть — как «закрыть всё».
Лишние пробелы в начале строки, слэш в конце адреса, который не совпадает с реальным путём, кириллические символы вместо латиницы в названии директивы — такие мелочи ломают логику файла незаметно для человека, но robots.txt читает их построчно и буквально.
Блокировка CSS, JS и изображений мешает рендерингу
Раньше правило «закрыть все технические файлы» было обычной практикой, чтобы не тратить лимит сканирования на статику. Сейчас поисковые системы рендерят страницу почти как браузер, и если стили и скрипты закрыты в robots.txt, робот видит её без оформления и части интерфейса. Это особенно критично для сайтов на JavaScript-фреймворках, где без выполнения скриптов контент вообще не появляется в структуре страницы.
Проверить это легко: достаточно открыть инструмент проверки рендеринга страницы в панели вебмастера и сравнить результат со стандартным отображением в браузере. Если блоки меню, карточек или текста отсутствуют — вероятная причина в закрытых технических каталогах вроде /css/ или /static/.
Ошибки в указании Sitemap и относительных путях
Директива Sitemap в robots.txt должна содержать полный адрес файла с протоколом и доменом, а не относительный путь. Если указать просто /sitemap.xml без полного адреса сайта, часть роботов не сможет найти файл, особенно при наличии нескольких поддоменов или зеркал. Ту же ошибку допускают, когда в Sitemap указывают карту старого домена после переезда или объединения разделов — робот продолжает ходить по неактуальному списку адресов.
Как проверить robots.txt за 10 минут
Ниже — таблица самых частых ошибок, по которым стоит пройтись перед каждой публикацией изменений в файле.
| Ошибка | Как обнаружить | Что сделать |
|---|---|---|
| Disallow: / в корне | Массовые ошибки сканирования в панели вебмастера, резкое падение трафика | Убрать строку или заменить на точечный запрет конкретных разделов |
| Опечатка в названии User-agent | Правило игнорируется нужным роботом или применяется ко всем | Сверить название робота с документацией поисковой системы |
| Закрыты /css/, /js/, /static/ | При проверке рендеринга страница отображается без оформления | Разрешить доступ к файлам, нужным для корректного отображения |
| Sitemap указан относительным путём | Файл карты сайта не находится при проверке в панели вебмастера | Указать полный адрес с протоколом и доменом |
| Лишние пробелы и слэши в строках | Правило срабатывает не на той папке, что задумано | Построчно перечитать файл в редакторе без автоформатирования |
Что делать, если ошибку нашли после индексации
Если ошибка обнаружена постфактум, исправление самого файла — это только первый шаг. Сначала нужно убрать некорректную директиву и опубликовать исправленную версию robots.txt по стандартному адресу в корне домена. Затем стоит отправить файл на повторную проверку через инструменты поисковых систем для вебмастеров — это ускоряет повторное сканирование по сравнению с ожиданием естественного обхода.
После этого важно отслеживать отчёты о сканировании несколько циклов подряд: число ошибок должно снижаться постепенно, а не исчезать мгновенно — у поисковых роботов есть собственный график обхода, который не перезапускается по команде. Полезно держать резервную копию последней рабочей версии robots.txt отдельно от общего репозитория сайта, с датой изменения: если после очередного релиза трафик падает без видимой причины, сравнение текущего файла с рабочей копией занимает меньше минуты.
Частые вопросы
Можно ли закрыть в robots.txt страницу с личными данными пользователей?
Нет. Robots.txt только просит роботов не заходить на раздел, но не ограничивает к нему доступ технически — страница может быть открыта по прямой ссылке или просто стать доступной любому, кто узнает адрес. Для защиты закрытых разделов нужны серверные ограничения доступа, а не правило в файле robots.txt.
Как часто нужно перепроверять robots.txt, если в него давно не вносили изменений?
Проверка нужна не по расписанию, а при любом техническом событии: смене хостинга, переносе файлов с тестового сервера, обновлении CMS или подключении нового поддомена. Именно в такие моменты строка Disallow чаще всего переносится туда, где её не должно быть.
Чтобы убедиться, что сайт сейчас не заблокирован случайно, откройте адрес сайта с приписанным /robots.txt в браузере, построчно сверьте каждую директиву Disallow с реальной структурой разделов и проверьте, что Sitemap указан полным адресом — этого достаточно, чтобы отсеять большинство ошибок без специальных инструментов.
