Как отключить XML-RPC в WordPress и не сломать нужные интеграции

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

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

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

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

Типичный сценарий: в логах много запросов к xmlrpc.php, а в админке нет ни одного признака реального использования. В таком случае отключение — нормальная техническая мера, а не «перестраховка».

Что может сломаться после отключения

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

Диагностика: как понять, используется ли xmlrpc.php

Перед изменениями проверьте логи веб-сервера и поведение сайта. Если у вас есть доступ к access log, ищите обращения к /xmlrpc.php. Важно смотреть не только на факт запросов, но и на источник: если это ваши IP или известные интеграции, отключение нужно планировать аккуратно.

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

есть ли Jetpack;
используется ли мобильное приложение WordPress;
есть ли внешняя публикация через сторонний софт;
настроены ли старые интеграции с CMS, CRM или планировщиками публикаций.

Если список пустой, отключение обычно проходит без последствий.

Что выбрать: плагин, код или серверное правило

У каждого подхода свой уровень контроля. Для небольшого сайта достаточно серверного правила или небольшого кода в functions.php. Если нужен удобный интерфейс и сайт ведётся не разработчиком, можно использовать плагин безопасности. Ниже — короткое сравнение.

Подход	Плюсы	Минусы
Код в теме или mu-plugin	Прозрачно, без лишних зависимостей	Нужно аккуратно обновлять и не потерять при смене темы
Правило на сервере	Блокирует запросы до загрузки WordPress	Зависит от конфигурации nginx/apache
Плагин безопасности	Удобно для редактора или администратора без доступа к серверу	Добавляет ещё один слой логики и может конфликтовать с другими защитными плагинами

Пошаговое решение: как отключить XML-RPC через код

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

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

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

Если нужно не просто отключить функциональность, а ещё и отдать корректный HTTP-ответ на прямой запрос к файлу, используйте отдельное правило в .htaccess для Apache или конфигурацию nginx. Пример для Apache:

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

Для nginx обычно используют блокировку на уровне location. Конкретная конфигурация зависит от вашего шаблона, но логика одна: запрос к xmlrpc.php должен завершаться до передачи в PHP.

Если нужно оставить доступ только для одного сервиса

Иногда XML-RPC нужен, но только для одного внешнего клиента. Тогда лучше ограничить доступ по IP на уровне сервера. Это безопаснее, чем держать endpoint открытым для всех. На уровне WordPress такой сценарий реализовать сложнее и менее надёжно, потому что запрос уже дошёл до PHP.

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

Проверка должна быть не «на глаз», а по факту ответа сервера. Откройте /xmlrpc.php в браузере или выполните запрос через curl. Если доступ закрыт, вы должны увидеть отказ в доступе или другой явный признак блокировки, а не рабочую страницу WordPress.

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

Дальше проверьте, не сломались ли реальные сценарии:

попробуйте войти в мобильное приложение WordPress, если оно используется;
проверьте Jetpack;
сделайте тестовую публикацию из внешнего сервиса, если он есть;
посмотрите error log и access log после изменения.

Если после отключения в логах исчезли массовые обращения к xmlrpc.php, а нужные интеграции не пострадали, задача решена.

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

Отключили XML-RPC, не проверив Jetpack

Это самая частая история. Пользователь видит «лишнюю дыру» и сразу закрывает endpoint, а потом ломается синхронизация статистики или публикаций. Исправление простое: сначала инвентаризация интеграций, потом блокировка.

Использовали только плагин, но сервер всё равно принимает запросы

Некоторые плагины отключают функциональность на уровне WordPress, но запрос до PHP всё равно доходит. Для защиты от перебора это хуже, чем блокировка на веб-сервере. Если есть возможность, закрывайте xmlrpc.php на уровне nginx или Apache.

Сломали внешнюю публикацию и не поняли почему

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

Смешали отключение XML-RPC с отключением REST API

Это разные механизмы. REST API нужен многим современным плагинам и редактору блоков, поэтому отключать его «за компанию» нельзя без анализа последствий. Если цель — защита от brute force, достаточно закрыть XML-RPC и усилить авторизацию.

Практические советы по безопасности

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

ограничение попыток входа;
двухфакторную авторизацию для администраторов;
защиту /wp-login.php на уровне сервера или через WAF;
регулярный аудит активных плагинов;
отключение ненужных внешних интеграций.

Если вам нужен более широкий набор технических настроек для SEO, чистки дублей и снижения лишней нагрузки, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wp-1.ru&utm_medium=article&utm_campaign=otklyuchit-xmlrpc-i-zashchitit-wordpress-ot-bruteforce. Но даже с плагином принцип остаётся тем же: сначала понять, что используется, потом отключать.

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

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

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