Если в индексе появились служебные URL, дубли архивов, страницы поиска или лишние параметры, robots.txt часто пытаются использовать как универсальный выключатель. Это рабочий инструмент, но только если понимать его границы: он управляет обходом, а не гарантирует удаление из индекса. Для WordPress это особенно важно, потому что часть технических страниц лучше закрывать через noindex, а не через Disallow.
Ниже — практический сценарий: какие разделы обычно закрывают, как собрать корректный robots.txt без поломки CSS/JS, и как проверить, что поисковые роботы видят именно то, что нужно.
Какие страницы WordPress обычно стоит закрыть
Не все технические URL одинаковы. Одни нужно просто не отдавать в обход, другие — оставить доступными для робота, но запретить индексацию через мета-тег или заголовок. Если закрыть слишком агрессивно, можно случайно спрятать полезные ресурсы темы, стили или изображения.
Что обычно попадает в список на закрытие
/wp-admin/— административная часть сайта;/wp-login.php— страница входа;- служебные результаты поиска по сайту, если они индексируются;
- архивы с пустым или дублирующимся содержимым;
- страницы с параметрами, которые создают мусорные URL;
- служебные фиды, если они не нужны для вашей модели распространения контента.
При этом /wp-content/uploads/, CSS и JS-файлы обычно не стоит закрывать без причины. Если роботу не удастся загрузить ресурсы, он может некорректно оценить страницу.
Диагностика: что именно мешает индексации
Перед правкой robots.txt проверьте, что именно вы хотите исправить. Иногда проблема не в обходе, а в неправильных canonical, дублях архивов или страницах, которые уже попали в индекс и продолжают там висеть.
- Откройте
/robots.txtсайта и посмотрите, нет ли там конфликтующих правил. - Проверьте, не закрыты ли случайно важные каталоги темы или плагинов.
- Посмотрите в Google Search Console, какие URL помечены как «Заблокировано robots.txt».
- Сравните это с реальными страницами, которые нужно убрать из индекса.
Если страница уже в индексе, а вы просто добавили Disallow, она может остаться там надолго. В таком случае часто нужен noindex на самой странице и только потом — ограничение обхода, если это уместно.
Пошаговая настройка robots.txt в WordPress
В WordPress robots.txt можно отдать двумя способами: через физический файл в корне сайта или через фильтр robots_txt. Для точечной настройки удобнее второй вариант, потому что он не требует ручного редактирования файла на сервере и меньше ломается при деплое.
Вариант 1: добавить правила через фильтр robots_txt
Этот способ подходит, если вы хотите управлять содержимым robots.txt из темы или небольшого MU-плагина. Пример ниже закрывает админку, логин, внутренний поиск и несколько служебных путей.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
if ( ! $public ) {
return $output;
}
$rules = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Disallow: /wp-login.php',
'Disallow: /?s=',
'Disallow: /search/',
'Disallow: /feed/',
'Allow: /wp-admin/admin-ajax.php',
);
return implode( "\n", $rules ) . "\n";
}, 10, 2 );
Здесь важно не закрыть admin-ajax.php, если тема или плагины используют его для фронтенд-скриптов, форм или динамических блоков.
Вариант 2: физический robots.txt в корне
Если у вас статичный деплой или сайт на отдельном хостинге без удобного доступа к PHP, можно создать файл вручную. Но тогда следите, чтобы его не перезаписывал CI/CD или панель хостинга.
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml
Строку Sitemap лучше указывать только если карта сайта реально доступна по этому адресу. Иначе вы создадите лишнюю ошибку для роботов и для себя.
Что лучше закрывать через noindex, а не через Disallow
Есть страницы, которые поисковик должен увидеть, чтобы понять, что их не нужно индексировать. Если вы полностью запретите обход, робот может не заметить мета-тег noindex или заголовок X-Robots-Tag.
| Сценарий | Лучший способ | Комментарий |
|---|---|---|
| Админка, логин | Disallow | Обычный служебный доступ, индексировать нечего |
| Внутренний поиск | noindex + при необходимости Disallow | Если страница уже в индексе, сначала уберите её корректно |
| Пагинация архивов | Зависит от структуры сайта | Не закрывайте вслепую, если страницы дают полезную навигацию |
| Фиды | Чаще Disallow или отключение | Если фиды не используются, их можно убрать из обхода |
Если вы используете плагин для SEO-управления, проверьте, не генерирует ли он собственные правила. Например, в Clearfy Pro есть инструменты для чистки технических хвостов и управления дублями, но перед включением любых опций всё равно стоит сверить итоговый robots.txt и мета-robots на страницах.
Проверка результата после внедрения
После правки не ограничивайтесь открытием файла в браузере. Нужно убедиться, что правила отдаются именно так, как вы ожидаете, и что важные ресурсы не оказались под запретом.
- Откройте
https://ваш-домен/robots.txtи проверьте содержимое; - проверьте, что
Sitemapуказывает на актуальный адрес; - в Search Console протестируйте URL, который должен быть закрыт;
- посмотрите, не исчезли ли из обхода CSS/JS, если сайт использует динамические блоки;
- проверьте, не остались ли в индексе старые URL, которые теперь должны быть удалены.
Если вы закрывали внутренний поиск или параметры, полезно вручную открыть несколько таких URL и убедиться, что они либо отдают noindex, либо больше не создаются в шаблонах и ссылках сайта.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — запретить обход целых каталогов темы, медиатеки или скриптов. В результате робот видит «пустую» страницу или не может нормально её отрендерить. Исправление простое: уберите лишний Disallow и проверьте, какие ресурсы нужны для отображения страницы.
Путают robots.txt и удаление из индекса
Disallow не гарантирует удаление URL из выдачи. Если страница уже проиндексирована, добавьте noindex на саму страницу или используйте инструменты удаления в Search Console, если это срочно.
Оставили конфликтующие правила
Иногда в robots.txt одновременно есть правила от темы, SEO-плагина и ручной правки. В итоге один блок перекрывает другой, а вы видите не тот результат, который ожидали. Решение — оставить один источник генерации файла.
Забыли про sitemap
Если карта сайта указана неверно, поисковик будет тратить время на несуществующий адрес. Проверьте, что sitemap открывается без редирект-цепочек и отдает актуальный XML.
Практические советы по безопасности и производительности
robots.txt не защищает сайт от атак. Если вы закрыли /wp-login.php в robots.txt, это не мешает брутфорсу. Для безопасности нужны лимиты попыток входа, двухфакторная аутентификация, нормальные пароли и, при необходимости, WAF.
С точки зрения производительности не стоит использовать robots.txt как способ «спрятать» тяжелые страницы. Если URL не должен существовать для пользователей, лучше убрать его из генерации, а не только закрыть для роботов.
Если сайт большой и технических дублей много, удобно сочетать robots.txt с нормализацией URL, canonical и чисткой лишних архивов. Это обычно дает более предсказуемый результат, чем попытка закрыть всё одним файлом.
Короткий чек-лист перед публикацией
- robots.txt открывается по прямому URL;
- не закрыты CSS, JS и критичные ресурсы;
Sitemapуказан правильно;- служебные страницы закрыты осознанно, а не «на всякий случай»;
- страницы, которые уже в индексе, дополнительно помечены
noindex, если это нужно; - в Search Console нет новых ошибок обхода после правки.
Если задача не ограничивается только robots.txt и нужно одновременно убрать дубли, почистить технические страницы и привести индексацию к нормальному виду, имеет смысл смотреть на комплексную настройку SEO-слоя сайта, а не на один файл в корне.