XML-RPC в WordPress нужен не всем, но на многих сайтах он продолжает быть включённым просто по умолчанию. Если вы не пользуетесь мобильным приложением WordPress, Jetpack, внешними публикациями через старые клиенты или удалённой синхронизацией, этот интерфейс чаще создаёт лишнюю поверхность атаки, чем пользу. При этом отключать его надо аккуратно: на некоторых сайтах через него до сих пор работают интеграции.
Ниже — рабочая схема: как понять, нужен ли XML-RPC именно вам, как отключить его без побочных эффектов и как проверить результат.
Когда XML-RPC можно отключать, а когда лучше не трогать
Сначала проверьте, используется ли этот механизм вообще. XML-RPC в WordPress отвечает за удалённые запросы к сайту через файл xmlrpc.php. Исторически через него работали публикация из внешних редакторов, мобильное приложение и часть интеграций Jetpack.
Сценарии, где отключение обычно безопасно
- вы публикуете записи только из админки WordPress;
- не используете мобильное приложение WordPress;
- Jetpack не подключён или не использует удалённые функции публикации;
- нет внешних сервисов, которые отправляют записи через XML-RPC;
- на сайте уже есть REST API-интеграции вместо старых удалённых клиентов.
Сценарии, где сначала нужна проверка
- на сайте подключён Jetpack и вы не уверены, какие модули активны;
- редакторы публикуют материалы из стороннего ПО;
- есть интеграция с CRM, которая работает через XML-RPC;
- сайт давно обслуживается и документации по интеграциям нет.
Если вы не уверены, сначала посмотрите логи доступа и запросы к /xmlrpc.php. На живом сайте это полезнее догадок: если endpoint регулярно вызывается, отключение сразу покажет, что именно сломается.
Диагностика: как понять, используется ли xmlrpc.php
Самый простой способ — проверить обращения к файлу на уровне веб-сервера или аналитики логов. На Apache и Nginx ищите строки с xmlrpc.php. Если запросы идут от ботов с частыми попытками авторизации, это ещё один аргумент в пользу отключения.
Если у вас есть доступ к серверу, можно быстро отфильтровать обращения:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50На shared-хостинге обычно проще открыть логи в панели управления или запросить их у поддержки. Если логов нет, проверьте вручную: откройте https://ваш-домен.ru/xmlrpc.php. Сам по себе ответ страницы ещё не означает, что интерфейс нужен, но это подтверждает, что endpoint доступен извне.
Ещё один практический тест — временно заблокировать XML-RPC на staging-копии и проверить, не перестали ли работать:
- мобильное приложение WordPress;
- отправка записей из внешнего редактора;
- синхронизация Jetpack;
- внешние интеграции, если они есть.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вам удобнее управлять сайтом: в коде, на сервере или через плагин безопасности. Для большинства проектов лучше начинать с кода или серверной конфигурации — так меньше лишней нагрузки и зависимостей.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или MU-плагине | Есть доступ к файлам сайта | Прозрачно, без лишних плагинов | Нужно не забыть про обновления темы |
| Правило на сервере | Есть доступ к Nginx/Apache | Блокирует запросы раньше WordPress | Требует доступа к конфигу |
| Плагин безопасности | Нет доступа к серверу или нужен быстрый способ | Просто включить | Добавляет ещё один плагин и слой логики |
Вариант 1: отключить через код
Если вам нужен управляемый и понятный способ, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой MU-плагин. Для отключения XML-RPC достаточно такого кода:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм на уровне WordPress. Если кто-то попытается обратиться к xmlrpc.php, сайт не будет обрабатывать XML-RPC-запросы как рабочие.
Если вы не хотите трогать тему, создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. MU-плагины загружаются автоматически и не зависят от активной темы:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Вариант 2: заблокировать на уровне сервера
Если нужен более жёсткий вариант, можно закрыть доступ к xmlrpc.php на уровне веб-сервера. Это особенно полезно, когда сайт часто атакуют брутфорсом через XML-RPC.
Для Nginx правило обычно выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Этот подход блокирует запросы раньше, чем WordPress успеет их обработать. Но если у вас есть легитимная интеграция, она тоже перестанет работать сразу — это важно учитывать.
Вариант 3: использовать плагин безопасности
Если вы не хотите править код, можно отключить XML-RPC через плагин безопасности. Такой путь удобен для админов без доступа к серверу, но я бы не делал его основным, если задача точечная. Для одного endpoint проще и надёжнее код или серверное правило.
Если на сайте уже стоит плагин, который умеет отключать XML-RPC, проверьте, не дублирует ли он другие функции. Иногда проще оставить одну задачу одному инструменту, чем держать несколько плагинов с пересекающимися настройками.
Пошаговое решение без лишнего риска
- Проверьте, не используется ли XML-RPC в интеграциях и Jetpack.
- Сделайте резервную копию файлов и базы.
- Внесите изменение сначала на staging-копии.
- Отключите XML-RPC через код или серверное правило.
- Проверьте доступ к сайту, авторизацию в админке и публикацию записей.
- Посмотрите логи на предмет ошибок и неожиданных 403/404.
Если у вас несколько окружений, лучше хранить отключение в MU-плагине или в конфигурации сервера, а не в теме. Тогда изменение не потеряется после обновления шаблона.
Как проверить, что отключение сработало
Проверка должна быть не формальной, а практической. Откройте /xmlrpc.php в браузере или отправьте тестовый запрос. Если вы блокировали endpoint на сервере, обычно увидите 403 Forbidden. Если отключали через WordPress-фильтр, поведение зависит от конфигурации, но сам XML-RPC должен перестать принимать рабочие запросы.
Дополнительно проверьте:
- мобильное приложение WordPress не может подключиться к сайту;
- Jetpack не сообщает об ошибках удалённого доступа;
- в логах нет успешных XML-RPC-запросов;
- админка и обычная публикация записей работают как раньше.
Если хотите проверить именно обработку XML-RPC-запроса, можно использовать простой POST-запрос с тестового окружения. В ответе не должно быть признаков успешной авторизации или выполнения метода.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали Jetpack
Это самая типичная ситуация. Причина простая: часть функций Jetpack исторически завязана на удалённый доступ. Решение — либо вернуть XML-RPC, либо отказаться от конкретных модулей Jetpack и перейти на альтернативные механизмы.
Добавили код в активную тему и потеряли его после обновления
Если правка лежит в functions.php родительской темы, она может исчезнуть при обновлении. Для системных ограничений лучше использовать дочернюю тему или MU-плагин.
Заблокировали endpoint на сервере, но забыли про staging
В результате на тестовом сайте всё работает, а на продакшене — нет, или наоборот. Синхронизируйте правило между окружениями и фиксируйте его в документации проекта.
Поставили плагин безопасности только ради одной функции
Это не ошибка само по себе, но часто приводит к лишней нагрузке и конфликтам настроек. Если задача одна — отключить XML-RPC — обычно достаточно кода или серверного правила.
Что ещё стоит проверить после отключения
После изменения полезно пройтись по соседним настройкам безопасности и производительности. Если у вас на сайте много технических правок, имеет смысл проверить и другие поверхности, которые часто оставляют открытыми без необходимости: лишние архивы, дубли, неиспользуемые REST-маршруты, старые плагины и публичные endpoint'ы.
Из практики помогает простой чек-лист:
- обновлены ли ядро, тема и плагины;
- нет ли неиспользуемых интеграций с внешними сервисами;
- закрыты ли лишние публичные endpoint'ы;
- не создаёт ли плагин безопасности конфликтов с кэшем или авторизацией;
- есть ли резервная копия перед следующей правкой.
Если вы ведёте несколько сайтов и часто чистите технический мусор, удобно держать часть таких настроек в одном месте. Например, в Clearfy Pro есть набор функций для SEO и технической чистки сайта; это не замена пониманию, но в типовых задачах помогает не собирать всё вручную.
Главная мысль простая: XML-RPC отключают не «на всякий случай», а когда вы точно понимаете, что он не нужен. Тогда решение получается безопасным, а не декоративным.