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

Автор: Маргарита Ларионова | Опубликовано: 20.08.2026

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

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

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

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

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

Что проверить перед отключением

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

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

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

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

Быстрая проверка через браузер и HTTP-ответ

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

Если хотите проверить именно доступность снаружи, используйте:

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

Для безопасного отключения важно не просто «спрятать» файл, а понять, кто и зачем его использует.

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

Есть три рабочих подхода: через код, через сервер и через плагин безопасности. Для большинства проектов удобнее начать с кода в теме или в небольшом mu-plugin, потому что это прозрачно и легко откатить.

Способ	Плюсы	Минусы
Код в WordPress	Легко контролировать, можно отключать выборочно	Не защищает файл на уровне сервера
Правило на сервере	Режет доступ раньше WordPress, меньше лишней нагрузки	Нужно аккуратно править конфиг
Плагин безопасности	Быстро включить без кода	Зависимость от плагина и его настроек

Вариант 1: отключить XML-RPC через WordPress

Если вам нужно именно запретить использование XML-RPC внутри WordPress, добавьте фильтр xmlrpc_enabled. Это не удаляет файл, но WordPress перестаёт обслуживать XML-RPC-запросы.

add_filter( 'xmlrpc_enabled', '__return_false' );

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

Пример mu-plugin:

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

add_filter( 'xmlrpc_enabled', '__return_false' );

Вариант 2: закрыть доступ на уровне сервера

Если нужен более жёсткий вариант, блокируйте запросы на веб-сервере. Это особенно полезно, когда сайт получает много мусорных обращений к xmlrpc.php.

Для Apache можно использовать правило в .htaccess:

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

Для Nginx обычно добавляют отдельное правило в конфигурацию сайта:

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

Если вы не уверены, где именно править конфиг, не экспериментируйте на боевом сайте. Сначала проверьте изменения на staging-копии.

Вариант 3: использовать плагин безопасности

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

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

После отключения проверьте не только сам xmlrpc.php, но и сценарии, которые могли от него зависеть.

Откройте /xmlrpc.php в браузере и убедитесь, что доступ закрыт или запрос не обслуживается WordPress.
Проверьте, не появились ли ошибки в логах сервера и PHP-логах.
Если используются внешние клиенты или интеграции, протестируйте публикацию и обновление записи.
Проверьте мобильное приложение WordPress, если редакторы им пользуются.

Дополнительно можно сделать простой тест через curl:

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

Если вы блокировали доступ на уровне WordPress, ответ может быть 403 или иной контролируемый отказ. Если закрывали на сервере, важно увидеть именно отказ до загрузки WordPress, а не обычный ответ приложения.

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

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

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

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

Чаще всего правило не применяется из-за особенностей конфигурации Apache или потому, что сайт работает на Nginx за прокси. В таком случае править нужно именно тот уровень, который реально обслуживает запрос.

Появились ошибки после установки плагина безопасности

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

Отключили XML-RPC, но нагрузка не снизилась

Значит, основной источник нагрузки был не в XML-RPC. Ищите другие точки: wp-login.php, REST API, тяжёлые запросы к базе, неэффективные плагины или ботов, которые бьют по другим URL.

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

Если вы отключаете XML-RPC ради защиты, не останавливайтесь на одном файле. Проверьте ещё несколько вещей:

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

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

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