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

Автор: Роман Фомин | Опубликовано: 29.08.2026

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

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

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

Не каждый «мусорный» URL нужно закрывать через robots.txt. Этот файл управляет обходом, а не удалением из индекса. Если страница уже попала в поиск, одного запрета может быть мало: робот перестанет её обходить, но URL может ещё какое-то время жить в выдаче без сниппета.

Типичные признаки

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

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

Что закрывать в WordPress, а что не трогать

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

Что делать	Подход	Компромисс
`/wp-admin/`	Закрыть от обхода	Не мешать входу в админку, но не блокировать `admin-ajax.php` без необходимости
`/wp-includes/`	Обычно закрыть	Проверить, не завязаны ли на него публичные ассеты темы или плагинов
служебные файлы	Закрыть точечно	Не использовать слишком широкие маски
CSS/JS темы и плагинов	Не закрывать	Иначе можно сломать рендеринг и ухудшить оценку страницы

Диагностика перед правкой robots.txt

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

Что проверить вручную

Откройте https://ваш-домен/robots.txt.
Посмотрите, нет ли там старых правил от плагина, хостинга или предыдущего разработчика.
Проверьте, не закрыты ли случайно wp-content, uploads или пути к CSS/JS.
Убедитесь, что в файле нет конфликтующих директив для разных user-agent.

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

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

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /cgi-bin/
Disallow: /trackback/
Disallow: /xmlrpc.php

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

Что здесь важно:

Disallow: /wp-admin/ закрывает административный раздел от обхода;
Allow: /wp-admin/admin-ajax.php оставляет доступ к AJAX-обработчику, который часто нужен фронтенду;
Disallow: /xmlrpc.php уместен, если XML-RPC не используется для внешних сервисов;
Sitemap помогает быстрее передать поисковику карту сайта.

Если нужно закрыть ещё и системные директории

Иногда добавляют /wp-includes/ и отдельные служебные пути. Делать это стоит только после проверки, что тема и плагины не отдают оттуда публичные файлы, которые должны сканироваться.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /cgi-bin/
Disallow: /trackback/
Disallow: /xmlrpc.php
Sitemap: https://example.com/sitemap_index.xml

Если сайт использует нестандартную сборку, CDN или выносит статические файлы в отдельный путь, перед добавлением Disallow проверьте, не лежат ли там CSS, JS, шрифты или изображения, нужные для рендеринга.

Как сделать robots.txt через код в WordPress

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

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

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

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

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

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

Мини-чек-лист

откройте /robots.txt и убедитесь, что правила отдаются без ошибок;
проверьте, что Sitemap указывает на актуальную карту сайта;
посмотрите, не закрыт ли случайно путь к CSS/JS;
в Search Console проверьте отчёт по страницам и статус обхода;
переобойдите несколько URL, которые раньше были проблемными.

Для быстрой технической проверки удобно использовать curl:

curl -I https://example.com/robots.txt
curl https://example.com/robots.txt

Если сервер отдаёт не 200 OK, а редирект или ошибку, это уже отдельная проблема: поисковик может не увидеть правила или будет интерпретировать их некорректно.

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

Закрыли слишком много

Самая частая ошибка — запретить целиком /wp-content/ или /wp-includes/, а потом обнаружить, что поисковик не может нормально отрисовать страницу. В результате падает качество обхода и могут просесть сигналы рендеринга.

Что делать: убрать широкий запрет и проверить, не блокируются ли критичные ресурсы. Если нужно закрыть только часть путей, делайте это точечно.

Путают robots.txt и noindex

robots.txt не гарантирует удаление URL из индекса. Если страница уже известна поисковику, для удаления или деиндексации нужен другой механизм: noindex, редирект, каноникал или удаление страницы с сервера.

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

Оставили старый физический robots.txt

После переноса сайта или установки SEO-плагина на сервере может остаться старый файл. Он перекрывает виртуальную генерацию WordPress и создаёт ощущение, что настройки не работают.

Что делать: проверить корень сайта по FTP/SSH и удалить конфликтующий файл или привести его к актуальному виду.

Закрыли XML-RPC без понимания последствий

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

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

Безопасность и производительность: что реально даёт robots.txt

robots.txt не защищает сайт от атак и не скрывает файлы от прямого доступа. Это только инструкция для поисковых роботов. Поэтому не стоит воспринимать его как инструмент безопасности.

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

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

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

Когда лучше не править robots.txt вручную

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

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

⭐⭐⭐⭐⭐