XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать Jetpack, мобильное приложение или внешняя публикация через сторонний сервис. Проблема в том, что у этого механизма нет одного единственного сценария использования: он нужен не всем, но если нужен — ломать его вслепую нельзя.
Ниже — практический разбор: как понять, используется ли XML-RPC на сайте, как отключить только лишнее, как оставить рабочие интеграции и как проверить, что после изменений ничего не отвалилось.
Когда XML-RPC действительно мешает
На большинстве обычных сайтов XML-RPC не нужен. Его часто отключают из-за попыток брутфорса, лишних запросов к /xmlrpc.php и старых интеграций, которые давно заменены REST API. Но если у вас подключены Jetpack, мобильное приложение WordPress или сервисы публикации через XML-RPC, полное отключение может создать проблемы сразу в нескольких местах.
Типичный сценарий выглядит так: в логах много запросов к xmlrpc.php, владелец ставит жесткую блокировку через .htaccess или код, а потом замечает, что перестали синхронизироваться статистика Jetpack, отложенные публикации или удаленная публикация записей.
Что именно может использовать XML-RPC
- Jetpack и связанные с ним функции подключения к WordPress.com.
- Мобильное приложение WordPress.
- Сторонние клиенты для публикации и редактирования записей.
- Некоторые старые интеграции с внешними сервисами.
Диагностика: используется ли XML-RPC на вашем сайте
Перед отключением проверьте не только сам файл xmlrpc.php, но и реальные зависимости. Самый простой путь — посмотреть, есть ли обращения к нему в логах веб-сервера и не завязаны ли на него подключенные сервисы.
Проверка по логам и поведению сайта
- Откройте access log и найдите запросы к
/xmlrpc.php. - Проверьте, есть ли в админке активный Jetpack и не показывает ли он ошибки соединения.
- Если вы публикуете записи из мобильного приложения WordPress, сделайте тестовую синхронизацию до изменений.
- Посмотрите, не использует ли сайт сторонний сервис автопостинга или мониторинга, который работает через XML-RPC.
Если доступа к логам нет, можно хотя бы проверить ответ файла напрямую. Сам по себе код ответа еще не доказывает, что XML-RPC нужен, но помогает понять, открыт ли он сейчас.
curl -I https://example.com/xmlrpc.phpЕсли сервер отвечает 200 или 405, файл доступен. Если вы уже закрывали его, может быть 403 или 404. Но повторюсь: важнее не статус, а наличие зависимостей.
Как отключить XML-RPC без лишнего риска
Есть три рабочих подхода: отключение через код, блокировка на уровне сервера и точечное ограничение вместо полного запрета. Для обычного сайта чаще всего достаточно кода в теме или в небольшом mu-plugin. Для сайтов с интеграциями лучше сначала ограничить доступ, а не рубить всё сразу.
| Способ | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
| Код в WordPress | Просто откатить, не зависит от сервера | Файл WordPress все равно загружается | Если нужен быстрый и управляемый вариант |
| .htaccess / nginx | Ранний отказ, меньше лишней нагрузки | Можно сломать нужные интеграции | Если XML-RPC точно не нужен |
| Точечное ограничение | Сохраняет нужные сценарии | Требует понимания, кто именно обращается | Если есть Jetpack или внешние клиенты |
Вариант 1: отключить XML-RPC через код
Если вы хотите убрать XML-RPC на уровне WordPress, используйте фильтр xmlrpc_enabled. Это безопаснее, чем править ядро или удалять файл.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы, но для технических правок надежнее вынести его в небольшой mu-plugin. Тогда он не исчезнет после обновления темы.
Вариант 2: блокировать файл на уровне сервера
Если XML-RPC точно не нужен, можно закрыть доступ к xmlrpc.php на уровне веб-сервера. Для Apache это часто делают через .htaccess.
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика будет другой, но смысл тот же: вернуть 403 на запросы к этому файлу. Такой подход уменьшает количество лишних обращений еще до загрузки WordPress.
Вариант 3: оставить только нужные интеграции
Если на сайте есть Jetpack или другой сервис, который использует XML-RPC, не отключайте его вслепую. Сначала выясните, что именно обращается к файлу, и только потом решайте: либо переводите интеграцию на другой способ, либо оставляете XML-RPC включенным и усиливаете защиту другими методами.
На практике это означает:
- проверить, какие сервисы завязаны на XML-RPC;
- ограничить доступ по IP, если источник запросов известен;
- добавить защиту от брутфорса на уровне WAF или сервера;
- не отключать XML-RPC только ради «чистоты», если он реально используется.
Пошаговое решение для обычного сайта
Если у вас обычный корпоративный сайт, блог или контентный проект без внешних публикаций и мобильного клиента, можно действовать так:
- Проверьте, не используется ли Jetpack и не завязаны ли на XML-RPC сторонние сервисы.
- Сделайте резервную копию файлов и базы.
- Добавьте отключение через
xmlrpc_enabledили блокировку на сервере. - Очистите кеш, если он есть на сайте, на хостинге или в CDN.
- Проверьте ответ
/xmlrpc.phpи протестируйте админку.
Если вы не уверены, начните с кодового варианта. Его проще откатить, чем править правила веб-сервера, особенно если доступ к конфигурации ограничен.
Как проверить, что решение сработало
После внедрения важно проверить не только сам файл, но и связанные функции. Иначе можно получить ложное ощущение безопасности: XML-RPC вроде бы закрыт, а Jetpack уже потерял соединение.
Минимальный чек-лист проверки
- Откройте
https://example.com/xmlrpc.phpв браузере или черезcurl. - Убедитесь, что ответ соответствует выбранному способу блокировки:
403,404или отключение на уровне WordPress. - Проверьте, не появились ли ошибки в Jetpack, если он установлен.
- Попробуйте выполнить тестовую публикацию из мобильного приложения WordPress, если вы им пользуетесь.
- Посмотрите логи сервера: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ без ошибок на стороне сайта.
Если после отключения у вас перестала работать синхронизация с внешним сервисом, не ищите проблему в кеше или теме раньше времени. Сначала проверьте, не использует ли этот сервис XML-RPC как основной канал связи.
Частые ошибки и как их исправить
Сломали Jetpack и не поняли почему
Это самая частая ситуация. XML-RPC отключили, а потом обнаружили, что Jetpack не подключается или часть его функций работает с ошибками. Решение простое: либо вернуть XML-RPC, либо отказаться от Jetpack-функций, которые от него зависят, и перейти на другой способ интеграции.
Закрыли файл, но запросы продолжают идти
Так бывает, если блокировка сделана только на уровне WordPress, а сервер все равно принимает запросы и отдает страницу с загрузкой ядра. В этом случае лучше закрывать доступ на уровне nginx или Apache, если задача именно в снижении лишней нагрузки.
Сделали жесткий запрет и забыли про тесты
Если на сайте есть внешние клиенты, мобильное приложение или автопостинг, они могут перестать работать не сразу, а после следующей попытки синхронизации. Поэтому после изменений всегда проверяйте не только статус файла, но и реальные сценарии использования.
Путаница между XML-RPC и REST API
Иногда XML-RPC отключают, думая, что это затронет REST API. Это разные механизмы. Если у вас современная интеграция работает через REST, отключение XML-RPC ей обычно не мешает. Но если сервис старый и использует XML-RPC, он сломается.
Безопасность и производительность: что имеет смысл сделать дополнительно
Отключение XML-RPC само по себе не заменяет нормальную защиту сайта. Если у вас есть атаки на логин, слабые пароли или устаревшие плагины, закрытие одного файла проблему не решит.
- Используйте сложные пароли и двухфакторную аутентификацию для админов.
- Обновляйте WordPress, темы и плагины без задержек.
- Не держите на сайте лишние интеграции, которые давно не используются.
- Если XML-RPC нужен, ограничьте его доступ и следите за логами.
Для сайтов, где важна техническая чистота и контроль дублей, полезно сочетать такие правки с аудитом SEO-настроек. Например, если вы параллельно чистите сайт от лишних технических страниц, удобно делать это в одном цикле проверки, а не по отдельности.
Если нужен более широкий набор инструментов для технической чистки WordPress, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверьте зависимости, а потом уже отключайте лишнее.
Когда лучше не отключать XML-RPC совсем
Полный запрет не всегда лучший вариант. Если сайт активно используется через мобильное приложение, если у вас есть редакционная команда с удаленной публикацией или если Jetpack критичен для рабочих процессов, лучше оставить XML-RPC включенным и закрыть только очевидные риски: ограничить доступ, убрать слабые пароли и следить за подозрительными запросами.
Практический критерий простой: если вы не можете назвать ни одного сценария, где XML-RPC нужен, его можно отключать. Если можете — сначала проверьте, можно ли перевести этот сценарий на REST API или другой способ интеграции, и только потом принимайте решение.