Как отключить XML-RPC в WordPress и закрыть его от ботов

Автор: Лев Ершов | Опубликовано: 05.09.2026

XML-RPC в WordPress часто отключают не из-за моды, а по конкретной причине: на сайт идут лишние запросы, в логах появляется шум, а иногда — попытки подбора паролей через xmlrpc.php. При этом просто удалить файл нельзя: это часть ядра WordPress. Рабочий подход здесь другой — сначала понять, используется ли XML-RPC вообще, затем ограничить доступ и проверить, не сломались ли внешние сервисы.

Когда XML-RPC действительно стоит отключать

Если сайт не подключен к старым мобильным клиентам WordPress, не использует Jetpack в режиме, где нужен XML-RPC, и не принимает публикации через внешние приложения, то держать этот интерфейс открытым обычно нет смысла. Особенно если в access log регулярно встречаются запросы к /xmlrpc.php с одинаковыми payload и большим количеством попыток авторизации.

Но есть и обратная ситуация: у сайта может быть интеграция, которая до сих пор опирается на XML-RPC. Поэтому перед изменениями лучше проверить фактическое использование, а не отключать наугад.

Диагностика проблемы: кто и зачем стучится в xmlrpc.php

Начните с логов веб-сервера. Если у вас Nginx или Apache, ищите обращения к xmlrpc.php и смотрите, это единичные запросы или поток. Важны не только IP, но и коды ответа, частота и наличие POST-запросов.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если доступ к логам ограничен, можно временно проверить поведение через браузер или curl. Сам по себе ответ 200 на xmlrpc.php еще не значит, что интерфейс нужен, но это сигнал, что точка входа открыта.

curl -I https://example.com/xmlrpc.php

Для более точной проверки полезно посмотреть, не используют ли XML-RPC внешние сервисы. Типичные признаки:

Jetpack не синхронизируется или теряет связь после блокировки;
мобильное приложение WordPress не может публиковать записи;
сторонний сервис автопостинга пишет об ошибке авторизации;
в логах есть вызовы system.multicall и похожие массовые запросы.

Что выбрать: код, плагин или серверное правило

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

Подход	Когда подходит	Плюсы	Минусы
Код в теме или mu-plugin	Нужен контроль внутри WordPress	Просто проверить и откатить	Не защищает до загрузки WordPress
Правило на сервере	Нужна жесткая блокировка	Отсекает запросы раньше PHP	Нужно править конфиг Nginx/Apache
Плагин для оптимизации	Нужна быстрая настройка без кода	Удобно для редактора или администратора	Лишняя зависимость от плагина

Если задача — именно отключить XML-RPC, а не просто скрыть его следы, лучше начинать с серверного правила. Если нужен более мягкий сценарий, можно вернуть 403 из WordPress и посмотреть, не появятся ли ошибки у интеграций.

Пошаговое решение: вернуть 403 для XML-RPC из WordPress

Самый безопасный для теста вариант — запретить доступ к xmlrpc.php через фильтр xmlrpc_enabled. Это не удаляет файл и не ломает ядро, но отключает обработку XML-RPC на уровне WordPress.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Код можно добавить в functions.php дочерней темы, но для технической настройки лучше использовать mu-plugin, чтобы правило не исчезло после смены темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Если нужен жесткий запрет на уровне сервера, для Nginx подойдет отдельное правило:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Для Apache можно использовать .htaccess:

<Files "xmlrpc.php">
    Require all denied
</Files>

Серверный вариант предпочтительнее, если сайт атакуют брутфорсом и вы хотите снизить нагрузку до запуска PHP. Но перед включением такого правила проверьте, не завязан ли на XML-RPC какой-то рабочий процесс.

Нужно ли добавлять запрет в robots.txt

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

User-agent: *
Disallow: /xmlrpc.php

Это не замена серверной блокировке. Рассматривайте robots.txt как дополнительный слой, а не как средство безопасности.

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

После отключения XML-RPC проверьте три вещи: код ответа, отсутствие ошибок в логах и работоспособность зависимых сервисов. Если вы ставили фильтр xmlrpc_enabled, запрос к /xmlrpc.php должен перестать обрабатываться WordPress. Если блокировали на сервере, ответ обычно будет 403.

curl -I https://example.com/xmlrpc.php

Дальше откройте админку и убедитесь, что обычная авторизация, публикация записей и REST API работают как раньше. Если у вас подключен Jetpack, проверьте его статус отдельно. Если используется мобильное приложение WordPress, попробуйте выполнить тестовую публикацию.

Полезно также посмотреть access log через 10–15 минут после изменения. Если запросы к xmlrpc.php продолжаются, но уже получают 403, значит блокировка сработала. Если вместо 403 вы видите 200, правило не применилось или его перебивает другое место конфигурации.

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

Отключили XML-RPC, а Jetpack перестал подключаться

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

Добавили правило в тему, а после обновления оно исчезло

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

Поставили robots.txt и решили, что этого достаточно

Нет, robots.txt не защищает от атак и не закрывает endpoint. Он только просит поисковики не обходить путь. Для безопасности нужен фильтр WordPress или серверная блокировка.

Сразу закрыли файл на сервере, не проверив интеграции

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

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

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

Для сайтов, где важна техническая чистота, удобно держать такие правила в одном месте. Если вы используете Clearfy Pro, у него есть инструменты для отключения лишних функций WordPress и чистки служебных элементов; это полезно, когда нужно не только закрыть XML-RPC, но и убрать другие источники дублей и лишнего шума. Смотрите документацию продукта по адресу https://wpshop.ru/plugins/clearfy.

Если вы работаете на VPS, не забывайте, что серверная блокировка должна быть согласована с конфигурацией веб-сервера и кэша. Иногда правило в Nginx есть, но запросы проходят через другой слой, и в итоге вы видите не 403, а обычный ответ WordPress. В таких случаях проверяйте именно тот виртуальный хост, который обслуживает домен.

В итоге рабочая схема выглядит так: сначала выяснить, нужен ли XML-RPC, затем выбрать уровень блокировки, после этого проверить коды ответа и зависимые интеграции. Это быстрее и безопаснее, чем просто «выключить всё лишнее» наугад.