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

Автор: Степан Жуков | Опубликовано: 29.09.2026

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

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

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

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

Если есть сомнения, сначала проверьте логи веб-сервера или WAF. Частые запросы к xmlrpc.php ещё не доказывают, что ваш сайт реально использует этот механизм — чаще это просто автоматические сканеры.

Диагностика: используется ли XML-RPC сейчас

Самый практичный способ — проверить, не завязаны ли на него ваши рабочие сценарии. Начните с простых вопросов:

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

Если нужно быстро проверить endpoint, откройте https://example.com/xmlrpc.php. Для живого сайта нормальный ответ обычно выглядит как сообщение о том, что XML-RPC server accepts POST requests only. Это не ошибка и не признак проблемы — просто подтверждение, что файл доступен.

Более полезная проверка — посмотреть, не вызываются ли методы XML-RPC в логах. Если в access log есть регулярные POST-запросы к /xmlrpc.php от ваших же сервисов, отключать его без замены нельзя.

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

Вариант 1. Через код в functions.php или mu-plugin

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

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

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

Вариант 2. Через .htaccess на Apache

Если сайт работает на Apache и вы хотите отрезать запросы ещё до загрузки WordPress, можно добавить правило в .htaccess:

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

Это жёстче, чем фильтр в WordPress. Такой способ удобен, если вы уверены, что XML-RPC нигде не нужен. Но если позже выяснится, что какой-то сервис всё же использует его, придётся возвращать доступ на уровне сервера.

Вариант 3. Через Nginx

На Nginx блокировка делается в конфигурации сайта:

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

После правки конфигурации не забудьте проверить синтаксис и перезагрузить Nginx. Этот способ хорош тем, что запросы не доходят до PHP вообще.

Вариант 4. Плагином

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

Подход	Где отключает	Плюс	Минус
Фильтр `xmlrpc_enabled`	WordPress	Просто откатить	Запрос всё ещё доходит до PHP
.htaccess	Apache	Режет раньше WordPress	Только для Apache
Nginx location	Nginx	Не грузит PHP	Нужен доступ к конфигу
Плагин	WordPress	Без кода	Лишняя зависимость

Пошаговое решение без риска сломать интеграции

Если сайт рабочий, не отключайте XML-RPC сразу на бою. Надёжнее идти так:

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

Если у вас есть доступ только к WordPress, начните с кода. Если есть доступ к Nginx или Apache, лучше закрыть endpoint на уровне сервера и оставить WordPress без лишней нагрузки.

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

Проверка должна быть не формальной, а практической. После внедрения сделайте три теста:

откройте /xmlrpc.php в браузере — если блокировка на сервере, вы увидите отказ в доступе;
попробуйте отправить POST-запрос к endpoint через curl;
проверьте, не перестали ли работать ваши внешние сервисы публикации.

Пример запроса:

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

Если XML-RPC отключён на уровне WordPress, ответ может отличаться от серверной блокировки. Важен не конкретный текст, а сам факт: endpoint больше не принимает рабочие XML-RPC-запросы.

Дополнительно посмотрите логи доступа через 1–2 дня. Если запросы к xmlrpc.php продолжают приходить, но теперь получают 403 или другой отказ, значит блокировка реально работает.

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

Отключили XML-RPC, а потом перестал работать Jetpack

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

Закрыли файл на сервере, но WordPress всё ещё отвечает

Так бывает, если правило добавили не в тот виртуальный хост или не перезагрузили Nginx. На Apache частая ошибка — правило в неверном месте .htaccess. Проверьте, что конфиг реально применяется к нужному домену.

Использовали плагин, а он только спрятал проблему

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

Сломали публикацию из внешнего клиента

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

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

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

не нужен ли вам wp-admin только по VPN или по IP;
нет ли лишних открытых endpoint-ов в REST API;
не стоит ли ограничить попытки входа;
не используются ли старые плагины, которые тянут за собой уязвимости.

Если нужен более широкий набор технических настроек без ручной сборки из десятка плагинов, иногда удобнее использовать Clearfy Pro как набор точечных оптимизаций и чистки сайта, но только если его функции реально закрывают ваши задачи, а не дублируют уже настроенные меры.

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