Как отключить XML-RPC в WordPress через .htaccess и PHP без срыва интеграций

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

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

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

Проверить, нужен ли он вам, можно быстро:

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

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

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

Диагностика: кто обращается к xmlrpc.php

Перед изменениями полезно посмотреть, есть ли вообще живой трафик. Самый простой способ — проверить access-логи веб-сервера. Если доступа к логам нет, можно временно добавить минимальную диагностику на стороне WordPress и посмотреть, появляются ли запросы в течение нескольких дней.

<?php
// functions.php темы или mu-plugin
add_action('init', function () {
    if (isset($_SERVER['REQUEST_URI']) && str_contains($_SERVER['REQUEST_URI'], 'xmlrpc.php')) {
        error_log('XML-RPC request from ' . ($_SERVER['REMOTE_ADDR'] ?? 'unknown'));
    }
});

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

Пошаговое решение: два рабочих способа

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

Способ	Что делает	Плюсы	Минусы
.htaccess	Режет доступ к файлу до загрузки WordPress	Меньше нагрузка, запросы не доходят до PHP	Работает только на Apache/LiteSpeed
PHP-хук	Отключает XML-RPC на уровне WordPress	Подходит для любого хостинга	Запрос уже доходит до WordPress

Вариант 1: блокировка через .htaccess

Если сайт работает на Apache или LiteSpeed, можно закрыть xmlrpc.php на уровне веб-сервера. Это самый дешёвый по ресурсам вариант: запрос даже не попадёт в WordPress.

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

Добавляйте этот блок в корневой .htaccess рядом с правилами WordPress. Если у вас старый Apache 2.2, синтаксис будет другим, но на живых проектах сейчас чаще встречается именно Require all denied.

Вариант 2: отключение через PHP

Если у вас Nginx без .htaccess или вы хотите отключить XML-RPC из кода, используйте фильтр xmlrpc_enabled. Это штатный хук WordPress, он не требует сторонних плагинов и работает предсказуемо.

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

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

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

Когда лучше оставить только один способ

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

Как не сломать нужные интеграции

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

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

Проверка результата после внедрения

После изменения нужно убедиться, что файл действительно недоступен и не отдаёт рабочий ответ. Проверка простая: откройте /xmlrpc.php в браузере или выполните запрос из консоли. В норме вы должны увидеть отказ в доступе или пустой ответ в зависимости от способа блокировки.

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

Если блокировка через .htaccess настроена правильно, сервер должен вернуть 403 Forbidden. Если вы отключали XML-RPC через PHP, ответ может отличаться, но сам функционал должен быть недоступен для внешнего использования.

Дополнительно проверьте:

• вход в админку работает как обычно;
• публикация записей из редактора не сломалась;
• REST API отвечает на запросы;
• в логах больше нет обращений к xmlrpc.php от внешних IP.

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

Правило добавили не туда

Если блок в .htaccess стоит внутри чужого условия или после некорректного правила переписывания, он может не сработать. Для проверки временно вынесите его выше стандартного блока WordPress и повторите запрос к xmlrpc.php.

Отключили XML-RPC, но забыли про старый сервис

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

Путают XML-RPC и REST API

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

Ожидают, что блокировка в WordPress остановит весь трафик

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

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

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

• не отключайте XML-RPC вслепую на проектах с внешними интеграциями;
• храните изменения в mu-plugin или в конфигурации сервера, а не в случайной теме;
• после обновления сайта повторно проверяйте доступ к xmlrpc.php;
• если используете плагин безопасности, убедитесь, что он не дублирует и не конфликтует с вашим правилом.

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

Короткий чек-лист перед публикацией изменений

• Проверили, используются ли мобильное приложение и внешние клиенты.
• Посмотрели логи на обращения к xmlrpc.php.
• Выбрали один основной способ блокировки: .htaccess или PHP.
• Проверили ответ curl -I или через браузер.
• Убедились, что REST API и вход в админку работают.
• Сохранили правило в месте, которое не потеряется после обновления темы.

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