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

Автор: Артем Фомин | Опубликовано: 30.08.2026

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

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

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

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

Быстрая диагностика проблемы

Перед изменениями ответьте на три вопроса:

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

Если вы не уверены, временно посмотрите access log и error log. На Apache и Nginx это самый надёжный способ понять, кто и как обращается к endpoint. Для сайтов на общем хостинге иногда достаточно панели статистики или логов в кабинете.

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

Способ зависит от того, что у вас под рукой: код темы, mu-plugin, конфигурация сервера или плагин. Если нужен контролируемый и обратимый вариант, лучше начать с кода. Если задача — закрыть endpoint на уровне веб-сервера, это тоже нормально, но там выше риск ошибиться в конфиге.

Способ	Плюсы	Минусы
Код в mu-plugin	Не зависит от темы, легко откатить	Нужен доступ к файлам
.htaccess / nginx	Закрывает запросы раньше WordPress	Можно задеть другие правила
Плагин безопасности	Быстро включить без кода	Лишняя зависимость от плагина

Вариант 1. Отключить XML-RPC через mu-plugin

Это самый практичный способ, если вы не хотите привязываться к теме. Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

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

Вариант 2. Закрыть доступ на уровне Nginx

Если сайт работает на Nginx, можно отрезать запросы к xmlrpc.php до передачи в PHP. Это полезно, когда endpoint атакуют брутфорсом и вы хотите снизить нагрузку на PHP-FPM.

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

После правки конфигурации обязательно проверьте синтаксис и перезагрузите Nginx. Не вносите это правило вслепую в общий блок location /, иначе можно случайно задеть другие маршруты.

Вариант 3. Закрыть через .htaccess на Apache

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

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

Если у вас старый стек с Apache 2.2, синтаксис будет другим, но в современных установках лучше ориентироваться именно на Require all denied. После изменения проверьте, что файл xmlrpc.php действительно отдаёт 403, а обычные страницы сайта открываются без ошибок.

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

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

Откройте https://ваш-домен.ru/xmlrpc.php в браузере или через curl.
Проверьте код ответа: ожидаемо это должен быть 403 или другой отказ, а не обычный XML-RPC response.
Если у вас есть внешняя интеграция, попробуйте выполнить её тестовый запрос.
Посмотрите логи веб-сервера и PHP-FPM: новых ошибок быть не должно.

Пример проверки через curl:

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

Если вы закрывали endpoint на уровне сервера, в ответе должен быть отказ ещё до WordPress. Если отключали через фильтр, WordPress может отвечать своим сообщением об ошибке или отказе в доступе — это тоже нормально, если endpoint больше не используется.

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

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

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

Закрыли не тот блок в Nginx

Если правило вставили в общий location без проверки, можно получить неожиданные 404 или 403 на других URL. Исправление — вынести правило в точное совпадение location = /xmlrpc.php и проверить конфиг командой nginx -t перед перезагрузкой.

Поставили плагин безопасности и забыли, что он уже делает это сам

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

Что делать, если XML-RPC всё-таки нужен

Если вы используете внешнюю публикацию или старую интеграцию, не отключайте endpoint полностью. Вместо этого:

ограничьте доступ по IP, если сервис работает с фиксированного адреса;
проверьте, можно ли заменить XML-RPC на REST API;
усильте защиту входа: сложные пароли, 2FA, ограничение попыток логина;
убедитесь, что на сервере есть базовая защита от брутфорса и rate limiting.

Для сайтов, где важна общая техническая чистка и снижение лишней поверхности атаки, полезно смотреть не только на XML-RPC, но и на дубли, автогенерируемые архивы, лишние скрипты и мета-теги. В таких задачах часто помогает комплексная настройка через плагины вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy.

Мини-чек-лист перед отключением

Проверили, используются ли внешние клиенты и интеграции.
Посмотрели логи на обращения к /xmlrpc.php.
Выбрали один способ отключения: код, сервер или плагин.
Протестировали curl -I и реальный рабочий сценарий.
Убедились, что обычные страницы и админка работают без ошибок.

Если нужен безопасный и обратимый вариант, начинайте с mu-plugin. Если важна защита от лишней нагрузки на сервер, закрывайте endpoint на уровне Nginx или Apache. Главное — не отключать XML-RPC «на всякий случай» без проверки зависимостей: в WordPress такие изменения почти всегда упираются не в сам код, а в забытые интеграции.