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