XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, Jetpack, внешние публикации и некоторые интеграции. Проблема не в самом файле xmlrpc.php, а в том, что его закрывают без проверки зависимостей. Если у сайта нет старых внешних клиентов и вы не используете сервисы, которым нужен XML-RPC, его действительно можно отключить. Но делать это лучше по схеме: сначала диагностика, потом блокировка, затем проверка.
Когда XML-RPC вообще нужен
XML-RPC — это старый способ удалённого доступа к WordPress. Он до сих пор встречается в нескольких сценариях:
- мобильное приложение WordPress для публикации и редактирования;
- Jetpack и связанные с ним функции;
- внешние сервисы автопостинга и планирования;
- некоторые старые интеграции, которые не перешли на REST API.
Если сайт живёт только в админке и через обычный браузер, XML-RPC чаще всего не нужен. Но это надо подтвердить по факту, а не по ощущению.
Диагностика: как понять, можно ли отключать
Сначала проверьте, кто реально обращается к xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный вариант. Ищите запросы к этому файлу за последние дни или недели. Если запросов нет, это хороший сигнал, но не абсолютная гарантия: часть интеграций может срабатывать редко.
Полезно отдельно пройтись по установленным плагинам и внешним сервисам. Особое внимание — Jetpack, приложениям для публикации с телефона, сервисам импорта/экспорта и автопостинга. Если сайт обслуживает несколько редакторов, уточните у них, пользуются ли они мобильным приложением WordPress.
Быстрая проверка снаружи
Если открыть /xmlrpc.php в браузере, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не признак уязвимости, а просто штатное поведение. Для проверки блокировки нужен именно POST-запрос или анализ ответа сервера после отключения.
Способы отключения: что выбрать
Есть три практических варианта: через код, через сервер и через плагин. Для большинства сайтов достаточно кода в functions.php дочерней темы или в небольшом mu-plugin. Серверный вариант надёжнее, но требует доступа к конфигурации. Плагин удобен, если вы не хотите трогать код, но это лишняя зависимость.
| Способ | Плюсы | Минусы | Когда брать |
|---|---|---|---|
| Код в WordPress | Быстро, прозрачно, легко откатить | Нужно не забыть про тему/му-плагин | Обычный сайт без сложной инфраструктуры |
| Правило на сервере | Останавливает запросы раньше WordPress | Нужен доступ к конфигу | Высокая нагрузка или жёсткие требования к безопасности |
| Плагин | Без кода | Лишний плагин ради одной функции | Если нет доступа к файлам и серверу |
Пошаговое решение через код
Самый безопасный для сопровождения вариант — отключить XML-RPC фильтром xmlrpc_enabled. Такой подход не ломает сайт и легко снимается, если выяснится, что какая-то интеграция всё-таки нужна.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Код можно добавить в functions.php дочерней темы, но лучше вынести в небольшой mu-plugin, чтобы он не зависел от смены темы. Пример минимального mu-plugin:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Если нужен более жёсткий вариант, можно сразу отдавать 403 на уровне WordPress. Это полезно, когда вы хотите не просто отключить функциональность, а явно закрыть доступ:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );
Я бы начинал с фильтра xmlrpc_enabled. Он проще, понятнее и обычно достаточно надёжен для типового сайта.
Если нужен серверный блок
Когда есть доступ к конфигурации веб-сервера, можно закрыть xmlrpc.php раньше, чем запрос попадёт в WordPress. Это снижает лишнюю нагрузку и уменьшает поверхность атаки. Для Apache часто используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>
Для Nginx логика обычно задаётся в конфигурации сайта. Конкретный блок зависит от вашей схемы, но смысл один: запросы к /xmlrpc.php должны получать отказ на уровне сервера. После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервис.
Проверка результата после внедрения
После отключения проверьте не только сам файл, но и реальные сценарии. Это важнее, чем просто увидеть ошибку 403 в браузере.
- Откройте
/xmlrpc.phpи убедитесь, что доступ закрыт или функциональность отключена. - Попробуйте опубликовать запись через мобильное приложение WordPress, если вы его используете.
- Проверьте Jetpack и другие подключённые сервисы.
- Посмотрите логи ошибок и access log на предмет новых отказов.
Если после отключения сайт продолжает работать как раньше, а внешние клиенты не жалуются, значит решение внедрено корректно.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про Jetpack
Jetpack в ряде сценариев использует XML-RPC. Если после блокировки часть функций перестала отвечать, сначала проверьте, действительно ли они завязаны на этот канал. Иногда достаточно перейти на другой способ подключения или пересмотреть набор функций Jetpack.
Скрыли проблему плагином безопасности, но не убрали источник запросов
Некоторые плагины просто маскируют доступ, но не помогают понять, кто и зачем стучится в xmlrpc.php. Если у вас есть подозрительные запросы, сначала посмотрите логи, а уже потом закрывайте доступ.
Поставили жёсткий запрет без теста
Самая частая ошибка — сразу резать доступ на сервере. Это нормально для зрелой инфраструктуры, но опасно на сайте, где редакторы работают через мобильное приложение или подключён внешний сервис публикации.
Сделали правку в родительской теме
Если отключение добавили в functions.php активной темы, оно исчезнет после обновления или смены темы. Для постоянного правила лучше использовать mu-plugin.
Чек-лист перед отключением
- Проверены access log и частота запросов к
xmlrpc.php. - Уточнено, используется ли мобильное приложение WordPress.
- Проверен Jetpack и другие внешние интеграции.
- Выбран способ отключения: код, сервер или плагин.
- После внедрения протестированы реальные рабочие сценарии.
Безопасность и производительность
Отключение XML-RPC не делает сайт «защищённым полностью», но убирает один из часто сканируемых входов. Это полезно, если у вас много автоматических запросов и лишняя нагрузка на сервер. При этом не стоит ожидать, что одна эта мера заменит обновления, ограничение попыток входа и нормальную политику паролей.
Если вам нужно не только закрыть XML-RPC, но и убрать другие технические дубли и лишние точки входа, имеет смысл смотреть в сторону комплексной чистки сайта. В экосистеме WPShop для таких задач есть Clearfy Pro: он помогает закрывать часть типовых SEO и технических дублей, а также упрощает базовую оптимизацию. Подробности можно посмотреть здесь: https://wpshop.ru/plugins/clearfy.
Если после отключения что-то сломалось, не пытайтесь «лечить» это повторной блокировкой. Сначала верните доступ, найдите зависимость и только потом выбирайте другой способ закрытия.