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

Автор: Сергей Фомин | Опубликовано: 24.09.2026

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

Когда robots.txt действительно помогает

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

Что имеет смысл закрывать

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

Что не стоит закрывать без проверки

/wp-admin/ — это нормально, но не трогайте /wp-admin/admin-ajax.php, если он нужен теме или плагинам;
/wp-content/uploads/ — закрывать весь каталог обычно плохая идея, если изображения должны индексироваться;
CSS и JS-файлы — поисковик должен видеть ресурсы для рендеринга страницы;
URL, которые уже закрыты через noindex и используются для навигации внутри сайта.

Диагностика: какие URL реально создают мусор

Перед правкой robots.txt проверьте, какие адреса вообще существуют и как они выглядят. Часто проблема не в самом robots.txt, а в том, что сайт генерирует слишком много вариантов одной и той же страницы.

Откройте в браузере и через Search Console такие типы URL:

/search/?s=тест или /?s=тест;
/feed/ у рубрик, записей и комментариев;
/attachment/ или страницы вложений медиафайлов;
URL с параметрами ?orderby=, ?filter=, ?amp, если они есть на сайте;
архивы тегов, если они пустые или почти пустые.

Если страница открывается и отдает код 200, но не нужна для поиска, сначала решите: закрывать обходом через robots.txt или убирать из индекса через noindex. Для страниц с контентом, который должен быть доступен пользователю, но не нужен в поиске, noindex обычно надежнее.

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

В WordPress robots.txt можно настраивать двумя способами: через физический файл в корне сайта или через генерацию плагином. Если у вас уже есть SEO-плагин, сначала проверьте, не управляет ли он robots.txt сам. Два источника правды здесь создают путаницу.

Шаг 1. Посмотреть текущий robots.txt

Откройте https://ваш-домен.ru/robots.txt и посмотрите, что там уже есть. На живых сайтах часто встречаются старые правила, которые остались после миграции или установки плагина. Если файл отдается виртуально, а не лежит физически в корне, его может генерировать WordPress или SEO-расширение.

Шаг 2. Добавить только нужные директивы

Ниже — аккуратный базовый вариант для типичного сайта на WordPress. Он не закрывает лишнего и не ломает индексацию ресурсов.

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

Sitemap: https://example.com/sitemap_index.xml

Здесь есть важная оговорка: правило Disallow: /?s= работает не во всех случаях одинаково, потому что поисковый запрос может формироваться по-разному. Если у вас поиск открывается как /search/, закрывайте именно этот путь. Если сайт использует нестандартный поиск, проверьте фактический URL.

Шаг 3. Не блокировать ресурсы темы и плагинов

Если в robots.txt уже есть строки вроде Disallow: /wp-content/ или запрет на /wp-includes/, это повод остановиться и проверить сайт в Search Console. Такие правила часто мешают рендерингу страниц и ухудшают понимание контента поисковиком. Закрывать стоит не весь каталог, а только конкретные служебные разделы, если они реально доступны и создают мусор.

Шаг 4. Сохранить sitemap отдельно

Карта сайта должна оставаться доступной. Если вы используете XML-карту от SEO-плагина, укажите ее в robots.txt отдельной строкой Sitemap:. Это не обязательно, но помогает роботам быстрее находить актуальные URL.

Если нужен более точный контроль: robots.txt, noindex или canonical

Не все проблемы решаются robots.txt. Иногда он вообще не подходит. Ниже короткое сравнение подходов.

Подход	Что делает	Когда использовать	Ограничение
robots.txt	Запрещает обход	Для служебных URL и мусорных разделов	Не удаляет уже проиндексированные страницы
noindex	Просит не индексировать страницу	Для страниц, которые должны открываться пользователю, но не нужны в поиске	Страница должна быть доступна для обхода
canonical	Указывает основную версию	Для дублей и параметров сортировки	Не всегда срабатывает, если страница сильно отличается по содержанию

Практически это выглядит так: robots.txt закрывает то, что не должно сканироваться; noindex убирает из индекса страницы, которые все же должны открываться; canonical объединяет дубли в одну основную версию. Если смешать эти инструменты без логики, можно получить ситуацию, когда робот не видит страницу, но она все равно висит в индексе как «URL без описания».

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

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

Откройте /robots.txt и убедитесь, что файл отдается без редиректов и ошибок.
Проверьте в Search Console инструмент проверки robots.txt или тестирование URL, если он доступен в вашем аккаунте.
Посмотрите, не исчезли ли из обхода CSS, JS и изображения, которые нужны для рендеринга.
Проверьте несколько закрытых URL вручную: они должны быть недоступны для обхода, но при этом сайт не должен ломаться.
Сравните отчеты по сканированию через 1-2 обхода робота, а не сразу после правки.

Если вы закрыли внутренний поиск, а в индексе он все еще есть, это нормально: robots.txt не удаляет URL мгновенно. В таком случае лучше дополнительно поставить noindex на шаблон страницы поиска или настроить вывод 404/410 для ненужных вариантов, если это соответствует логике сайта.

Пример правки через код, если файл генерируется WordPress

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

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

    $lines[] = 'Sitemap: ' . home_url('/sitemap_index.xml');

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

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

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

Ниже ошибки, которые встречаются чаще всего на реальных проектах.

Закрыли весь `/wp-content/`

Это ломает доступ к изображениям, стилям и скриптам. Исправление простое: уберите общий запрет и оставьте только точечные правила для ненужных каталогов, если они действительно есть.

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

Не удалит. Если страница уже в поиске, используйте noindex, canonical или настройку ответа сервера. Robots.txt нужен для обхода, а не для деиндексации.

Закрыли `admin-ajax.php`

После этого могут перестать работать фильтры, формы, динамические элементы и часть функциональности темы. Если не уверены, оставьте Allow: /wp-admin/admin-ajax.php.

Добавили правила, но файл не изменился

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

Закрыли страницы, которые нужны для внутренней перелинковки

Если раздел полезен пользователю и должен участвовать в навигации, но не нужен в индексе, лучше использовать noindex, follow, а не полный запрет обхода. Иначе робот может хуже понимать структуру сайта.

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

robots.txt не защищает сайт от атак. Это не firewall и не способ скрыть админку. Но он помогает уменьшить лишний обход и снизить шум в логах, если у вас много мусорных запросов от роботов.

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

Если вам нужен более широкий технический аудит дублей, индексации и служебных страниц, удобнее сначала собрать все правила в одном месте, а потом уже править robots.txt, canonical и noindex по очереди. На практике это проще сопровождать, чем пытаться «починить SEO» одной директивой.

Мини-чек-лист перед публикацией изменений

Проверен текущий robots.txt в браузере.
Понятно, какие URL закрываются и зачем.
Не заблокированы CSS, JS и изображения.
Сохранена строка с sitemap.
Проверены страницы поиска, feed и вложений.
Убедились, что robots.txt не дублируется в плагине и в файле одновременно.
После правки сделана повторная проверка в Search Console.

Если на сайте уже стоит SEO-плагин и вы не хотите собирать правила вручную, имеет смысл использовать его только как инструмент управления, а не как замену понимания логики индексации. Для проектов, где важны чистка дублей и техническое SEO, это обычно экономит больше времени, чем точечные правки «на глаз».