XML-RPC в WordPress до сих пор встречается на живых сайтах, хотя большинству проектов он уже не нужен. Проблема в том, что его часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение WordPress, внешние сервисы публикации или старые интеграции. Поэтому правильный сценарий здесь не «вырубить всё», а сначала понять, используется ли endpoint /xmlrpc.php, и только потом закрывать доступ.
Когда XML-RPC действительно стоит отключать
Если сайт не использует внешнюю публикацию, старые мобильные клиенты WordPress, Jetpack в режиме, завязанном на XML-RPC, или сторонние сервисы, которые ходят именно через этот протокол, то endpoint чаще всего только создаёт лишнюю поверхность атаки. Его нередко используют для перебора паролей и pingback-атак. Но если у вас есть хотя бы один внешний клиент, отключение нужно делать аккуратно и с проверкой.
Что обычно ломается после отключения
Чаще всего проблемы проявляются не сразу. Пользователь жалуется, что «не публикуется из приложения», «не синхронизируется сервис», «не работает удалённая отправка постов». Это типичный признак того, что интеграция ходила через XML-RPC, а не через REST API.
Диагностика: используется ли xmlrpc.php на вашем сайте
Перед изменениями проверьте, есть ли реальные обращения к файлу xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный способ. Ищите запросы вида POST /xmlrpc.php. Если логов нет, можно временно посмотреть статистику в панели хостинга или через WAF/Cloudflare, если он подключён.
Полезно также проверить, не завязаны ли на XML-RPC плагины и внешние клиенты. Если сайт давно обслуживается только через админку WordPress и REST API, риск поломки минимален. Если же есть мобильные приложения, автопостинг или удалённые редакторы, сначала протестируйте отключение на staging-копии.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин безопасности | Быстро включить и откатить | Лишняя зависимость, не всегда нужен на постоянной основе |
| Код в теме или mu-plugin | Контроль без лишних плагинов | Нужно следить за обновлениями и местом размещения кода |
| Ограничение на уровне сервера | Самый жёсткий вариант | Можно случайно заблокировать нужные интеграции |
Пошаговое решение: как закрыть XML-RPC безопасно
Если вы уверены, что endpoint не нужен, самый практичный вариант — отключить его через код. Для этого лучше использовать mu-plugin, чтобы решение не зависело от активной темы.
Вариант 1: отключить через фильтр
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter('xmlrpc_enabled', '__return_false');Создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную. Такой код не требует активации в админке и работает сразу после загрузки WordPress.
Вариант 2: заблокировать сам файл xmlrpc.php на уровне WordPress
Если нужно не только отключить функциональность, но и отдать корректный ответ на запрос, можно добавить проверку в mu-plugin или обычный плагин. Это полезно, когда вы хотите явно закрыть доступ, но не ломать остальную логику сайта.
<?php
add_action('init', function () {
if (defined('XMLRPC_REQUEST') && XMLRPC_REQUEST) {
wp_die('XML-RPC disabled', 'Forbidden', ['response' => 403]);
}
});Этот вариант не заменяет серверную блокировку, но помогает быстро закрыть доступ на уровне WordPress. Для большинства сайтов этого достаточно, если нет жёстких требований по безопасности.
Вариант 3: ограничить доступ на сервере
Если вы управляете конфигурацией Nginx или Apache, можно закрыть xmlrpc.php ещё до загрузки WordPress. Это снижает нагрузку и убирает лишние PHP-запросы. Но такой способ стоит применять только если вы точно знаете, что endpoint нигде не нужен.
# Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache логика похожая, но синтаксис будет другим. Если доступ к конфигу ограничен, не пытайтесь имитировать серверную блокировку через .htaccess без понимания текущих правил — можно случайно задеть другие маршруты.
Проверка результата после внедрения
После отключения откройте https://ваш-домен/xmlrpc.php в браузере. Ожидаемое поведение зависит от способа блокировки: либо 403 Forbidden, либо сообщение WordPress о том, что XML-RPC отключён. Главное — не должен открываться рабочий endpoint с ответом, который позволяет удалённые вызовы.
Дальше проверьте реальные сценарии:
- публикация из внешнего клиента, если он у вас есть;
- синхронизация с сервисами автопостинга;
- работа мобильного приложения WordPress;
- отсутствие ошибок в логах после отключения.
Если после изменения сайт начал ругаться на интеграцию, не возвращайте XML-RPC целиком сразу. Сначала выясните, какой именно сервис его использует, и решите, можно ли перевести его на REST API или другой способ авторизации.
Частые ошибки и как их исправить
Отключили XML-RPC в плагине, а потом обновление его сняло
Так бывает, если решение было завязано на обычный плагин, который случайно деактивировали или удалили. Для системной защиты лучше использовать mu-plugin или серверный уровень.
Закрыли endpoint, но забыли про внешние интеграции
Если сервис перестал публиковать записи, проверьте его документацию. Некоторые старые интеграции до сих пор используют XML-RPC по умолчанию. В таком случае безопаснее сначала перевести их на REST API или отключить только те методы, которые реально не нужны.
Сделали блокировку на сервере и получили ошибки в других правилах
Частая причина — конфликт с уже существующими rewrite-правилами или неверное место вставки в конфиге. Если после правки конфигурации сайт начал отдавать 500, откатите изменения и проверьте синтаксис отдельно.
Практические советы по безопасности и производительности
Если цель — не просто закрыть XML-RPC, а уменьшить шум от атак, не ограничивайтесь одним действием. Проверьте, не открыт ли у вас лишний доступ к админке, не используются ли слабые пароли, включена ли двухфакторная аутентификация для администраторов. XML-RPC часто становится только одной из точек входа.
С точки зрения производительности отключение endpoint полезно ещё и тем, что убирает ненужные PHP-запросы. Это не магическая оптимизация, но на сайтах с постоянным сканированием ботов разница заметна в логах и в общей нагрузке на сервер.
Если вам нужен более широкий набор технических настроек для чистки дублей, SEO-правок и отключения лишних функций, посмотрите Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, что именно он меняет и как это проверить вручную.
Что должно получиться в итоге
После корректного отключения xmlrpc.php не отвечает как рабочий endpoint, внешние интеграции не ломаются, если они не завязаны на XML-RPC, а в логах исчезают лишние обращения к этому файлу. Если что-то перестало работать, значит, у вас есть реальная зависимость, и её нужно либо заменить, либо оставить XML-RPC включённым точечно, а не отключать вслепую.