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

Автор: Андрей Громов | Опубликовано: 10.09.2026

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

Когда XML-RPC действительно мешает

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

Быстрая диагностика

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

Проверьте, используется ли Jetpack.
Убедитесь, что никто не публикует через мобильное приложение WordPress.
Посмотрите логи на частые обращения к /xmlrpc.php.
Сравните нагрузку до и после изменения, если сайт уже под атакой.

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

Выбор зависит от того, насколько жёстко вы хотите закрыть доступ и где удобнее управлять настройкой. Для большинства сайтов достаточно одного из двух способов: через фильтр в коде или через серверную конфигурацию. Плагины тоже подходят, но только если вы уже используете их для общей технической чистки и не хотите трогать код темы.

Способ	Когда подходит	Минус
Код в `functions.php` или мини-плагине	Нужен быстрый и контролируемый вариант	Нужно помнить о теме или MU-плагине
Правило на сервере	Есть доступ к nginx/apache и нужен жёсткий запрет	Можно случайно перекрыть нужные интеграции
Плагин безопасности	Уже есть единый инструмент для hardening	Лишняя зависимость и риск конфликтов

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

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

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

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

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

Если цель — не просто отключить функцию, а вообще не принимать обращения к файлу, можно закрыть xmlrpc.php на уровне веб-сервера. Это полезно, когда сайт регулярно получает мусорный трафик именно на этот endpoint.

Для nginx обычно используют отдельное правило в конфигурации сайта:

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

Для Apache часто применяют правило в .htaccess:

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

Серверный вариант жёстче, но и риск выше: если позже понадобится Jetpack или удалённая публикация, доступ придётся возвращать на уровне веб-сервера.

Вариант 3: использовать плагин безопасности

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

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

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

Проверьте, используется ли Jetpack или внешний клиент публикации.
Выберите один способ отключения: код или сервер.
Внесите изменение на staging, если он есть.
Очистите кеш сайта и CDN, если они используются.
Проверьте доступ к /xmlrpc.php и рабочие сценарии админки.

Как проверить, что XML-RPC действительно отключён

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

Самый простой тест — открыть /xmlrpc.php в браузере или отправить запрос через curl. Если всё закрыто корректно, вы не должны видеть штатный ответ WordPress с сообщением о том, что XML-RPC сервер принимает только POST-запросы.

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

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

Что ещё стоит посмотреть после отключения

Не появились ли ошибки в логах PHP или веб-сервера.
Не сломался ли Jetpack, если он подключён.
Не изменилось ли поведение мобильного приложения WordPress.
Не остались ли старые правила кеша, которые маскируют результат.

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

Ошибка 1: отключили XML-RPC, не проверив Jetpack. Jetpack использует XML-RPC для части функций. Если он нужен, не блокируйте endpoint на сервере без теста.

Ошибка 2: правят functions.php активной темы. После обновления тема может перезаписаться, и защита исчезнет. Надёжнее использовать дочернюю тему или мини-плагин.

Ошибка 3: закрыли файл на сервере, но забыли про кеш. В результате кажется, что правило не работает. Очистите кеш страницы, объектный кеш и CDN, если он есть.

Ошибка 4: блокируют XML-RPC, когда проблема на самом деле в brute force на wp-login.php. Это разные точки входа. Если атака идёт через форму входа, дополнительно нужны ограничения на авторизацию, а не только запрет XML-RPC.

Безопасность и производительность: что имеет смысл сделать вместе с отключением

Если вы уже занимаетесь технической чисткой сайта, проверьте и соседние настройки. На практике полезно ограничить число попыток входа, включить нормальный кеш страниц, убрать лишние REST-эндпоинты только там, где это действительно оправдано, и следить за логами 404 и 403. Но не отключайте всё подряд ради «безопасности»: WordPress часто ломают именно чрезмерно агрессивные hardening-настройки.

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

Короткий чек-лист перед выкладкой на прод

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

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