Как настроить robots.txt в WordPress для закрытия лишних служебных URL

Автор: Виктория Игнатьева | Опубликовано: 21.09.2026

Если в отчётах поисковиков всплывают служебные URL, это не всегда проблема с контентом. Часто сайт сам отдаёт в обход индексации страницы поиска, вложения, служебные параметры, фиды, внутренние endpoint’ы и другие адреса, которые не нужны в выдаче. В WordPress это обычно решают через robots.txt, но здесь легко переборщить: закрыть не то, сломать обход сайта или просто не получить ожидаемого эффекта.

Ниже — рабочий сценарий: что именно имеет смысл закрывать, как это сделать без лишнего риска и как проверить, что поисковый бот видит именно то, что вы задумали.

Какие URL обычно создают лишний шум

Сначала полезно понять, что вы закрываете не «мусор вообще», а конкретные типы адресов. В WordPress чаще всего в зону риска попадают:

внутренний поиск вида ?s=;
страницы вложений медиафайлов, если они индексируются отдельно;
служебные фиды /feed/ и фиды комментариев;
адреса с параметрами сортировки, фильтров и пагинации, если они создают дубли;
служебные endpoint’ы плагинов, которые не должны попадать в поиск.

Важно: robots.txt не удаляет URL из индекса сам по себе. Он только ограничивает обход. Если страница уже в индексе, одного запрета в robots может быть мало. Для таких случаев обычно дополнительно используют noindex, canonical или редирект — в зависимости от сценария.

Диагностика: что именно закрывать, а что оставить

Перед правкой файла проверьте, какие URL реально создаются на сайте. Это можно сделать без сложных инструментов:

откройте поиск по сайту и посмотрите, какие адреса формируются;
проверьте страницы вложений в медиабиблиотеке;
посмотрите, есть ли у записей отдельные фиды комментариев;
загляните в логи аналитики или Search Console на предмет странных параметров в URL;
проверьте, не закрывает ли текущий robots важные разделы по ошибке.

Если сайт уже использует SEO-плагин, сначала посмотрите, не генерирует ли он robots автоматически. Иногда ручная правка файла в корне сайта конфликтует с настройками плагина, и вы получаете не тот результат, который видите в редакторе.

Что не стоит закрывать в robots.txt

Не пытайтесь через robots закрыть то, что должно быть доступно для обхода и индексации: основные записи, рубрики, страницы, изображения, CSS и JS. Особенно осторожно относитесь к блокировке ресурсов темы и плагинов — если поисковик не сможет загрузить стили и скрипты, он может хуже оценить страницу.

Пошаговая настройка robots.txt в WordPress

В WordPress файл robots.txt может быть виртуальным, то есть генерироваться системой, а не лежать физически в корне сайта. Это нормально. Но если у вас есть реальный файл в корне, именно он обычно имеет приоритет.

Базовый вариант для закрытия типовых служебных URL может выглядеть так:

User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /trackback/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Этот пример не универсален. Он показывает принцип: закрываем только то, что действительно не нужно в поиске или не должно обходиться ботом. Если на сайте используется другой формат поиска, например /page/2/?s= или отдельный URL поиска от темы, правила нужно подстроить под фактическую структуру.

Как добавить свой robots.txt без ручной правки файла

Если вы хотите управлять содержимым robots из темы или мини-плагина, используйте фильтр robots_txt. Это удобнее, чем править файл через FTP, если сайт на хостинге с ограниченным доступом.

<?php
add_filter( 'robots_txt', function( $output, $public ) {
    $lines = array(
        'User-agent: *',
        'Disallow: /?s=',
        'Disallow: /search/',
        'Disallow: /feed/',
        'Disallow: /comments/feed/',
        'Disallow: /trackback/',
        'Disallow: /wp-admin/',
        'Allow: /wp-admin/admin-ajax.php',
    );

    return implode( "\n", $lines ) . "\n";
}, 10, 2 );

Такой подход полезен, если вы ведёте проект через Git и хотите, чтобы правило было в коде, а не в админке. Но если на сайте уже есть SEO-плагин, сначала проверьте, не перезаписывает ли он robots своим шаблоном.

Сравнение подходов: плагин, код или ручной файл

Подход	Когда подходит	Плюсы	Минусы
Ручной `robots.txt`	Небольшой сайт, есть доступ к корню	Просто и прозрачно	Легко ошибиться, нужен доступ к файлам
Фильтр `robots_txt`	Нужна версия в коде	Удобно для деплоя и контроля изменений	Требует правки темы или плагина
SEO-плагин	Нужно управлять без кода	Проще для редактора или контент-менеджера	Не всегда гибко, возможны конфликты настроек

Если у вас уже стоит плагин для технической чистки сайта, например Clearfy Pro, проверьте, не решает ли он часть задачи штатно. Но даже в этом случае логику закрытия лучше понимать самостоятельно: плагин не отменяет необходимость проверить фактический результат.

Проверка результата после внедрения

После правки не ограничивайтесь тем, что файл «выглядит правильно». Проверка должна быть практической.

Откройте /robots.txt в браузере и убедитесь, что правила отдаются именно в том виде, который вы задали.
Проверьте, не дублируется ли содержимое из плагина и из физического файла.
Попробуйте открыть закрываемые URL вручную и посмотрите, не остались ли они доступными для обхода.
В Search Console проверьте, не растёт ли количество обнаруженных служебных URL.
Если страница уже была в индексе, оцените, нужен ли для неё noindex или редирект вместо одного robots-запрета.

Полезный тест: если вы закрыли внутренний поиск, попробуйте найти в индексе URL вида ?s=. Если они уже были проиндексированы, robots может не убрать их мгновенно. В таком случае лучше дополнительно ограничить генерацию таких страниц на уровне темы или SEO-настроек.

Частые ошибки и как их исправить

Закрыли CSS и JS вместе с системными URL

Иногда в robots по привычке блокируют слишком широкие пути, а потом поисковик не может корректно отрисовать страницу. Если после правки упала видимость или появились проблемы с рендерингом, проверьте, не закрыты ли папки темы, плагинов, /wp-includes/ и статические ресурсы.

Ожидали, что robots удалит URL из индекса

Это частая ошибка. Robots ограничивает обход, но не гарантирует удаление уже известного адреса. Для удаления из индекса нужен другой механизм: noindex, canonical, редирект или удаление страницы с корректным кодом ответа.

Правили не тот robots.txt

Если на сервере есть физический файл, а в WordPress включён виртуальный robots, легко смотреть не на тот источник. Всегда проверяйте итоговый ответ сервера по адресу /robots.txt, а не только файл в панели хостинга.

Закрыли важные разделы по шаблону

Правило вроде Disallow: / встречается реже, чем кажется, но последствия у него очевидны: бот перестаёт обходить сайт целиком. Если после правки резко просела индексация, первым делом сравните текущую версию robots с резервной копией.

Практические советы по безопасности и производительности

С точки зрения безопасности robots.txt не скрывает чувствительные данные. Если URL не должен быть доступен, его нужно защищать на уровне прав доступа, авторизации или серверной конфигурации. Robots — это не механизм защиты, а лишь подсказка для ботов.

С точки зрения производительности полезно не плодить служебные URL на уровне темы и плагинов. Чем меньше мусорных адресов генерируется, тем меньше работы у поисковых систем и тем чище отчёты. Если внутренний поиск создаёт много бесполезных страниц, иногда лучше ограничить его индексацию через noindex и доработать шаблон результатов поиска, чем бесконечно расширять robots.

Если вы ведёте несколько сайтов, держите шаблон robots в репозитории и меняйте его осознанно. Это проще, чем потом искать, почему на одном проекте закрыт /feed/, а на другом — нет.

Когда robots.txt не подходит

Есть сценарии, где robots.txt — не лучший инструмент. Например, если нужно убрать из индекса уже опубликованные страницы фильтров, архивов или поиска, а сами URL должны оставаться доступными для пользователей. В таких случаях обычно работают через noindex на уровне шаблона или через настройки SEO-плагина. Если же URL вообще не должен существовать, лучше решать задачу редиректом или удалением маршрута, а не запретом обхода.

Именно поэтому хорошая настройка robots.txt в WordPress начинается не с копирования готового шаблона, а с понимания, какие адреса у вас реально появляются и что вы хотите с ними сделать: закрыть от обхода, убрать из индекса или вообще не генерировать.