На WordPress robots.txt часто правят «на глаз»: закрывают всё подряд, а потом удивляются, почему в индексе остаются служебные URL или, наоборот, выпадают нужные страницы. На практике задача обычно проще: спрятать от роботов страницы поиска, служебные каталоги, внутренние результаты фильтров, XML-RPC, staging-окружение и не сломать при этом обход сайта.
Ниже разберём, какие URL действительно стоит закрывать, как это сделать без плагинного хаоса, чем отличается Disallow от noindex, и как проверить, что правила работают.
Когда robots.txt нужен, а когда он не решает проблему
robots.txt управляет обходом, а не индексацией как таковой. Это важная разница: если страница уже известна поисковику, запрет в robots.txt не гарантирует её исчезновение из выдачи. Для таких URL обычно нужен noindex или редирект, а не только запрет обхода.
Типичные служебные страницы, которые можно закрывать
/wp-admin/— административная часть сайта./wp-login.php— страница входа./search/или внутренний поиск, если он создаёт мусорные URL.- Технические каталоги плагинов и тем, если они доступны публично и не нужны в индексе.
- Staging-домен или тестовая копия сайта.
А вот архивы, категории, теги и страницы пагинации закрывать без анализа не стоит. Иногда именно они дают поисковый трафик и помогают структуре сайта.
Диагностика: что именно индексируется лишнего
Перед правкой robots.txt проверьте, какие URL уже попали в индекс и откуда они берутся. Если закрыть не тот каталог, можно случайно заблокировать ресурсы темы или плагина, которые нужны для рендеринга страницы.
Минимальный чек-лист перед изменениями:
- Откройте
/robots.txtв браузере и посмотрите текущие правила. - Проверьте страницы в Google Search Console или Яндекс Вебмастере, если сайт уже добавлен.
- Посмотрите, нет ли в индексе URL вида
?s=,/page/2/,/feed/,/author/,/wp-json/. - Убедитесь, что служебные страницы не закрыты через
noindexв мета-тегах, если robots.txt уже блокирует обход.
Рабочий вариант: свой robots.txt через WordPress
Если нужен предсказуемый результат, лучше генерировать robots.txt через хук robots_txt. Так вы не зависите от ручного файла в корне, который легко забыть обновить после миграции.
<?php
add_filter('robots_txt', function ($output, $public) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /wp-login.php',
'Disallow: /search/',
'Disallow: /*?s=',
'Disallow: /feed/',
'Disallow: /comments/feed/',
'Disallow: /xmlrpc.php',
);
return implode("\n", $lines) . "\n";
}, 10, 2);Этот вариант подходит, если вы хотите централизованно управлять правилами из темы или небольшого mu-plugin. Но не забывайте: если у вас уже есть физический файл robots.txt в корне сайта, он может иметь приоритет в зависимости от конфигурации сервера и хостинга. После правки проверьте, какой именно файл отдаётся по адресу /robots.txt.
Если нужен отдельный staging
Для тестовой копии лучше не полагаться только на robots.txt. Надёжнее закрыть сайт на уровне HTTP-аутентификации, IP-ограничения или хотя бы выставить noindex и запретить доступ к админке. robots.txt здесь — дополнительный слой, а не защита.
Сравнение подходов: файл, код или плагин
| Подход | Когда удобен | Минус |
|---|---|---|
Физический robots.txt | Простой сайт, редкие правки | Легко забыть обновить после переноса |
Фильтр robots_txt | Нужна версия в коде и контроль в Git | Требует аккуратности при деплое |
| SEO-плагин | Нужны настройки без кода | Можно случайно задать конфликтующие правила |
Если на сайте уже используется SEO-плагин, проверьте, не генерирует ли он robots.txt сам. Дублирующиеся правила часто становятся причиной путаницы: в браузере виден один набор директив, а плагин в админке показывает другой.
Пошаговая настройка без лишнего риска
- Сделайте резервную копию текущего robots.txt или сохраните правила в Git.
- Определите только те URL, которые действительно не должны обходиться роботами.
- Добавьте правила через файл или фильтр
robots_txt. - Не закрывайте CSS, JS и изображения, если они нужны для отрисовки страниц.
- Проверьте, что на публичных страницах нет случайного
Disallowдля важных каталогов. - Отправьте обновлённый robots.txt на переобход в инструментах для вебмастеров.
Проверка результата после внедрения
После публикации изменений не ограничивайтесь просмотром файла в браузере. Нужно проверить, как поисковый робот видит сайт и не заблокированы ли важные ресурсы.
- Откройте
https://example.com/robots.txtи убедитесь, что там именно актуальные правила. - Проверьте в Search Console инструмент проверки robots.txt или тест URL, если он доступен.
- Запустите обход главной и нескольких внутренних страниц через инспекцию URL и посмотрите, нет ли блокировки ресурсов.
- С помощью
curlпроверьте ответ сервера:
curl -I https://example.com/robots.txtЕсли сайт отдаёт не 200 OK, а редирект или ошибку, поисковики могут читать файл нестабильно. Это уже не проблема директив, а проблема доставки файла.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — запретить /wp-content/ целиком. Внутри этого каталога лежат темы, плагины, изображения и скрипты. Если заблокировать всё, поисковик может хуже рендерить страницы, а часть контента станет недоступной для анализа.
Путают Disallow и noindex
Disallow запрещает обход, но не гарантирует удаление URL из индекса. Если страница уже попала в поиск, используйте noindex на самой странице или отдавайте корректный редирект/404, если контент больше не нужен.
Оставляют конфликтующие правила
Например, в плагине задано одно, а в корневом файле — другое. В итоге диагностика показывает разные версии robots.txt. Решение простое: оставьте один источник правды и документируйте, где именно он находится.
Блокируют служебные ресурсы темы
Иногда закрывают папки с CSS или JS, а потом получают проблемы с мобильной версией, Core Web Vitals и визуальным рендерингом. Если сомневаетесь, сначала проверьте страницу в режиме «Просмотреть как Google» или через инструменты тестирования URL.
Практические советы по безопасности и производительности
robots.txt не защищает сайт от атак. Если цель — спрятать админку или XML-RPC, не рассчитывайте только на директивы для роботов. Для безопасности важнее ограничение доступа, сложные пароли, 2FA и минимизация публичных точек входа.
Для производительности полезно не закрывать ресурсы, которые нужны браузеру и поисковику для рендеринга. Иначе можно получить ложную картину в тестах скорости и проблемы с индексацией CSS/JS. Если на сайте много дублей, параметров и служебных страниц, имеет смысл дополнительно проверить настройки SEO-плагина и чистку дублей, например в Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Если после правки robots.txt служебные URL всё равно лезут в индекс, не пытайтесь «додавить» это ещё большим количеством Disallow. Сначала выясните источник URL: внутренний поиск, фильтры, архивы автора, фиды или старые ссылки с внешних сайтов. В WordPress это обычно решается точечной настройкой, а не тотальной блокировкой.