XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешние публикации или интеграции, которые давно никто не вспоминал. Проблема не в самом XML-RPC, а в том, что его отключают без диагностики зависимостей. Ниже — рабочий порядок: как понять, нужен ли он вам вообще, как выключить его аккуратно и как проверить, что сайт не потерял нужные сценарии.
Когда XML-RPC действительно стоит отключать
Если сайт не использует старые внешние клиенты, публикацию через сторонние сервисы и pingback/trackback, XML-RPC чаще всего можно убрать. На практике он остается нужен в трех случаях: старое мобильное приложение WordPress, интеграции с внешними редакторами и некоторые сервисы автопостинга. Если вы не уверены, сначала проверьте логи и список плагинов, которые работают с удаленной публикацией.
Что обычно ломается после отключения
Чаще всего проблемы проявляются не сразу. Сайт открывается, админка работает, но:
- не публикуются записи из внешнего клиента;
- не проходит авторизация через мобильное приложение;
- перестают приходить/обрабатываться pingback и trackback;
- интеграции с сервисами автопостинга начинают возвращать ошибки 403 или 405.
Диагностика: нужен ли XML-RPC именно вам
Перед отключением проверьте, используется ли endpoint /xmlrpc.php. Самый простой способ — открыть его в браузере. Если XML-RPC включен, WordPress обычно отвечает сообщением о том, что сервер принимает только POST-запросы. Это еще не доказательство использования, но уже сигнал, что endpoint доступен.
Дальше проверьте:
- есть ли в проекте мобильные приложения WordPress, которые реально публикуют записи;
- используются ли внешние редакторы вроде desktop-клиентов;
- есть ли интеграции, которые отправляют записи по XML-RPC;
- нужны ли pingback/trackback на сайте вообще.
Если сайт корпоративный, лендинг или обычный контентный проект без внешней публикации, отключение XML-RPC обычно не создает проблем. Если это старый блог с историческими интеграциями, сначала тестируйте на staging-копии.
Пошаговое решение: как отключить XML-RPC правильно
Есть три подхода: через плагин, через код и через серверную блокировку. Для большинства сайтов достаточно кода в functions.php дочерней темы или в небольшом mu-plugin. Плагин удобен, если вы хотите управлять настройкой без правки кода, но он добавляет еще одну точку отказа.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме / mu-plugin | Прозрачно, быстро, без лишних зависимостей | Нужно не забыть при смене темы | Если есть доступ к коду и нужен контроль |
| Плагин безопасности | Можно включать/выключать из админки | Лишняя зависимость, иногда избыточен | Если админка обслуживается не разработчиком |
| Блокировка на сервере | Снимает нагрузку раньше WordPress | Зависит от конфигурации сервера | Если нужен жесткий запрет на уровне веб-сервера |
Вариант 1: отключить XML-RPC через код
Самый аккуратный способ — запретить сам endpoint. Добавьте код в functions.php дочерней темы или в mu-plugin:
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите не просто отключить, а еще и убрать pingback-методы, можно дополнительно фильтровать методы XML-RPC:
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Этот вариант полезен, если вам нужно оставить часть XML-RPC-логики для совместимости, но убрать pingback. Однако в большинстве случаев проще отключить все целиком.
Вариант 2: закрыть xmlrpc.php на уровне сервера
Если цель — именно блокировка запросов до WordPress, можно закрыть xmlrpc.php на сервере. Для Apache это обычно делают через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика зависит от конфигурации сайта, но смысл тот же: отдельный location для xmlrpc.php с отказом в доступе. Этот способ хорош, когда вы хотите снизить лишние запросы и не полагаться только на PHP-уровень.
Вариант 3: использовать плагин
Если на сайте уже стоит плагин безопасности, проверьте, есть ли в нем отдельная опция для XML-RPC. Это удобно для редакторов и администраторов без доступа к коду. Но если плагин решает сразу десяток задач, не включайте его только ради одной галочки: иногда проще и надежнее добавить одну строку кода.
Как проверить, что отключение сработало
После внедрения проверьте не только сам endpoint, но и реальные сценарии. Это важнее, чем просто увидеть ошибку в браузере.
- Откройте
/xmlrpc.php— доступ должен быть закрыт или endpoint должен возвращать отказ. - Проверьте публикацию из внешнего клиента, если он у вас есть.
- Убедитесь, что мобильное приложение WordPress не используется для публикации.
- Посмотрите логи веб-сервера на повторяющиеся запросы к
xmlrpc.php. - Проверьте, не завязаны ли на XML-RPC сторонние сервисы автопостинга.
Если после отключения на сайте ничего не изменилось, это хороший знак. Но лучше еще раз пройтись по интеграциям, которые подключались давно и могли быть забыты.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом сломалась публикация из приложения
Значит, зависимость была, просто ее не проверили. Решение простое: либо вернуть XML-RPC, либо перевести публикацию на другой канал. Если приложение критично, не блокируйте endpoint на сервере без теста.
Поставили плагин, но endpoint все равно доступен
Некоторые плагины отключают только отдельные методы, а не весь XML-RPC. Проверьте описание настройки: если нужен полный запрет, ищите именно опцию полного отключения или используйте код xmlrpc_enabled.
Закрыли xmlrpc.php, но забыли про pingback
Если сайт активно принимал pingback, после блокировки могут остаться старые ссылки или уведомления в логах. Обычно это не критично, но на старых блогах стоит проверить, нет ли зависших уведомлений и лишнего шума в логах.
Сделали правку в родительской теме
При обновлении темы изменение пропадет. Для таких правок используйте дочернюю тему или mu-plugin. Это особенно важно, если вы отключаете XML-RPC на нескольких сайтах и хотите одинаковое поведение.
Безопасность и производительность: что еще стоит учесть
Отключение XML-RPC — не замена нормальной защите входа, но это полезное сокращение поверхности атаки. Если endpoint не нужен, его лучше убрать. При этом не стоит считать, что одной этой мерой вы решили все вопросы безопасности.
Практически полезно сделать еще три вещи:
- ограничить число попыток входа;
- проверить, не включены ли лишние публичные API-интеграции;
- убрать старые плагины, которые давно не используются, но все еще загружаются.
Если у вас много технических дублей и лишних служебных функций на сайте, имеет смысл посмотреть в сторону инструментов чистки и SEO-гигиены. Например, Clearfy Pro помогает убрать часть технического шума и сократить количество лишних настроек, но использовать его стоит только там, где вы понимаете, что именно отключаете: Clearfy Pro.
Если нужен безопасный минимум
Если вы не хотите трогать сервер и не уверены, что XML-RPC нигде не используется, начните с проверки логов и теста на staging. Затем отключайте endpoint кодом, а не набором случайных плагинов. Это проще откатить и легче сопровождать.
Для большинства сайтов рабочая схема такая: сначала диагностика, потом отключение через xmlrpc_enabled, затем проверка реальных сценариев публикации. Такой порядок снижает риск сломать интеграции и не оставляет лишний технический мусор в системе.