Как отключить XML-RPC в WordPress без поломки внешних сервисов

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

Когда XML-RPC можно отключать, а когда лучше не трогать

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

Типичные сценарии, где XML-RPC ещё встречается

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

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

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

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

Что проверить перед отключением

• используется ли Jetpack или похожий сервис;
• есть ли публикация через сторонние приложения;
• есть ли старые мобильные клиенты у редакторов;
• есть ли интеграции с CRM, которые работают через XML-RPC;
• не завязаны ли на него плагины автопостинга или синхронизации.

Если доступ к серверу есть, полезно посмотреть, не атакуют ли xmlrpc.php перебором паролей. Этот файл часто используют для массовых попыток авторизации, потому что он позволяет делать много запросов за один HTTP-вызов. В таком случае отключение или жёсткое ограничение доступа действительно имеет смысл.

Пошаговое решение: как отключить XML-RPC без лишнего риска

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

Вариант 1: отключить XML-RPC через хук

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

add_filter( 'xmlrpc_enabled', '__return_false' );

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

Вариант 2: закрыть доступ на уровне сервера

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

Для Apache:

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

Для Nginx обычно используют отдельное правило в конфигурации сайта:

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

Этот вариант жёстче, чем фильтр WordPress: запросы режутся ещё до загрузки CMS. Но именно поэтому его стоит применять только после проверки зависимостей.

Вариант 3: отключение через плагин безопасности

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

Если нужен более широкий набор технических чисток и отключения лишнего функционала, в экосистеме WPShop есть Clearfy Pro: он закрывает часть типовых SEO- и технических дублей, а также помогает с чисткой сайта. Ставить такой инструмент только ради XML-RPC не обязательно, но в проектах с большим количеством «лишнего» кода он бывает удобен.

Сравнение подходов: код, сервер, плагин

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

После отключения не ограничивайтесь тем, что страница /xmlrpc.php «не открывается». Проверка должна показать, что сайт работает в ваших реальных сценариях.

Что проверить вручную

• откройте /xmlrpc.php в браузере и убедитесь, что доступ закрыт или функция отключена;
• попробуйте войти в админку обычным способом;
• проверьте публикацию и редактирование записей;
• если есть внешние сервисы, сделайте тестовый запрос или синхронизацию;
• посмотрите логи сервера на предмет ошибок после изменения.

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

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

Отключили XML-RPC, но сломали Jetpack

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

Поставили правило в .htaccess, но оно не сработало

Причина обычно в том, что сайт работает на Nginx, либо правила Apache переопределяются другой конфигурацией. Для Apache важно, чтобы модуль и директивы были разрешены. Для Nginx нужен именно конфиг сервера, а не файл внутри WordPress.

Скрыли проблему плагином, но нагрузка осталась

Если плагин просто отвечает ошибкой внутри WordPress, запрос всё равно доходит до PHP. При большом количестве обращений это не лучший вариант. В таком случае лучше закрывать доступ на уровне веб-сервера или хотя бы ограничивать его через firewall/WAF.

Отключили без инвентаризации интеграций

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

Безопасность и производительность: что ещё имеет смысл сделать рядом

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

• ограничьте попытки входа в админку;
• проверьте, не открыт ли wp-json без необходимости для лишних маршрутов;
• уберите неиспользуемые плагины и темы;
• включите кеширование страниц и объектов, если сайт его поддерживает;
• проверьте, не создают ли плагины дубли мета-тегов и служебных страниц.

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

Короткий чек-лист перед выкладкой на продакшен

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

Если после отключения сайт работает как раньше, а обращения к xmlrpc.php исчезли или стали блокироваться на уровне сервера, значит задача решена правильно. Если что-то сломалось, не возвращайте всё назад «вслепую» — сначала найдите конкретную интеграцию, которая зависит от XML-RPC, и уже потом решайте, чем её заменить.