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

Автор: Антон Ершов | Опубликовано: 03.09.2026

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

Ниже — практический сценарий: как понять, нужен ли вам XML-RPC, как отключить его безопасно и как проверить, что ничего не сломалось.

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

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

Отключение особенно уместно, если:

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

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

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

Для быстрой проверки можно временно добавить простой лог в functions.php дочерней темы или в небольшой mu-плагин. Это не замена серверным логам, но помогает увидеть, что запросы доходят до WordPress.

<?php
add_action('init', function () {
    if (isset($_SERVER['REQUEST_URI']) && strpos($_SERVER['REQUEST_URI'], 'xmlrpc.php') !== false) {
        error_log('XML-RPC request from ' . ($_SERVER['REMOTE_ADDR'] ?? 'unknown'));
    }
});

Если после этого в error log появляются обращения с разных IP, значит файл реально сканируют. Это не доказательство атаки, но хороший повод убрать лишнюю поверхность риска.

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

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

Как отключить XML-RPC: три рабочих варианта

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

Способ	Плюсы	Минусы
Плагин	Быстро, без правок кода	Лишняя зависимость от плагина
Код в теме или mu-плагине	Прозрачно, легко контролировать	Нужно не забыть о дочерней теме или mu-плагине
Серверная блокировка	Жёстко закрывает доступ	Можно случайно задеть нужные сценарии, если не проверить интеграции

Вариант 1: отключить через код

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

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

Такой код лучше размещать не в основной теме, а в дочерней теме или в небольшом mu-плагине. Тогда он не исчезнет после обновления темы.

Вариант 2: убрать доступ к файлу на уровне сервера

Если у вас Apache и сайт работает через .htaccess, можно закрыть доступ к xmlrpc.php отдельным правилом. Это жёсткий вариант, и его стоит использовать только после проверки зависимостей.

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

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

Вариант 3: использовать плагин для отключения

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

Пошаговое внедрение без сюрпризов

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

Если вы отключаете через код, лучше делать это в отдельном mu-плагине. Так настройка не потеряется при смене темы и не будет зависеть от редактора файлов в админке.

<?php
/*
Plugin Name: Disable XML-RPC
*/
add_filter('xmlrpc_enabled', '__return_false');

Как проверить, что решение сработало

Проверка должна быть не только визуальной. Откройте https://ваш-домен.ru/xmlrpc.php в браузере: при корректной блокировке вы не должны видеть обычный рабочий ответ WordPress для XML-RPC. Дальше проверьте реальные сценарии.

Попробуйте войти через мобильное приложение WordPress, если вы им пользуетесь.
Проверьте публикацию через внешние сервисы, если они были подключены.
Посмотрите access log: обращения к xmlrpc.php должны либо исчезнуть, либо получать 403/404 в зависимости от способа блокировки.
Убедитесь, что обычная работа сайта не изменилась: вход в админку, REST API, публикация записей, загрузка медиа.

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

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

Отключили в теме, а после обновления всё вернулось

Это типичная ошибка. Код в основной теме не подходит для технических ограничений. Перенесите фильтр в дочернюю тему или mu-плагин.

Сразу закрыли файл на сервере и сломали интеграцию

Так бывает, если не проверили мобильное приложение или старый сервис публикации. Сначала тестируйте на staging, потом закрывайте на проде.

Поставили плагин, который делает слишком много

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

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

Это не проверка. Нужно смотреть именно /xmlrpc.php, логи сервера и реальные интеграции, а не только визуальную доступность сайта.

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

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

удалите неиспользуемые плагины, а не просто деактивируйте их;
проверьте, не торчит ли в публичном доступе лишняя информация о версии WordPress;
ограничьте число администраторов;
не отключайте REST API без понимания последствий — это другой механизм, и он нужен многим современным плагинам.

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

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