XML-RPC в WordPress часто отключают «на всякий случай», но это не всегда безопасно для рабочего сайта. Если у вас подключены мобильное приложение WordPress, внешние сервисы публикации, Jetpack или старые интеграции, простое выключение может обернуться ошибками авторизации и неотправленными публикациями. Поэтому сначала нужно понять, используется ли endpoint /xmlrpc.php вообще, а уже потом выбирать способ отключения.
Когда XML-RPC мешает и зачем его отключают
На практике XML-RPC чаще всего отключают из-за двух причин: лишняя поверхность атаки и ненужные запросы к сайту. Этот файл регулярно сканируют боты, а в логах можно увидеть массовые обращения к xmlrpc.php с попытками перебора паролей или pingback-атак. Если сайт работает только через админку WordPress и не использует внешние клиенты, XML-RPC обычно не нужен.
Но есть и обратная сторона. Через XML-RPC могут работать:
- мобильное приложение WordPress;
- Jetpack и некоторые его функции;
- внешние редакторы и сервисы автопостинга;
- старые интеграции, которые не переведены на REST API.
Диагностика: используется ли XML-RPC сейчас
Перед отключением проверьте, есть ли реальные обращения к endpoint. Самый простой способ — посмотреть access log веб-сервера или логи в панели хостинга. Ищите запросы к /xmlrpc.php и обратите внимание, откуда они приходят: это может быть ваш же сервис, а может быть бот.
Быстрая проверка через браузер и curl
Если открыть https://example.com/xmlrpc.php в браузере, WordPress обычно отвечает сообщением о том, что XML-RPC server accepts POST requests only. Это не значит, что функция нужна, но подтверждает, что endpoint доступен извне.
curl -I https://example.com/xmlrpc.phpВ ответе вы увидите HTTP-статус. Если после отключения всё настроено правильно, доступ к файлу должен закрываться или возвращать отказ в зависимости от выбранного способа.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Минус |
|---|---|---|
| Плагин | Если нужно быстро отключить без правки кода | Ещё один плагин в системе |
| Код в теме или mu-plugin | Если нужен контролируемый и прозрачный вариант | Нужно аккуратно разместить код |
| Правило на сервере | Если нужен жёсткий запрет ещё до загрузки WordPress | Зависит от nginx/Apache и доступа к конфигу |
Пошаговое решение через код
Если задача — отключить XML-RPC без лишних зависимостей, удобнее всего добавить фильтр в functions.php дочерней темы или, что лучше, в небольшой mu-plugin. Так код не потеряется при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает XML-RPC на уровне WordPress. В большинстве случаев этого достаточно, чтобы запросы к endpoint перестали обрабатываться как раньше. Если у вас есть интеграции, проверьте их отдельно до выката на боевой сайт.
Если нужно заблокировать доступ точечно
Иногда полезно не просто выключить XML-RPC, а вернуть 403 для самого файла. Это особенно уместно, если боты продолжают долбить endpoint и вы хотите отсечь запросы раньше загрузки WordPress. Для Apache можно использовать .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой вариант жёстче, чем фильтр WordPress, и подходит не всем. Если вы используете Jetpack или мобильное приложение, сначала убедитесь, что они не завязаны на XML-RPC.
Отключение через плагин: когда это оправдано
Плагин удобен, если вы не хотите трогать код или серверные настройки. Но для production-сайта это не всегда лучший выбор: лишний плагин ради одной функции — это ещё одна точка обновления и потенциальный конфликт. Если у вас уже установлен плагин для технической чистки сайта, например Clearfy Pro, проверьте, есть ли в нём готовая опция отключения XML-RPC и других ненужных возможностей WordPress. Это практичнее, чем ставить отдельный однофункциональный инструмент.
Важно не путать «отключить XML-RPC» и «запретить все внешние запросы». REST API и другие механизмы WordPress при этом должны остаться рабочими, если вы их используете.
Проверка результата после внедрения
После отключения проверьте не только сам endpoint, но и реальные сценарии сайта. Это особенно важно, если на сайте есть внешние сервисы публикации или мобильные клиенты.
- Откройте
/xmlrpc.phpв браузере и убедитесь, что доступ закрыт или обработка отключена. - Проверьте логи веб-сервера: новые обращения к endpoint не должны приводить к успешной обработке.
- Если используете Jetpack, проверьте его статус в админке WordPress.
- Попробуйте выполнить публикацию из внешнего клиента, если он у вас есть в рабочем процессе.
Для более технической проверки можно снова использовать curl и посмотреть код ответа после изменений:
curl -I https://example.com/xmlrpc.phpЕсли вы закрывали доступ на уровне сервера, ожидаемое поведение — отказ в доступе. Если использовали только фильтр WordPress, ответ может отличаться в зависимости от конфигурации, но обработка XML-RPC должна быть недоступна для обычного использования.
Частые ошибки и как их исправить
Отключили XML-RPC, а перестал работать Jetpack
Это типичный сценарий. Jetpack в некоторых конфигурациях использует XML-RPC для связи с сайтом. Решение простое: либо возвращаете XML-RPC, либо переводите интеграцию на другой способ, если он поддерживается вашей конфигурацией.
Добавили код в родительскую тему и потеряли его после обновления
Если код лежит в functions.php родительской темы, обновление темы его затрёт. Для таких правок лучше использовать дочернюю тему или mu-plugin.
Поставили плагин, который блокирует слишком много
Некоторые плагины безопасности могут отключать не только XML-RPC, но и другие API-методы, из-за чего ломаются интеграции. Если после установки плагина начались странные ошибки авторизации или публикации, проверьте его настройки по пунктам, а не отключайте всё подряд.
Закрыли XML-RPC на сервере, но забыли про тестовый домен
Если у вас есть staging-окружение, правило нужно повторить и там. Иначе вы получите расхождение между тестом и продом: на одном сайте интеграция работает, на другом — нет.
Что ещё стоит сделать вместе с отключением XML-RPC
Если цель — уменьшить мусорный трафик и поверхность атаки, одного XML-RPC обычно мало. Имеет смысл проверить и другие технические точки WordPress: лишние архивы, дубли, ненужные эмодзи, доступность REST API для публичных данных, а также общую нагрузку от плагинов. Но каждое такое изменение нужно тестировать отдельно, чтобы не сломать нужные сценарии.
Для сайтов, где важна техническая чистка без постоянной ручной правки, удобнее держать под рукой инструмент, который закрывает несколько типовых проблем сразу. В экосистеме WPShop для этого есть Clearfy Pro: он помогает отключать ненужные функции WordPress, убирать дубли и наводить порядок в технических настройках. Если вам нужен именно такой сценарий, это экономит время по сравнению с набором разрозненных решений.
Главный критерий простой: если после отключения XML-RPC сайт продолжает нормально публиковать записи, работать с нужными интеграциями и не отдаёт endpoint наружу без необходимости, значит решение внедрено корректно. Если хотя бы один рабочий сценарий сломался, откатывайте изменение и ищите, какая именно интеграция была завязана на XML-RPC.