Как закрыть и отключить XML-RPC в WordPress без поломки приложений и пингабэков

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

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

Когда XML-RPC действительно проблема

Файл xmlrpc.php — это не «ошибка WordPress», а легитимный интерфейс обмена данными. Проблема в том, что на большинстве обычных сайтов он не нужен постоянно, но остаётся доступным извне. В логах это выглядит как частые POST-запросы к /xmlrpc.php, иногда с попытками метода system.multicall и перебором учётных данных.

Типичные признаки, что XML-RPC пора закрывать:

• в логах много запросов к xmlrpc.php с разных IP;
• на сайте нет внешних сервисов, которым нужен удалённый постинг;
• мобильное приложение WordPress не используется;
• в панели безопасности или на хостинге видны попытки brute force именно через XML-RPC;
• сайт работает на обычной админке, а не на старой цепочке публикаций через внешние клиенты.

Что может сломаться, если отключить без проверки

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

Диагностика: нужен ли вам xmlrpc.php

Перед изменениями проверьте, используется ли endpoint реально. Самый простой способ — посмотреть access log веб-сервера или логи на уровне хостинга. Ищите запросы к /xmlrpc.php за последние дни или недели.

grep