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

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

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

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

Если вы не используете старые внешние клиенты, мобильное приложение WordPress, Jetpack для удалённого управления или сервисы, которые публикуют записи через XML-RPC, то этот интерфейс обычно не нужен. Для большинства сайтов достаточно REST API и обычной админки.

Но перед отключением стоит проверить не абстрактно «пользуемся ли мы чем-то», а конкретно:

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

Быстрая диагностика перед изменениями

Самый простой тест — посмотреть, отвечает ли /xmlrpc.php и не завязаны ли на него ваши сценарии. Открывать файл в браузере недостаточно: он может отвечать даже на пустой POST-запрос. Лучше проверить логику использования на уровне плагинов и сервисов.

curl -i https://example.com/xmlrpc.php

Если в ответе вы видите сообщение вроде XML-RPC server accepts POST requests only., это нормально и само по себе не говорит, нужен вам интерфейс или нет. Важнее понять, кто именно его использует.

Как отключить XML-RPC безопасно

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

Способ	Плюсы	Минусы
Плагин	Быстро, без правки кода	Добавляет зависимость от плагина, иногда скрывает причину проблемы
Код	Прозрачно, легко откатить	Нужно аккуратно выбрать место размещения
Серверная блокировка	Режет запросы раньше WordPress	Можно случайно сломать нужную интеграцию, сложнее диагностировать

Вариант через код

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

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Это отключает сам XML-RPC на уровне WordPress. Если сайт использует только обычный вход в админку и REST API, этого обычно достаточно.

Вариант через .htaccess для Apache

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

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

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

Что проверить после отключения

После изменений не ограничивайтесь тем, что сайт открывается в браузере. Проверьте именно те сценарии, которые чаще всего ломаются.

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

Для быстрой проверки можно снова отправить запрос на xmlrpc.php. Если вы отключали его через фильтр WordPress, ответ должен измениться: сервер не должен обрабатывать XML-RPC как рабочий интерфейс.

curl -i https://example.com/xmlrpc.php

Если используете Jetpack, проверьте его статус в админке WordPress. Когда связь с WordPress.com нарушена, это обычно видно сразу: модуль сообщает о проблеме подключения или синхронизации.

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

Отключили XML-RPC, но забыли про Jetpack

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

Поставили плагин и не поняли, что именно он блокирует

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

Закрыли доступ на сервере и потеряли возможность быстро откатить

Серверная блокировка хороша, пока вы уверены в конфигурации. Но если сайт обслуживает несколько интеграций, лучше сначала использовать фильтр WordPress. Он проще в откате и не требует лезть в конфиг веб-сервера при каждом изменении.

Проверили только главную страницу

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

Если XML-RPC нужен частично

Иногда полностью отключать интерфейс не стоит. Например, сайт использует Jetpack, но при этом вы хотите сократить поверхность атаки. В таком случае лучше не ломать рабочий канал, а ограничить другие слабые места: обновить плагины, включить двухфакторную авторизацию, ограничить попытки входа, проверить права пользователей и убрать лишние интеграции.

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

Практические советы по безопасности и производительности

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

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

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

Короткий чек-лист перед отключением

Проверить, используется ли Jetpack.
Уточнить, публикуют ли контент из мобильного приложения WordPress.
Посмотреть, нет ли внешних сервисов, завязанных на XML-RPC.
Выбрать способ отключения: код, плагин или сервер.
После изменения протестировать вход, синхронизацию и публикацию.
Проверить логи на ошибки и повторные обращения к xmlrpc.php.

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