XML-RPC в WordPress часто отключают не «на всякий случай», а по конкретной причине: брутфорс по xmlrpc.php, лишняя поверхность атаки, ненужные запросы от старых клиентов и сервисов. Если интеграции через XML-RPC у вас нет, держать этот вход открытым обычно не имеет смысла. Но отключать его нужно аккуратно: некоторые плагины и внешние приложения до сих пор используют этот канал.
Ниже — рабочие способы закрыть XML-RPC на уровне сервера и WordPress, как проверить, что всё сработало, и где чаще всего ломают сайт при такой настройке.
Когда XML-RPC действительно стоит отключать
Сценарий простой: в логах есть запросы к /xmlrpc.php, в панели безопасности срабатывают попытки подбора пароля, а вы не используете мобильное приложение WordPress, удалённую публикацию через старые клиенты или внешние сервисы, которым нужен XML-RPC. В таком случае отключение оправдано.
Если же сайт подключён к сервису, который публикует записи по XML-RPC, или вы используете старое приложение, сначала проверьте зависимость. Иначе после блокировки получите не «усиление безопасности», а неработающую интеграцию.
Что именно отключаем
Речь не про весь REST API и не про комментарии. Мы блокируем только точку входа xmlrpc.php. Это отдельный файл в корне WordPress, который можно закрыть на уровне веб-сервера или через PHP-фильтр.
Диагностика: есть ли у вас реальные запросы к xmlrpc.php
Перед изменениями полезно понять, используется ли XML-RPC вообще. Самый быстрый способ — посмотреть access log веб-сервера и поискать обращения к xmlrpc.php.
grep