Если в отчётах Search Console всплывают служебные URL, а в индексе живут страницы поиска, архивы и технические разделы, первым делом стоит проверить robots.txt. В WordPress этот файл часто либо отсутствует, либо содержит случайный набор правил, который не решает задачу. Ниже — рабочий сценарий: что именно закрывать, как не переборщить и чем проверить, что всё сработало.
Какие страницы обычно стоит закрывать в WordPress
Речь не про «запретить всё подряд», а про технические URL, которые не несут самостоятельной ценности для поиска. Обычно это:
- внутренний поиск сайта, например
?s=; - страницы пагинации служебных архивов, если они не нужны в выдаче;
- авторские архивы на сайтах с одним автором;
- теги и таксономии, которые дублируют рубрики;
- служебные каталоги плагинов и системные пути, если они вообще доступны извне.
Важно: robots.txt не удаляет URL из индекса сам по себе. Он только ограничивает обход. Если страница уже проиндексирована, одной директивы может быть мало — тогда нужен ещё noindex или корректная каноникализация.
Диагностика: что именно у вас лишнее
Перед правкой файла откройте отчёты в Search Console и посмотрите, какие URL реально создают шум. Полезно проверить три вещи:
- Есть ли в индексе страницы поиска вида
/ ?s=или/search/. - Появляются ли архивы автора, тегов, дат, вложений.
- Не закрыт ли случайно CSS, JS или изображения, без которых страница рендерится неправильно.
Если сайт использует SEO-плагин, сначала проверьте его настройки. Иногда нужные ограничения уже можно задать без ручного редактирования robots.txt. Но если нужен точный контроль, удобнее держать файл в репозитории темы или в отдельном MU-плагине, а не править его через админку «на глаз».
Пошаговая настройка robots.txt
1. Начните с безопасного базового файла
Для большинства сайтов достаточно минимального набора. Он не ломает доступ к стилям и скриптам и закрывает только то, что обычно не нужно в выдаче:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /author/
Disallow: /tag/
Disallow: /feed/
Этот вариант не универсален. Например, если у вас теги — важная часть структуры, закрывать /tag/ не надо. То же самое с /author/: на многопользовательском сайте архивы авторов могут быть полезны.
2. Не закрывайте ресурсы, нужные для рендеринга
Распространённая ошибка — добавить в Disallow целые каталоги темы или плагинов. В результате поисковый робот не видит CSS и JS, а страницы могут выглядеть «сломано» при рендеринге. Если у вас есть отдельные служебные пути, закрывайте именно их, а не весь /wp-content/.
3. Если нужен точечный контроль, используйте фильтр WordPress
Когда файл должен генерироваться автоматически, удобнее подключить фильтр robots_txt. Это особенно полезно, если правила зависят от окружения или типа сайта.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array();
$lines[] = 'User-agent: *';
$lines[] = 'Disallow: /wp-admin/';
$lines[] = 'Allow: /wp-admin/admin-ajax.php';
$lines[] = 'Disallow: /?s=';
$lines[] = 'Disallow: /search/';
return implode( "\n", $lines ) . "\n";
}, 10, 2 );
Такой подход удобен, если вы хотите хранить правила в коде темы или в небольшом MU-плагине. Но не забывайте: если SEO-плагин тоже управляет robots.txt, проверьте, не перетирает ли он ваш вывод.
Сравнение подходов: плагин, код или ручной файл
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Нужно быстро закрыть базовые служебные URL без разработки | Меньше гибкости, правила могут быть спрятаны в интерфейсе |
Ручной robots.txt | Небольшой сайт, понятный набор директив | Легко забыть обновить файл после изменений структуры |
Фильтр robots_txt | Нужна генерация правил из кода и контроль через Git | Требует аккуратной поддержки и тестирования |
Как проверить, что настройка сработала
После правки не ограничивайтесь открытием файла в браузере. Проверьте результат по шагам:
- Откройте
/robots.txtи убедитесь, что файл отдается без редиректов и ошибок. - Проверьте, что в нём нет лишних
Disallowдля CSS, JS и изображений. - В Search Console используйте проверку URL для страниц, которые должны быть закрыты.
- Посмотрите логи обхода, если они доступны: робот не должен массово ходить по закрытым служебным страницам.
Если вы закрыли только обход, но URL всё ещё в индексе, это ожидаемо. Тогда добавьте на саму страницу noindex или уберите её из внутренней перелинковки, чтобы робот перестал считать её важной.
Частые ошибки и как их исправить
Закрыли слишком много
Если после правки упала видимость или страницы стали плохо рендериться, первым делом проверьте, не заблокированы ли стили и скрипты. Уберите широкие правила вроде Disallow: /wp-content/ и замените их точечными исключениями.
Ожидали удаления из индекса только через robots.txt
Это частое недоразумение. robots.txt не удаляет уже известные поисковику страницы. Для удаления нужен noindex, редирект, 404/410 или снятие ссылки с сайта.
Конфликт с SEO-плагином
Если вы редактируете файл вручную, а плагин генерирует свой вариант, итоговый файл может отличаться от ожидаемого. Проверьте, где именно формируется robots.txt, и оставьте только один источник правды.
Закрыли архивы, которые нужны для навигации
На контентных проектах теги и авторы иногда помогают пользователю и поиску. Перед закрытием оцените, есть ли у них реальный трафик и внутренняя ценность. Если есть — лучше доработать шаблон архива, чем прятать его от робота.
Безопасность и производительность: что учесть
Сам robots.txt не защищает сайт от атак и не ускоряет его напрямую. Но грамотная настройка снижает бесполезный обход и помогает поисковику тратить краулинговый бюджет на важные страницы. Для крупных сайтов это уже практическая польза.
Если вы ведёте сайт на WordPress и регулярно чистите технический мусор, удобно держать SEO-настройки в одном месте. Например, в Clearfy Pro есть инструменты для удаления дублей и технической чистки сайта: https://wpshop.ru/plugins/clearfy. Это не заменяет понимание правил, но помогает не расползаться настройкам по разным плагинам.
Практический чек-лист перед публикацией
- Проверить, какие URL реально мусорят в индексе.
- Убедиться, что
robots.txtне закрывает CSS и JS. - Не блокировать важные архивы без причины.
- Согласовать правила с SEO-плагином, если он установлен.
- Проверить файл в браузере и через Search Console.
- Для уже проиндексированных страниц добавить
noindexили убрать их из внутренней перелинковки.
Если держать robots.txt как часть технической архитектуры, а не как случайный список запретов, он перестаёт быть источником проблем и начинает работать как нормальный фильтр для робота. В WordPress это особенно заметно на сайтах с большим количеством архивов, поисковых страниц и служебных URL.