Как отключить XML-RPC в WordPress и не сломать мобильные приложения и Jetpack

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

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

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

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

Диагностика: кто обращается к xmlrpc.php

Перед изменениями проверьте, есть ли запросы к /xmlrpc.php в логах веб-сервера. Если доступ к логам есть, это самый надёжный способ понять, используется ли endpoint вообще.

Что искать в логах

• частые POST-запросы к xmlrpc.php с одинаковых IP;
• ошибки авторизации с повторяющимися логинами;
• запросы от Jetpack или мобильного приложения, если они у вас подключены;
• обращения от внешних сервисов публикации, если они настроены.

Пример поиска по access log в Linux:

grep