Если в индексе начинают всплывать служебные URL, результаты поиска по сайту, страницы с параметрами или внутренние технические разделы, первым делом обычно смотрят на robots.txt. Но это не кнопка «спрятать всё лишнее». Файл работает только как подсказка для роботов, и его легко настроить так, что часть мусора останется в индексе, а нужные страницы случайно выпадут из обхода.
Ниже разберём, какие задачи реально решает robots.txt в WordPress, что лучше закрывать через него, а что — через noindex, и как проверить, что после правок сайт не потерял важные страницы.
Когда robots.txt действительно нужен
В WordPress чаще всего закрывают не «весь мусор подряд», а конкретные технические зоны:
- страницы поиска по сайту вида
/?s=; - служебные каталоги плагинов и тем, если они доступны по URL;
- URL с параметрами фильтрации и сортировки;
- служебные endpoint’ы, которые не должны обходиться поисковыми роботами;
- внутренние архивы и дубли, если они генерируются шаблоном или плагином.
При этом robots.txt не убирает URL из индекса сам по себе. Если страница уже известна поисковику, одного запрета на обход может быть недостаточно. Для таких случаев нужен noindex на самой странице или корректный canonical.
Диагностика проблемы: что именно закрывать
Перед правкой файла полезно понять, откуда берётся индексируемый мусор. Откройте в поиске по сайту запросы вида site:example.com и посмотрите, какие URL всплывают. Если это страницы поиска, параметры или архивы с дублями, robots.txt может помочь сократить обход. Если это полноценные страницы с контентом, их лучше не закрывать через robots, а решить вопрос на уровне шаблона или мета-тега.
Проверьте ещё три вещи:
- есть ли у сайта уже свой
robots.txtв корне; - не генерирует ли SEO-плагин отдельные правила;
- не блокируются ли CSS и JS, нужные для рендеринга страниц.
Последний пункт важен: если случайно закрыть папки со стилями или скриптами, поисковик может хуже отрисовать страницу и неверно оценить её качество.
Что лучше закрывать через robots.txt, а что нет
| Подход | Когда использовать | Минус |
|---|---|---|
robots.txt | Для служебных URL, которые не нужно обходить | Не гарантирует удаление из индекса |
noindex | Для страниц, которые уже должны исчезнуть из поиска | Страница должна быть доступна роботу для обхода |
| canonical | Для дублей и параметров, если есть основная версия | Не всегда срабатывает мгновенно |
На практике эти инструменты часто используют вместе: robots.txt уменьшает лишний обход, noindex и canonical помогают убрать дубли из индекса.
Пошаговое решение: как настроить robots.txt в WordPress
Шаг 1. Откройте файл в корне сайта
Файл должен лежать в корне сайта и открываться по адресу https://site.ru/robots.txt. Если файла нет, WordPress и SEO-плагин могут отдавать виртуальную версию. Это нормально, но для сложных правил удобнее управлять файлом явно.
Шаг 2. Добавьте только нужные запреты
Ниже пример аккуратного варианта для типового WordPress-сайта. Он не закрывает важные ресурсы темы и плагинов, но убирает очевидные служебные зоны:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /search/
Disallow: /?s=
Disallow: /*?s=
Disallow: /*?replytocom=
Disallow: /*?orderby=
Disallow: /*?filter=
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важная оговорка: правила с параметрами работают не у всех роботов одинаково. Это не универсальная магия, а практическая попытка сократить обход типовых дублей. Если у вас другой SEO-плагин или другая структура URL, список нужно подстроить под реальный сайт.
Шаг 3. Не закрывайте лишнее
Частая ошибка — добавить в Disallow папки /wp-content/ или /wp-includes/ целиком. Так делать не стоит, если вы не понимаете последствия. Поисковику нужны доступные CSS и JS, а некоторые изображения и файлы темы тоже могут участвовать в рендеринге.
Если вы хотите закрыть только конкретный каталог, делайте это точечно и после проверки, что он не нужен для отображения страниц.
Если нужно закрыть страницы поиска и параметры без поломки SEO
Для страниц поиска по сайту и URL с параметрами лучше не ограничиваться robots.txt. Поисковик может сохранить такой адрес в индексе как «известный, но не просканированный». Чтобы убрать его корректнее, добавьте noindex на уровне шаблона или SEO-плагина.
Пример для WordPress: запретить индексацию страниц поиска через wp_robots:
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
return $robots;
} );Такой подход безопаснее, чем пытаться «спрятать» поиск только через robots.txt. Робот увидит страницу, поймёт директиву и не будет держать её в индексе как полноценную посадочную.
Как проверить, что решение сработало
После правок не ограничивайтесь открытием файла в браузере. Проверьте три уровня:
- Откройте
/robots.txtи убедитесь, что файл отдаётся без ошибки 404. - Проверьте, что sitemap указан корректно и ведёт на реальный файл.
- Посмотрите в инструментах для вебмастеров, как робот видит запреты и нет ли блокировки важных ресурсов.
Полезно также вручную проверить несколько URL:
/search/?s=тест;- страницу с параметром сортировки;
- служебный URL, который вы закрывали;
- основную страницу статьи или рубрики, чтобы убедиться, что она не попала под лишний запрет.
Если после обновления robots.txt важные страницы перестали обходиться, значит правило слишком широкое. В таком случае сначала уберите лишний Disallow, потом заново отправьте sitemap на переобход.
Частые ошибки и как их исправить
Закрыли весь сайт одной строкой
Иногда в файл случайно попадает Disallow: /. После этого робот не может обходить вообще ничего. Исправление простое: удалить строку и проверить, не осталось ли её в кеше SEO-плагина или CDN.
Используют robots.txt вместо noindex
Если URL уже в индексе, запрет на обход не всегда решает задачу. Для удаления из поиска нужен noindex или редирект на каноническую страницу, если дубль больше не нужен.
Блокируют CSS и JS
Это особенно часто случается после копирования чужого шаблона robots.txt. В результате страница может выглядеть нормально для пользователя, но хуже анализироваться поисковиком. Не закрывайте ресурсы темы без необходимости.
Оставляют несколько конфликтующих версий файла
Если SEO-плагин генерирует виртуальный robots.txt, а в корне лежит физический файл, поведение может отличаться от ожидаемого. Проверьте, какая версия реально отдаётся сервером.
Практические советы по безопасности и производительности
Не используйте robots.txt как средство защиты. Он не скрывает админку и не защищает от доступа к URL, а только подсказывает роботам, что обходить не нужно. Для безопасности важнее ограничить вход в /wp-admin/, включить нормальную авторизацию и не оставлять открытыми лишние служебные страницы.
С точки зрения производительности robots.txt полезен, когда на сайте много мусорных параметров, бесконечных страниц поиска или технических дублей. Но если проблема в генерации URL внутри темы или плагина, лучше исправить источник, а не только закрывать последствия.
Если на сайте уже накопилось много дублей, иногда удобнее сначала почистить технику на уровне шаблона и мета-тегов, а затем обновить правила обхода. В таких задачах полезны инструменты вроде Clearfy Pro, если нужен набор для чистки дублей и технической оптимизации, но сам принцип остаётся тем же: сначала понять источник, потом закрывать.
Мини-чек-лист перед публикацией изменений
- Файл
/robots.txtоткрывается без ошибки. - В нём нет
Disallow: /и других глобальных запретов. - Не закрыты CSS, JS и изображения темы.
- Для уже индексируемых дублей добавлен
noindexили canonical. - Sitemap указан и ведёт на актуальный адрес.
- Проверены URL с параметрами, поиск по сайту и служебные страницы.
Если после правок в индексе всё ещё остаются старые URL, это не всегда означает ошибку. Поисковику нужно время на переобход и переоценку страниц. Главное — не создавать новые проблемы слишком широкими запретами и не пытаться решить всё одним robots.txt.