Robots.txt управляет обходом, а не гарантированным удалением страниц из поиска. Неверная директива способна закрыть роботу CSS, JavaScript, каталог товаров или весь сайт. Поэтому файл нужно проектировать от задач индексации, проверять на тестовой среде и контролировать после каждого изменения структуры.
Поймите границы robots.txt
Используйте файл для управления обходом повторяющихся и технических URL: служебных фильтров, внутренних результатов поиска, временных каталогов. Конфиденциальные данные защищайте авторизацией, а не Disallow.
Запрещённый URL всё равно может появиться в поиске без описания, если на него ведут внешние ссылки. Робот просто не сможет прочитать страницу и увидеть noindex.
Как проверить: Откройте файл по адресу /robots.txt и проверьте, что он доступен без авторизации с кодом 200 и типом text/plain.
Частая ошибка: Публиковать в комментариях секретные пути или считать Disallow механизмом информационной безопасности.
Разделяйте группы User-agent
Начните с User-agent: * для общих правил. Отдельные группы создавайте только при реальной необходимости, когда конкретному роботу нужны отличающиеся директивы.
Избыточные группы усложняют поддержку и создают расхождения между поисковыми системами. Правило должно быть коротким, предсказуемым и документированным.
Как проверить: Проверьте один и тот же URL в инструментах Яндекса и Google для соответствующих роботов.
Частая ошибка: Дублировать десятки одинаковых правил по группам и забывать обновить одну из них при изменении структуры.
Работайте с путями точно
Disallow сопоставляется с путём URL. Используйте конкретные префиксы и тестируйте граничные случаи. Не закрывайте общий фрагмент, если он встречается в полезных адресах.
Одна слишком широкая строка способна исключить из обхода каталог или ресурсы интерфейса. Чем короче шаблон, тем шире потенциальное действие.
Как проверить: Составьте таблицу минимум из десяти разрешённых и запрещённых URL и проверьте каждый через анализатор robots.txt.
Частая ошибка: Использовать Disallow: / без проверки на боевом домене или переносить файл с тестового стенда, где весь сайт был закрыт.
Не блокируйте ресурсы рендеринга
Разрешите роботу получать CSS, JavaScript и изображения, необходимые для отображения основного контента. Закрывайте только действительно служебные сборки и приватные области.
Поисковая система оценивает мобильную страницу после рендеринга. Без стилей и сценариев она может неверно понять структуру, скрытый контент или удобство интерфейса.
Как проверить: Используйте проверку URL с рендерингом и сравните скриншот робота с реальной страницей.
Частая ошибка: Закрывать целиком /assets/, /css/ или /js/ ради экономии краулингового бюджета.
Различайте Disallow и noindex
Если страницу нужно убрать из индекса, робот должен иметь возможность открыть её и увидеть meta robots noindex или заголовок X-Robots-Tag. После удаления URL возвращайте 404/410 либо перенаправляйте на полноценный аналог.
Одновременный Disallow и noindex часто конфликтуют: запрет обхода мешает прочитать запрет индексирования.
Как проверить: Проверьте выбранный способ в исходном HTML и инструменте проверки URL, затем отслеживайте исключение в отчёте.
Частая ошибка: Закрывать страницу в robots.txt сразу после добавления noindex и ожидать мгновенного удаления из поиска.
Добавьте адрес Sitemap
В конце файла укажите абсолютный URL карты сайта. Строка Sitemap не относится к конкретной группе User-agent и может повторяться для нескольких карт.
Так робот обнаружит актуальный перечень канонических страниц даже без ручной отправки в панели.
Как проверить: Перейдите по адресу из директивы и убедитесь, что карта отвечает 200, валидна и относится к тому же сайту.
Частая ошибка: Оставлять ссылку на тестовый домен или старую карту после миграции.
Учтите параметры и фильтры
Для интернет-магазина сначала определите, какие комбинации фильтров имеют поисковый спрос и уникальное содержание. Полезные посадочные оставьте доступными, бесконечные технические комбинации ограничьте системно.
Грубое закрытие всех параметров может скрыть нужные категории, а полная открытость создаёт миллионы дублей и расходует ресурсы обхода.
Как проверить: Проанализируйте логи и отчёты по параметрическим URL, затем проверьте canonical, внутренние ссылки и правила формирования адресов.
Частая ошибка: Копировать универсальный robots.txt из другого магазина с иной структурой фильтров.
Проверяйте перед публикацией
Храните robots.txt в системе версий и добавьте автоматическую проверку, которая не позволит развернуть Disallow: / на основном домене. Изменения согласовывайте с SEO-специалистом и разработчиком.
Файл маленький, но зона риска огромна. Процесс проверки важнее количества директив.
Как проверить: Сравните старую и новую версии, прогоните список критических URL и сохраните результат проверки в задаче релиза.
Частая ошибка: Редактировать файл напрямую на сервере без истории, ревью и возможности быстро откатить изменение.
Следите за эффектом
После обновления контролируйте статистику обхода, ошибки загрузки и число доступных страниц. Изменения интерпретируйте с учётом задержки повторного обхода.
Роботу нужно время, чтобы перечитать файл и посетить URL. Резкие изменения в логах помогут понять, сработало ли правило ожидаемым образом.
Как проверить: Сравните группы URL до и после изменения, а не только общий размер индекса.
Частая ошибка: Делать новые правки каждый день, не дождавшись измеримого результата предыдущего изменения.
Безопасный регламент изменения robots.txt
Перед правкой выгрузите текущий файл и список критичных URL: главная, услуги, категории, карточки, статьи, CSS и JavaScript. Для каждого адреса запишите ожидаемый результат — разрешён или запрещён. Новую версию сначала прогоните через анализаторы поисковых систем, затем проведите ручную проверку. Такой набор становится приёмочным тестом и используется при каждом следующем релизе.
На боевом сервере полезен автоматический предохранитель: сборка должна останавливаться, если для основного домена появляется Disallow: /. Это защищает от распространённой ошибки переноса настроек тестового стенда. Сам файл хранят в репозитории вместе с комментарием к задаче, чтобы было видно, почему появилась каждая директива и когда её можно удалить.
После публикации не ограничивайтесь визуальной проверкой. Убедитесь, что сервер отдаёт 200 без перенаправления и правильный текст для всех узлов инфраструктуры. Через несколько дней сравните логи обхода и отчёты вебмастеров. Если полезный раздел перестал посещаться, откатите изменение и разберите конкретное правило, а не добавляйте новые исключения поверх ошибочной конфигурации.
Итоговый чек-лист
- Файл доступен по /robots.txt с кодом 200
- Нет случайного Disallow: /
- CSS и JavaScript для рендеринга открыты
- Noindex не заблокирован от обхода
- Sitemap указан абсолютным URL
- Параметры и фильтры проверены на реальных адресах
- Изменения проходят ревью и автоматический тест
- После релиза контролируются логи и индексирование
Частые вопросы
Можно ли закрыть сайт паролем через robots.txt?
Нет. Robots.txt публичен и носит рекомендательный характер для добросовестных роботов. Приватную область защищают серверной авторизацией и правами доступа.
Нужно ли добавлять Host?
Следуйте актуальной документации конкретной поисковой системы. Главный адрес надёжнее закреплять редиректами, canonical, внутренними ссылками и единообразным Sitemap, а не полагаться на одну директиву.
Почему закрытая страница осталась в выдаче?
Поисковик мог знать URL по ссылкам, но не иметь права прочитать содержимое. Разрешите обход и отдайте noindex, либо удалите страницу корректным HTTP-кодом, если она больше не существует.
Материал подготовлен как практическая инструкция. Перед массовыми изменениями сделайте резервную копию, протестируйте правила на выборке URL и сохраните исходные настройки для отката.