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

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

Если в отчётах по сканированию всплывают /wp-admin/, /wp-content/uploads/, служебные файлы плагинов, параметры сортировки и прочие технические URL, первым делом обычно смотрят на robots.txt. Но именно здесь чаще всего делают лишнее: закрывают то, что не нужно, или, наоборот, случайно режут доступ к важным ресурсам для поисковых роботов.

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

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

robots.txt не удаляет страницы из индекса сам по себе. Он управляет обходом. Это важная разница: если URL уже попал в индекс, один только запрет в robots.txt не гарантирует его исчезновение. Для удаления из выдачи нужны другие механизмы: noindex, каноникал, редирект или 404/410 в зависимости от сценария.

В WordPress robots.txt полезен, когда нужно:

сократить обход служебных разделов;
не тратить crawl budget на мусорные URL с параметрами;
закрыть от обхода внутренние каталоги плагинов и тем, если они не должны сканироваться;
не пускать роботов в административную часть сайта;
убрать из обхода дубли, которые генерируются технически, но не должны участвовать в поиске.

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

Не нужно бездумно закрывать /wp-content/ целиком. Внутри него лежат изображения, CSS и JS, которые часто нужны поисковым системам для рендеринга страницы. Если закрыть всё подряд, можно получить проблемы с обработкой страниц в поиске и с диагностикой в инструментах вебмастера.

Также осторожно относитесь к запрету /wp-includes/. В старых советах это встречается часто, но на практике такой запрет может мешать роботам видеть ресурсы, которые участвуют в отображении сайта.

Диагностика: что именно у вас индексируется или обходится лишний раз

Перед правкой robots.txt полезно понять источник мусора. Иначе легко лечить не ту проблему. Проверьте:

отчёт по страницам в Google Search Console или Яндекс Вебмастере;
логи сервера, если есть доступ к ним;
результаты поиска по site:вашдомен с подозрительными URL;
список URL, которые генерируют плагины фильтрации, поиска, сортировки, пагинации и календарей;
наличие дублей с параметрами вроде ?replytocom=, ?utm_, ?orderby=, ?s=.

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

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

У WordPress есть базовый виртуальный robots.txt, который можно переопределить двумя способами: через файл в корне сайта или через фильтр robots_txt. Для рабочих сайтов чаще удобнее файл, потому что он прозрачен и не зависит от темы или плагина.

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

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

Шаг 2. Сформировать минимально безопасный набор правил

Для типового WordPress-сайта стартовая конфигурация может быть такой:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /*?replytocom=
Disallow: /*?orderby=
Disallow: /*?filter=
Sitemap: https://example.com/sitemap_index.xml

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

Шаг 3. Добавить только те правила, которые реально нужны

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?replytocom=
Disallow: /*?sort=
Disallow: /*?filter_=
Disallow: /*?page_id=
Sitemap: https://example.com/sitemap_index.xml

Не копируйте этот блок без проверки. Если у вас ?page_id= используется в рабочих ссылках, такое правило навредит. В robots.txt нет универсального списка для всех сайтов.

Настройка через код, если robots.txt генерируется из темы или плагина

Иногда файл в корне недоступен или его перезаписывает плагин. Тогда можно использовать фильтр robots_txt. Это рабочий вариант, если вы контролируете тему или делаете небольшую mu-plugin-надстройку.

<?php
add_filter('robots_txt', function ($output, $public) {
    $lines = [];
    $lines[] = 'User-agent: *';
    $lines[] = 'Disallow: /wp-admin/';
    $lines[] = 'Allow: /wp-admin/admin-ajax.php';
    $lines[] = 'Disallow: /wp-login.php';
    $lines[] = 'Disallow: /*?replytocom=';
    $lines[] = 'Sitemap: ' . home_url('/sitemap_index.xml');

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

Такой подход удобен, когда нужно централизованно управлять правилами, но у него есть минус: при смене темы или отключении кода robots может измениться. Для критичных проектов лучше хранить правила в отдельном небольшом плагине или mu-plugin.

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

Подход	Плюсы	Минусы	Когда выбирать
Файл `/robots.txt`	Прозрачно, просто проверить, не зависит от темы	Нужен доступ к корню сайта	Почти всегда, если есть доступ по FTP/SSH
Фильтр `robots_txt`	Можно управлять из кода	Зависит от темы/плагина	Когда файл недоступен или нужна генерация на лету
SEO-плагин	Удобно для редактора, часто есть интерфейс	Легко перегрузить правилами	Если сайт ведётся без разработчика и нужен простой контроль

Если используете SEO-плагин, проверьте, не создаёт ли он свой robots.txt поверх вашего файла. В таком случае редактировать нужно только один источник, иначе правила будут расходиться.

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

После правки не ограничивайтесь открытием файла в браузере. Проверьте несколько вещей:

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

Если нужно проверить быстро, используйте ручной тест: откройте URL из sitemap, затем URL с параметром и сравните, что именно закрыто. Для более точной диагностики смотрите логи робота в аналитике сервера или отчёты вебмастера.

Что должно насторожить после правки

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

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

Ошибка 1. Путают запрет обхода и запрет индексации. Если URL уже в индексе, robots.txt сам по себе не уберёт его. Решение: noindex, canonical, редирект или удаление страницы в зависимости от задачи.

Ошибка 2. Закрывают весь /wp-content/. Это ломает доступ к статике. Решение: не трогать папку целиком, если нет точной причины.

Ошибка 3. Добавляют правила для параметров без проверки. На сайте могут быть рабочие ссылки с теми же параметрами. Решение: сначала найти все шаблоны URL, потом закрывать только лишнее.

Ошибка 4. Дублируют правила в нескольких местах. Файл, SEO-плагин и код начинают спорить друг с другом. Решение: оставить один источник правды.

Ошибка 5. Ожидают мгновенного исчезновения страниц из выдачи. Роботы могут учитывать изменения не сразу. Решение: после правки отправить на переобход только действительно важные URL и следить за отчётами вебмастера.

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

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

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

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

Мини-чек-лист перед публикацией robots.txt

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

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