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

Автор: Евгения Данилова | Опубликовано: 22.09.2026

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

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

Если сайт не использует внешние клиенты для публикации, старые интеграции и pingback/trackback, XML-RPC обычно только расширяет поверхность атаки. На практике его отключают, когда:

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

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

Диагностика: используется ли xmlrpc.php на вашем сайте

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

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

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

Если доступа к логам нет, можно временно проверить ответ сервера на сам файл. Это не доказывает использование, но показывает, открыт ли endpoint.

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

Если сервер отвечает 200 или 405, файл доступен. Это нормально само по себе, но для защищённого сайта часто хотят ограничить именно доступ к нему.

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

Есть три рабочих подхода: через плагин, через код и на уровне сервера. Выбор зависит от того, насколько вам нужен контроль и есть ли доступ к конфигурации хостинга.

Способ	Плюсы	Минусы	Когда выбирать
Плагин	Быстро, без правок кода	Дополнительная зависимость	Если нужен простой и обратимый вариант
Код в теме или mu-plugin	Контроль, минимум лишнего	Нужно аккуратно обновлять	Если есть доступ к файлам сайта
Серверная блокировка	Режет запросы раньше WordPress	Нужен доступ к nginx/apache	Если важна защита и нагрузка

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

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

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

Это отключает XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно. Если нужно убрать ещё и pingback-заголовки, добавьте дополнительную очистку:

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

add_action('init', function () {
    remove_action('wp_head', 'rsd_link');
    remove_action('wp_head', 'wlwmanifest_link');
    remove_action('wp_head', 'wp_generator');
});

Последний блок не отключает XML-RPC сам по себе, но убирает часть лишних сигналов из <head>.

Вариант 2: заблокировать xmlrpc.php на уровне сервера

Если сайт под нагрузкой или вы хотите отсечь запросы до загрузки WordPress, блокируйте файл на уровне веб-сервера. Для Apache обычно используют .htaccess:

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

Для nginx логика зависит от конфигурации, но типовой вариант выглядит так:

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

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

Вариант 3: оставить XML-RPC, но ограничить риск

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

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

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

После отключения не ограничивайтесь открытием главной страницы. Нужно проверить именно endpoint и связанные сценарии.

Откройте /xmlrpc.php в браузере — доступ должен быть закрыт или возвращать ограниченный ответ.
Проверьте мобильное приложение WordPress, если оно использовалось раньше.
Проверьте внешние сервисы автопостинга и синхронизации.
Посмотрите логи сервера: запросы к xmlrpc.php не должны приводить к успешной обработке.

Для быстрой проверки можно отправить тестовый запрос:

curl -X POST https://example.com/xmlrpc.php -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

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

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

Отключили XML-RPC в коде темы, а потом сменили тему

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

Заблокировали xmlrpc.php, но сломали внешнюю публикацию

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

Отключили всё подряд через плагин безопасности

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

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

Главная может открываться нормально, даже если сломалась публикация через приложение или автосинхронизация. Проверять нужно именно endpoint и реальные сценарии использования.

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

Если цель — не просто отключить XML-RPC, а уменьшить шум и риск, полезно сделать ещё несколько вещей:

убрать pingback и trackback, если они не нужны;
проверить, не включены ли лишние внешние интеграции;
ограничить частые POST-запросы на уровне WAF или сервера;
не держать защиту только в теме — используйте mu-plugin или серверную конфигурацию;
после изменений очистить кеш, если у вас подключён page cache или CDN.

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

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