XML-RPC в WordPress часто держат включённым «на всякий случай», а потом удивляются лишним запросам, шуму в логах и лишней поверхности атаки. На небольшом сайте это может быть незаметно, но если у вас нет старого мобильного клиента, Jetpack, внешнего редактора или интеграции, которой действительно нужен xmlrpc.php, его обычно проще отключить.
Ниже — не абстрактный совет, а рабочий сценарий: как понять, нужен ли XML-RPC именно вам, как отключить его безопасно, чем отличается блокировка на уровне WordPress от блокировки на уровне сервера и как проверить, что после правки ничего не отвалилось.
Когда XML-RPC реально нужен
Сначала стоит отделить «исторически включено» от «используется». XML-RPC нужен не каждому сайту. Чаще всего он нужен, если вы:
- используете Jetpack и часть функций завязана на удалённое соединение;
- публикуете записи через старые мобильные приложения или внешние редакторы;
- подключаете сторонние сервисы, которые до сих пор работают через XML-RPC;
- используете интеграции, где явно указан endpoint
/xmlrpc.php.
Если ничего из этого не используется, отключение обычно не ломает обычную работу сайта: вход в админку, REST API, редактор блоков и публикацию через панель WordPress это не затрагивает.
Диагностика: как понять, что XML-RPC вам не нужен
Самый надёжный способ — посмотреть, обращается ли кто-то к xmlrpc.php. Если у вас есть доступ к логам веб-сервера, ищите запросы к этому файлу. На уровне nginx это может выглядеть как обычные строки access log с путём /xmlrpc.php. На хостинге без доступа к логам можно временно поставить правило блокировки и посмотреть, не начнут ли жаловаться интеграции или редакторы.
Ещё один практический признак: если в админке нет ни одного сценария, где вы осознанно используете удалённую публикацию, а в списке подключённых сервисов нет старых клиентов, XML-RPC чаще всего просто не нужен.
Что проверить перед отключением
- используется ли Jetpack и какие его модули реально нужны;
- есть ли внешние редакторы или мобильные приложения для публикации;
- есть ли интеграции, которые отправляют запросы на
xmlrpc.php; - не завязаны ли на XML-RPC старые автоматизации, которые уже забыли в документации.
Как отключить XML-RPC в WordPress через код
Если нужен именно WordPress-уровень, самый простой вариант — отключить XML-RPC фильтром. Это удобно, когда вы хотите оставить серверную конфигурацию без изменений и быстро откатить правку.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы, но для технической правки надёжнее вынести его в маленький mu-plugin. Тогда он не исчезнет после обновления темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант отключает сам механизм на уровне WordPress. При этом сам файл xmlrpc.php может оставаться доступным на сервере и отвечать, но WordPress уже не будет обрабатывать XML-RPC-запросы как раньше.
Как заблокировать xmlrpc.php на уровне сервера
Если цель — не только отключить функцию, но и убрать лишний входной пункт для ботов, лучше дополнительно закрыть доступ на уровне веб-сервера. Это уже не замена WordPress-фильтру, а более жёсткая защита.
nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такое правило блокирует прямые запросы к файлу. Если у вас несколько сайтов на одном сервере, правило нужно добавить только в конфигурацию нужного виртуального хоста.
Apache
<Files xmlrpc.php>
Require all denied
</Files>Для Apache это стандартный способ закрыть доступ к конкретному файлу. Если сайт работает через .htaccess, правило можно разместить там, но важно убедиться, что хостинг разрешает такие директивы.
Что выбрать: плагин, код или сервер
| Способ | Плюсы | Минусы | Когда подходит |
|---|---|---|---|
Фильтр xmlrpc_enabled | Быстро, просто откатить | Файл остаётся доступным | Нужно мягко отключить функцию |
| Блокировка на сервере | Жёстче, меньше шума в логах | Нужен доступ к конфигу | Хотите закрыть endpoint полностью |
| Плагин безопасности | Удобно для неразработчика | Лишняя зависимость | Нужно управлять защитой через админку |
Если у вас уже стоит плагин безопасности и в нём есть отдельная опция отключения XML-RPC, это тоже рабочий путь. Но для точечной задачи код или серверное правило обычно прозрачнее: вы точно знаете, что именно изменили.
Проверка результата после внедрения
После отключения важно не ограничиваться «в админке всё открывается». Нужно проверить сам endpoint.
- Откройте
https://ваш-домен/xmlrpc.phpв браузере. - Если блокировка серверная, вы должны увидеть отказ в доступе или 403.
- Если отключение через WordPress, ответ может отличаться в зависимости от конфигурации, но XML-RPC-запросы должны перестать работать.
- Проверьте, не появились ли ошибки в логах интеграций, которые раньше использовали этот endpoint.
Дополнительно можно сделать простой POST-запрос и посмотреть ответ. Например, через curl:
curl -i -X POST https://example.com/xmlrpc.phpЕсли endpoint действительно закрыт, вы не должны получать рабочий XML-RPC-ответ. Для серверной блокировки это обычно будет 403 или аналогичный отказ.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал подключаться
Это ожидаемо, если вы используете функции Jetpack, которым нужен удалённый доступ. Решение простое: либо вернуть XML-RPC, либо пересмотреть, какие модули Jetpack вам действительно нужны. Не стоит отключать endpoint, не проверив зависимые сервисы.
Сделали правило в nginx, но файл всё равно отвечает
Частая причина — правило добавили не в тот server-блок или конфигурация не была перезагружена. Проверьте, что правило относится именно к нужному домену, затем выполните reload конфигурации и повторите тест.
Добавили код в тему, а после обновления он пропал
Это типичная ошибка при правках в functions.php родительской темы. Для постоянной технической настройки лучше использовать дочернюю тему или mu-plugin.
Отключили XML-RPC, но в логах всё равно идут запросы
Это не значит, что защита не работает. Боты часто продолжают стучаться в xmlrpc.php, даже если endpoint закрыт. Важно смотреть не на сам факт запросов, а на то, что они больше не обрабатываются как рабочие.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC — не универсальная защита, а один из шагов. Если вы уже чистите поверхность атаки, имеет смысл проверить и другие вещи: неиспользуемые плагины, лишние REST-эндпоинты, старые тестовые страницы, открытые авторские архивы, дубли архивов и служебные страницы. Для таких задач часто удобнее использовать точечную настройку, а не ставить тяжёлый комбайн ради одной функции.
Если вам нужен более широкий набор инструментов для SEO- и технической чистки сайта, можно посмотреть на Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае полезно понимать, что именно вы отключаете и зачем, а не полагаться только на кнопку в интерфейсе.
Мини-чек-лист перед публикацией изменений
- Проверили, не нужен ли XML-RPC Jetpack или внешним сервисам.
- Выбрали способ отключения: код или сервер.
- Добавили правило в правильное место.
- Проверили ответ
/xmlrpc.phpвручную. - Посмотрели логи и убедились, что нет ошибок у зависимых интеграций.
- Сохранили способ быстрого отката.
Если задача стоит именно как «закрыть лишний технический вход и не сломать сайт», XML-RPC — хороший кандидат на отключение. Главное здесь не сам факт блокировки, а аккуратная проверка зависимостей до и после правки.