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

Если в отчётах по сканированию всплывают URL вроде /wp-admin/, /wp-login.php, /wp-json/, страницы с параметрами поиска или служебные endpoints плагинов, обычно проблема не в «плохом robots.txt», а в том, что сайт отдаёт слишком много технических адресов в обходе. Закрывать всё подряд нельзя: часть URL должна оставаться доступной для индексации или работы фронтенда. Поэтому задача здесь не «запретить WordPress целиком», а аккуратно отсечь системные пути, которые не нужны поисковому роботу.

Какие URL имеет смысл закрывать в robots.txt

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

/wp-admin/ — административная часть сайта.
/wp-login.php — форма входа.
/wp-json/ — REST API, если у вас нет задачи индексировать его ответы.
Параметры поиска и внутренние фильтры, если они генерируют мусорные URL.
Служебные каталоги плагинов, если они доступны по публичным адресам и не нужны в поиске.

При этом не стоит закрывать CSS, JS и изображения, если они нужны для рендеринга страниц. Поисковик должен видеть страницу так же, как пользователь, иначе можно получить проблемы с оценкой качества и мобильной версткой.

Диагностика: что именно мешает индексации и обходу

Прежде чем править robots.txt, проверьте, какие URL реально попадают в обход. Для этого достаточно трёх источников: отчёт краулера, логи сервера и Search Console. Если в логах много запросов к /wp-login.php или /wp-admin/admin-ajax.php, это не всегда проблема индексации, но это уже сигнал, что роботы и боты тратят ресурсы на служебные адреса.

Полезно отдельно посмотреть, не закрыты ли важные ресурсы случайно. Типичная ошибка — запретить весь /wp-content/, а потом удивляться, что поисковик не видит стили и скрипты. Ещё один частый сценарий — закрыть /wp-json/, а потом сломать интеграцию с блоками, формами или внешними сервисами, которые используют REST API.

Быстрая проверка перед изменениями

Откройте текущий /robots.txt в браузере.
Проверьте, нет ли там дублирующихся правил Disallow.
Посмотрите, не закрыты ли /wp-content/uploads/, /wp-includes/ или пути к теме.
Сравните список служебных URL с тем, что реально сканируется ботом.

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

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

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

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

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

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

Здесь есть важная деталь: admin-ajax.php оставлен открытым, потому что многие темы и плагины используют его на фронтенде. Если закрыть его без проверки, можно получить неработающие формы, фильтры или динамические блоки.

Шаг 2. Добавьте правила только для реально мусорных URL

Если у вас есть публичные страницы поиска с параметром ?s=, их лучше не закрывать грубо через общий запрет на весь сайт. Чаще полезнее убрать их из sitemap, поставить noindex на шаблон поиска и оставить robots.txt как дополнительный барьер для обхода.

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

Шаг 3. Не блокируйте то, что нужно для рендеринга

Если в robots.txt есть запреты на /wp-content/themes/, /wp-content/plugins/ или отдельные папки со стилями и скриптами, это почти всегда лишнее. Поисковик должен иметь возможность загрузить ресурсы, иначе вы сами создадите проблемы с проверкой адаптивности и качеством отображения страниц.

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

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

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

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

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

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

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

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

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

Откройте /robots.txt и убедитесь, что он отдаёт код ответа 200.
Проверьте, что sitemap указан корректно и ведёт на реальный файл.
Прогоните несколько URL через инструмент проверки robots.txt в Search Console, если он доступен.
Посмотрите логи сервера через 1–2 дня: количество запросов к закрытым служебным URL должно снизиться, но не исчезновение всех обращений к фронтенду.
Откройте главную страницу и несколько внутренних страниц после изменений и проверьте, что стили и скрипты загружаются без ошибок 403/404.

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

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

Закрыли слишком широкий путь

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

Путают robots.txt и noindex

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

Закрывают REST API без проверки

Если сайт использует блоки, формы, headless-интеграции или внешние сервисы, запрет /wp-json/ может создать побочные эффекты. Перед блокировкой проверьте, не обращается ли к API фронтенд.

Забывают про sitemap

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

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

robots.txt не защищает от атак, но может снизить количество бессмысленных запросов к служебным адресам. Это полезно для логов и немного разгружает сервер, особенно если бот-активность высокая. Но не рассчитывайте на robots.txt как на барьер безопасности: /wp-login.php и /wp-admin/ всё равно должны быть защищены нормальными мерами — сложными паролями, ограничением попыток входа, 2FA и актуальными обновлениями.

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

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

robots.txt отдаёт 200 и не содержит случайных дубликатов правил.
Закрыты только служебные URL, а не весь /wp-content/.
admin-ajax.php не заблокирован без проверки фронтенда.
Sitemap указан и ведёт на актуальный файл.
Страницы сайта после изменений грузят CSS и JS без ошибок.
В Search Console нет новых сообщений о недоступных ресурсах.

Если после настройки вы видите, что поисковик всё ещё активно обходит мусорные адреса, проблема часто не в robots.txt, а в внутренних ссылках, sitemap или шаблонах, которые продолжают генерировать эти URL. Тогда править нужно источник ссылок, а не только файл для роботов.