XML-RPC в WordPress часто отключают из соображений безопасности, но делают это грубо: через .htaccess, без проверки зависимостей и без понимания, что именно сломается. В результате перестают работать внешние публикации, мобильные клиенты, некоторые интеграции и часть сервисов, которые обращаются к сайту не через обычную админку.
Если задача звучит именно так — убрать XML-RPC, но не трогать REST API — лучше идти точечно. Ниже разберём, как проверить, нужен ли XML-RPC вообще, как отключить его безопасно и как убедиться, что REST API продолжает работать.
Когда XML-RPC можно отключать, а когда нет
XML-RPC нужен не всем. На типичном сайте, где публикация идёт только через админку WordPress, он действительно чаще лишний. Но перед отключением стоит проверить, нет ли завязок на внешние инструменты.
Сценарии, где XML-RPC обычно не нужен
- посты и страницы редактируются только из панели WordPress;
- нет старых мобильных приложений WordPress для публикации;
- нет внешних сервисов, которые используют
xmlrpc.phpдля постинга или синхронизации; - сайт не подключён к legacy-интеграциям, написанным много лет назад.
Сценарии, где отключение может навредить
- подключены старые клиенты для удалённой публикации;
- используются сервисы автопостинга, которые до сих пор ходят в XML-RPC;
- есть интеграции с приложениями, где REST API не настроен или не используется;
- вы не уверены, кто и как обращается к сайту извне.
Диагностика: как понять, используется ли XML-RPC
Начинать лучше не с блокировки, а с проверки запросов. Если у вас есть доступ к логам веб-сервера, посмотрите обращения к /xmlrpc.php. Это самый надёжный способ увидеть реальную активность.
# Пример для поиска обращений в access.log
# путь и формат логов зависят от хостинга
grep "xmlrpc.php" /var/log/nginx/access.log
grep "xmlrpc.php" /var/log/apache2/access.logЕсли логов нет, можно временно проверить ответ самого файла. Откройте в браузере https://example.com/xmlrpc.php. Нормальный ответ WordPress обычно выглядит как сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает использование, но подтверждает, что endpoint доступен.
Дополнительно проверьте, не завязаны ли на него плагины или внешние сервисы. Если у вас есть список интеграций, это хороший момент пройтись по нему вручную.
- сервисы автопостинга;
- мобильные приложения для публикации;
- внешние редакторы контента;
- старые скрипты синхронизации записей.
Что выбрать: плагин, код или серверный запрет
Есть несколько рабочих подходов. Для большинства сайтов достаточно отключить XML-RPC на уровне WordPress, не трогая REST API. Если нужен более жёсткий вариант, можно добавить серверное правило, но это уже стоит делать осознанно.
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или MU-плагине | Отключает XML-RPC из WordPress | Не ломает REST API, легко откатить | Нужно добавить код вручную |
| Плагин безопасности | Даёт переключатель в интерфейсе | Удобно для админов без кода | Лишняя зависимость, иногда больше функций, чем нужно |
| Серверный запрет | Блокирует доступ к xmlrpc.php на уровне веб-сервера | Жёстко и быстро | Можно случайно задеть нужные интеграции |
Пошаговое решение без поломки REST API
Если задача — отключить XML-RPC именно в WordPress, а не на уровне сервера, используйте фильтр xmlrpc_enabled. Он отключает XML-RPC, но не влияет на REST API и обычный вход в админку.
<?php
// Лучше размещать в mu-plugin или в functions.php дочерней темы.
// Для production надёжнее mu-plugin, чтобы код не потерялся при смене темы.
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите не просто отключить обработку, а ещё и убрать сам файл из доступности, можно дополнительно вернуть 403 при прямом обращении к xmlrpc.php. Но это уже более жёсткий шаг, и его стоит применять только если вы уверены, что интеграции не нужны.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );На практике чаще достаточно первого варианта. Он проще, прозрачнее и меньше рискует задеть сторонние сценарии.
Куда лучше добавить код
Если у вас есть дочерняя тема, можно временно положить код в functions.php, но для технических ограничений лучше использовать mu-plugin. Тогда отключение не исчезнет при обновлении темы.
<?php
/**
* Plugin Name: WPCat XML-RPC Disable
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Файл положите в wp-content/mu-plugins/. Если папки нет, создайте её. WordPress подхватит такой файл автоматически.
Как проверить, что решение сработало
Проверка нужна не только для XML-RPC, но и для REST API. Иначе можно случайно получить «безопасный» сайт, который уже не работает с редактором, приложениями или внешними сервисами.
Проверка XML-RPC
- откройте
/xmlrpc.phpв браузере — доступ должен быть ограничен или обработка отключена; - если используете curl, отправьте тестовый POST-запрос и проверьте, что сервер не отвечает как раньше;
- посмотрите логи веб-сервера: новых обращений к endpoint быть не должно, либо они должны завершаться отказом.
Проверка REST API
REST API должен продолжать отвечать. Самый простой тест — открыть базовый endpoint WordPress:
https://example.com/wp-json/Если всё в порядке, вы увидите JSON-ответ с информацией о маршрутах. Это значит, что отключение XML-RPC не задело REST API.
Ещё один полезный тест — проверить конкретный маршрут, например записи:
https://example.com/wp-json/wp/v2/postsЕсли сайт закрыт авторизацией, ответ может быть ограничен, но сам endpoint должен существовать и отдавать корректный HTTP-ответ, а не ошибку сервера.
Частые ошибки и как их исправить
Отключили XML-RPC через .htaccess и сломали нужную интеграцию
Это типичная ошибка, когда блокируют xmlrpc.php на уровне сервера, не проверив зависимости. Если после этого перестали работать публикации из внешнего сервиса, уберите серверное правило и оставьте отключение через xmlrpc_enabled только после теста.
Проверили только главную страницу и решили, что всё работает
Главная страница может открываться нормально, даже если REST API уже сломан из-за другого правила или плагина безопасности. Проверяйте именно /wp-json/ и конкретные маршруты, а не только фронтенд.
Добавили код в тему, а потом потеряли его после обновления
Если код лежал в родительской теме, обновление его затрёт. Для таких задач используйте mu-plugin или дочернюю тему. Это особенно важно для ограничений безопасности.
Смешали отключение XML-RPC с отключением REST API
Некоторые плагины безопасности умеют блокировать оба механизма сразу. Если вам нужен только XML-RPC, проверьте настройки плагина внимательно. Иначе можно получить проблемы с редактором, мобильными приложениями и интеграциями, которые работают через REST.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищённым полностью», но убирает один из лишних публичных входов. Это разумная мера, если вы не используете удалённую публикацию.
- не блокируйте всё подряд на уровне сервера, пока не проверили зависимости;
- если используете плагин безопасности, проверьте, не отключает ли он REST API вместе с XML-RPC;
- держите отдельный список внешних интеграций, которые обращаются к сайту;
- после изменений проверьте логи хотя бы в первые дни, чтобы увидеть неожиданные обращения;
- если сайт обслуживает редакторов через внешние инструменты, сначала протестируйте на staging-копии.
Если вам нужно не только убрать XML-RPC, но и навести порядок в технических настройках сайта, полезно смотреть шире: дубли, индексация, лишние скрипты, кеш и правила безопасности. Для этого иногда удобнее использовать набор точечных настроек, чем ставить тяжёлый комбайн. В экосистеме WPShop, например, для таких задач есть Clearfy Pro, если нужен именно набор технических переключателей без ручного разбрасывания по коду.
Мини-чек-лист перед публикацией изменений
- проверены ли внешние сервисы, которые могли использовать XML-RPC;
- выбрано ли место для кода, которое не исчезнет после обновления темы;
- проверен ли ответ
/wp-json/после изменений; - есть ли откатный план, если интеграция перестанет работать;
- посмотрены ли логи на предмет ошибок и отказов после внедрения.
Если после отключения XML-RPC сайт ведёт себя нормально, а REST API продолжает отвечать, значит задача решена правильно: лишний endpoint убран, а рабочие механизмы WordPress остались на месте.