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