Служебные URL WordPress часто попадают в индекс не потому, что они нужны пользователю, а потому что их кто-то случайно оставил открытыми для поисковиков. В результате в отчётах Search Console появляются страницы входа, XML-RPC, feed-адреса, архивы с параметрами и другие технические URL, которые не должны конкурировать с основным контентом.
Задача здесь не в том, чтобы «всё закрыть». Нужен аккуратный список исключений: что действительно не должно индексироваться, что лучше отдать с noindex, а что вообще не стоит трогать, чтобы не сломать интеграции и не потерять полезные сигналы для сайта.
Какие URL обычно мешают индексации
Перед правками полезно понять, что именно вы хотите закрыть. На практике чаще всего речь идёт о таких типах страниц:
/xmlrpc.php— служебная точка WordPress, не предназначенная для индексации;/wp-login.phpи страницы авторизации;- ленты
/feed/и их вариации, если они не нужны как отдельный канал; - страницы с параметрами сортировки, фильтрации и поиска;
- технические архивы, которые дублируют основной контент.
Если закрыть их грубо через robots.txt, можно получить ситуацию, когда URL остаётся в индексе без возможности переобхода. Для части страниц это нормально, но для удаления уже проиндексированных адресов чаще нужен noindex или корректный редирект.
Диагностика: что именно уже индексируется
Сначала проверьте, какие URL реально попали в поиск. Не ориентируйтесь только на ощущение «их много». Откройте отчёт по страницам в Google Search Console и посмотрите, какие служебные адреса там есть. Дополнительно можно быстро проверить через поиск по сайту:
site:example.com xmlrpc OR wp-login OR feedЕсли в выдаче видны не только сами URL, но и сниппеты с техническими страницами, значит поисковик уже успел их обойти. В этом случае простого запрета в robots.txt может быть недостаточно — нужно либо отдать noindex, либо убрать страницу из индекса через корректный HTTP-ответ.
Что проверить до изменений
- использует ли сайт внешние сервисы, которым нужен XML-RPC;
- есть ли мобильное приложение, публикация по API или старые интеграции;
- не завязаны ли на feed сторонние подписки или парсеры;
- не закрыт ли уже доступ на уровне сервера или плагина безопасности;
- нет ли конфликтующих правил в
robots.txtи в SEO-плагине.
Пошаговое решение: закрываем индексацию без лишних рисков
Ниже — рабочая схема, которая обычно даёт предсказуемый результат. Она не требует выдуманных хуков и не ломает сайт, если у вас нет старых зависимостей от XML-RPC.
1. Закройте служебные страницы от индексации через заголовок или мета-тег
Для URL, которые должны быть доступны, но не должны попадать в поиск, лучше использовать noindex. В WordPress это можно сделать точечно через wp_robots для нужных шаблонов.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_feed() || is_search() ) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
return $robots;
} );Такой вариант подходит для лент и страниц поиска, если вы не хотите, чтобы они ранжировались. Для wp-login.php и xmlrpc.php этот фильтр не сработает, потому что это не обычные фронтенд-страницы WordPress.
2. Для XML-RPC отдайте корректный ответ сервера
Если XML-RPC не нужен, лучше не просто прятать его от роботов, а закрыть сам endpoint. Самый безопасный вариант — вернуть 403 Forbidden на запросы к xmlrpc.php. Это не «маскировка», а явный запрет на использование точки входа.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
add_action( 'init', function() {
if ( isset( $_SERVER['SCRIPT_NAME'] ) && $_SERVER['SCRIPT_NAME'] === '/xmlrpc.php' ) {
status_header( 403 );
exit;
}
} );Первый фрагмент отключает XML-RPC на уровне WordPress. Второй — подстраховка, если запрос всё же дошёл до файла. Если у вас есть Jetpack, мобильное приложение WordPress или внешняя публикация через XML-RPC, этот шаг нужно тестировать отдельно.
3. Уберите служебные URL из sitemap
Если ваш SEO-плагин добавляет в карту сайта страницы поиска, архивы с параметрами или другие технические URL, их нужно исключить. В стандартном WordPress XML-карта не включает xmlrpc.php или wp-login.php, но плагины и кастомные решения иногда добавляют лишнее.
Проверьте sitemap вручную: откройте его в браузере и убедитесь, что там нет URL, которые вы хотите скрыть. Если они есть, ищите настройку в SEO-плагине или фильтр, который исключает конкретные типы записей и таксономий.
4. Для уже проиндексированных страниц используйте правильный способ удаления
Если URL уже в индексе, одного Disallow в robots.txt мало. Поисковик может оставить страницу в базе без возможности переобхода. Для удаления обычно работают такие варианты:
noindexна самой странице;- редирект на релевантный URL, если страница не нужна совсем;
- возврат
410 Goneдля окончательно удалённых адресов; - инструмент удаления URL в Search Console как временная мера.
Для XML-RPC и wp-login.php чаще всего достаточно запрета на уровне сервера или WordPress, потому что индексировать там нечего. Для страниц поиска и параметров лучше оставить возможность обойти страницу и увидеть noindex.
Сравнение подходов: robots.txt, noindex, серверный запрет
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
robots.txt | Чтобы не тратить краулинговый бюджет на служебные URL | Просто внедрить, быстро проверить | Не удаляет уже проиндексированные страницы |
noindex | Для страниц, которые должны открываться, но не ранжироваться | Понятный сигнал поисковику | Страница должна быть доступна для обхода |
| 403/410 | Для endpoint'ов и удалённых адресов | Жёстко и однозначно | Нельзя применять к нужным публичным страницам |
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что сервер и поисковик видят страницу так, как вы задумали.
- Откройте
/xmlrpc.phpв браузере или черезcurlи проверьте статус ответа. - Проверьте исходный код страниц поиска и лент: должен быть виден
noindex, если вы его добавляли. - Посмотрите sitemap и убедитесь, что служебных URL там нет.
- В Search Console отправьте страницу на повторную проверку после переобхода.
curl -I https://example.com/xmlrpc.php
curl -I https://example.com/wp-login.php
curl -I https://example.com/feed/Для xmlrpc.php ожидаемым результатом будет 403 или другой явно запрещающий ответ, если вы так настроили сервер. Для feed и страниц поиска — либо 200 с noindex, либо другой выбранный вами сценарий.
Частые ошибки и как их исправить
Закрыли всё через robots.txt, но URL остались в индексе
Это типичная ситуация. robots.txt запрещает обход, но не гарантирует удаление уже известного URL. Если страница уже в индексе, добавьте noindex или отдайте 410, если адрес больше не нужен.
Отключили XML-RPC, а потом перестали работать внешние сервисы
Перед блокировкой проверьте, что сайт не использует Jetpack, старые мобильные клиенты, публикацию через сторонние приложения или интеграции, завязанные на XML-RPC. Если сервис нужен, лучше ограничить доступ по IP или закрыть только опасные методы, а не рубить endpoint целиком.
Поставили noindex, но страница всё равно в выдаче
Поисковику нужно время на повторный обход. Кроме того, если страница закрыта в robots.txt, робот может не увидеть noindex. Сначала дайте доступ на обход, потом уже закрывайте индексацию.
Сломали sitemap после правок в SEO-плагине
Если после исключения URL карта сайта стала пустой или начала отдавать ошибки, проверьте фильтры плагина и кеш. Иногда проблема не в логике, а в том, что старый sitemap ещё отдается из кеша страницы или CDN.
Что ещё стоит учесть для безопасности и производительности
Если вы закрываете служебные URL не только ради SEO, но и ради снижения шума в логах, не забывайте про серверный уровень. Для xmlrpc.php и wp-login.php часто достаточно правил на уровне nginx, Apache или WAF. Это уменьшает количество лишних запросов ещё до загрузки WordPress.
Но здесь важен баланс: жёсткий запрет на уровне сервера быстрее, а вот точечный noindex полезнее для страниц, которые должны остаться доступными. Для крупных сайтов удобнее сначала описать политику: какие URL индексируются, какие доступны только пользователю, а какие должны отвечать 403 или 410.
Если вам нужно регулярно чистить сайт от дублей, технических архивов и лишних страниц, имеет смысл вынести это в отдельный регламент. В некоторых проектах для такой работы используют Clearfy Pro, но сам принцип остаётся тем же: сначала классифицировать URL, потом применять нужный тип запрета, а не отключать всё подряд.
После внедрения полезно ещё раз пройтись по сайту глазами поисковика: карта сайта, внутренние ссылки, редиректы, ответы сервера и индексация в Search Console должны совпадать. Если хотя бы один из этих слоёв расходится, служебные страницы будут возвращаться в индекс снова.