Если в индексе всплывают служебные URL, а в отчётах поисковых систем появляются страницы поиска, архивы тегов, параметры сортировки или внутренние служебные разделы, первым делом обычно смотрят на robots.txt. Но здесь легко сделать хуже: закрыть не то, перекрыть доступ к CSS и JS или ожидать от robots.txt того, чего он не умеет. Этот файл не удаляет страницы из индекса сам по себе, а только задаёт правила обхода.
Ниже — рабочий сценарий для WordPress: что именно имеет смысл закрывать, как это сделать без лишнего риска и как проверить, что настройка действительно сработала.
Какие страницы WordPress обычно стоит закрывать
В типичном сайте WordPress есть несколько групп URL, которые не нужны в поиске или не должны тратить краулинговый бюджет. Речь не о том, чтобы закрыть всё подряд, а о служебных и малоценных разделах, которые создаются автоматически.
- страницы внутреннего поиска вида
?s=; - архивы по датам, если они не несут самостоятельной ценности;
- служебные URL плагинов, если они не должны обходиться роботами;
- параметры сортировки и фильтров, если они плодят мусорные адреса;
- технические файлы и каталоги, которые не должны индексироваться.
При этом не стоит закрывать в robots.txt то, что должно оставаться доступным для рендера страницы: CSS, JS, изображения темы и критические ресурсы. Если поисковик не может нормально отрисовать страницу, это уже проблема не индексации, а качества обхода.
Диагностика: что именно мешает индексации
Перед правкой файла полезно понять, откуда берутся лишние URL. В WordPress это обычно один из четырёх сценариев: внутренний поиск, архивы таксономий, параметры в адресе или генерация служебных страниц плагином.
Проверьте, какие URL уже попали в индекс
Сначала смотрят на отчёты поисковой системы и на сам сайт. Если в выдаче есть страницы с ?s=, /page/ у внутренних архивов, адреса с параметрами ?orderby=, ?filter= или похожие варианты, значит проблема не в одном файле, а в общей логике генерации URL.
Полезно также открыть сайт в браузере и посмотреть, не создают ли плагины дополнительные пути. Часто это видно в хлебных крошках, фильтрах, поиске по сайту и пагинации.
Проверьте текущий robots.txt
На большинстве сайтов файл доступен по адресу /robots.txt. Если там уже есть правила от хостинга, SEO-плагина или старой настройки, не стоит просто дописывать новые строки вслепую. Сначала нужно понять, какие директивы уже работают и нет ли конфликтов.
Если используется SEO-плагин, он может генерировать robots.txt виртуально. В таком случае правка физического файла на сервере может не дать ожидаемого эффекта. Это частая причина, почему изменения «не применяются».
Пошаговая настройка robots.txt в WordPress
Самый безопасный подход — начать с минимального набора правил и добавлять только то, что действительно нужно. Для WordPress обычно достаточно закрыть внутренний поиск и служебные пути, а остальное решать отдельно через noindex или настройку самого плагина.
Базовый пример robots.txt
User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xmlЗдесь есть несколько важных моментов. /wp-admin/ закрывают почти всегда, но admin-ajax.php оставляют доступным, потому что его используют темы и плагины. Если у вас в теме или плагинах есть AJAX-функции, блокировка этого файла может сломать форму, фильтр или динамическую подгрузку.
Строка Disallow: /?s= помогает ограничить обход страниц внутреннего поиска. Но если сайт использует красивый URL поиска, например /search/term/, нужен отдельный путь. Универсального правила для всех сайтов нет.
Если нужен запрет для параметров фильтрации
Для URL с параметрами вроде сортировки и фильтров можно закрыть конкретные шаблоны. Здесь важно не переборщить: robots.txt работает по префиксам, а не по сложным условиям. Поэтому правило должно быть максимально точным.
User-agent: *
Disallow: /*?orderby=
Disallow: /*?filter=
Disallow: /*?sort=
Disallow: /*?add-to-cart=Такой вариант подходит только если вы уверены, что эти параметры не нужны в поиске и не используются для важных страниц. Если параметров много, лучше сначала посмотреть, какие из них реально создают мусорные URL, а какие участвуют в нормальной навигации.
Когда лучше не использовать robots.txt
Если задача — убрать страницу из индекса, а не просто запретить обход, одного robots.txt недостаточно. Страница может остаться в индексе как URL без контента, если на неё уже есть ссылки. В таких случаях нужен noindex через мета-тег или заголовок X-Robots-Tag, а не только запрет в robots.
Это особенно важно для архивов, страниц поиска и параметрических URL. Если закрыть их в robots, поисковик может не увидеть директиву noindex на самой странице, потому что не сможет её обойти.
Как задать robots.txt через код в WordPress
Если не хочется править файл вручную или нужно управлять правилами из темы/плагина, в WordPress есть фильтр robots_txt. Он позволяет добавить или изменить содержимое файла на лету.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$output .= "\nUser-agent: *\n";
$output .= "Disallow: /?s=\n";
$output .= "Disallow: /search/\n";
$output .= "Disallow: /wp-admin/\n";
$output .= "Allow: /wp-admin/admin-ajax.php\n";
return $output;
}, 10, 2 );Этот вариант удобен, если сайт развёрнут в нескольких окружениях и нужно централизованно управлять правилами. Но для продакшена лучше хранить такую логику в небольшом mu-plugin или в отдельном плагине, а не в файле темы. Тогда правило не исчезнет после обновления темы.
Сравнение подходов: файл, плагин или код
| Подход | Когда подходит | Минус |
|---|---|---|
Физический robots.txt | Простые правила, один сайт, ручное управление | Легко перезаписать при деплое или настройке плагина |
| SEO-плагин | Когда уже используется плагин для мета-тегов и sitemap | Нужно понимать, кто именно генерирует файл |
Фильтр robots_txt | Если правила должны быть в коде и под версионным контролем | Требует аккуратного размещения и тестирования |
Если на сайте уже стоит SEO-плагин, сначала проверьте его настройки. Иногда проще и безопаснее управлять robots.txt там, где уже генерируется sitemap и мета-robots. Если нужна более широкая чистка дублей и служебных URL, из практических инструментов часто используют Clearfy Pro, но только как часть общей настройки, а не вместо понимания логики индексации.
Как проверить, что решение сработало
После правки не ограничивайтесь открытием файла в браузере. Нужно проверить и сам robots.txt, и реакцию поисковика, и поведение сайта.
- откройте
/robots.txtи убедитесь, что правила отдаются без ошибок; - проверьте, не перезаписывает ли файл SEO-плагин;
- посмотрите, не сломались ли AJAX-формы и фильтры из-за запрета
admin-ajax.php; - в отчётах поисковой системы проверьте, уменьшается ли число обходов служебных URL;
- вручную откройте несколько закрытых адресов и убедитесь, что они не нужны для обычной навигации.
Если у вас есть доступ к логам сервера, полезно посмотреть, перестали ли роботы часто ходить на внутренний поиск и параметрические адреса. Это не мгновенный эффект, но по логам обычно видно, что мусорный обход снижается.
Частые ошибки и как их исправить
Закрыли слишком много
Самая неприятная ошибка — заблокировать CSS, JS, изображения или admin-ajax.php. В результате страница может начать рендериться неправильно, а динамические элементы перестанут работать. Если это уже произошло, верните доступ к критическим ресурсам и проверьте сайт в режиме инкогнито и в инструментах проверки рендеринга.
Ожидали удаления из индекса только от robots.txt
robots.txt не удаляет URL из индекса мгновенно и не всегда вообще удаляет его. Если страница уже известна поисковику, нужен noindex или удаление через инструменты вебмастера. Для страниц поиска и архивов это особенно важно.
Правили не тот файл
На сайтах с SEO-плагином виртуальный robots.txt может перекрывать физический файл. В таком случае изменения на сервере не видны. Проверьте настройки плагина, а затем уже редактируйте источник, который реально отдаёт файл.
Использовали слишком общие маски
Правило вроде Disallow: /*? может задеть больше, чем нужно. На некоторых сайтах через параметры работают полезные страницы, фильтры или даже канонические переходы. Лучше закрывать только конкретные шаблоны, которые вы уже увидели в логах или индекс-отчётах.
Практические советы по безопасности и производительности
Если сайт активно растёт, robots.txt стоит воспринимать как часть технической гигиены, а не как разовую правку. На больших сайтах полезно периодически пересматривать список закрытий: новые плагины, фильтры и архивы могут снова создавать мусорные URL.
Ещё один практический момент: не храните правила в нескольких местах одновременно. Если часть директив лежит в файле, часть — в плагине, а часть — в коде темы, через месяц почти невозможно понять, что именно отдаётся поисковику. Один источник правды здесь лучше трёх.
Если вы работаете с кастомной разработкой, держите изменения robots_txt в репозитории и тестируйте их на staging. Это особенно полезно, когда сайт обновляется часто и есть риск случайно закрыть важные разделы.
Для сайтов, где нужно не только закрыть технические страницы, но и подчистить дубли метатегов, архивы и служебные элементы, удобнее смотреть на комплексную настройку SEO и чистки сайта, а не на один файл. Но даже в этом случае robots.txt остаётся базовой точкой контроля, которую стоит проверять вручную после каждого изменения.