XML-RPC в WordPress часто отключают «на всякий случай», а потом удивляются, почему перестал работать Jetpack, мобильное приложение или публикация через сторонний сервис. На практике задача не в том, чтобы просто закрыть /xmlrpc.php, а в том, чтобы понять, нужен ли он вообще вашему сайту и чем его безопасно заменить.
Если у вас нет старых интеграций, XML-RPC обычно не нужен. Но перед отключением стоит быстро проверить зависимости: это дешевле, чем потом искать, почему не отправляются посты по API или не синхронизируется статистика.
Когда XML-RPC действительно стоит отключать
XML-RPC — старый механизм удалённого доступа к WordPress. Его до сих пор используют некоторые приложения и сервисы, но для большинства современных сайтов он не обязателен. Отключение имеет смысл, если:
- вы не публикуете записи через мобильное приложение WordPress;
- не используете Jetpack для функций, завязанных на XML-RPC;
- нет внешних сервисов, которые подключаются к сайту через XML-RPC;
- в логах видно много запросов к
/xmlrpc.phpот ботов; - вам нужно уменьшить поверхность атаки, особенно на сайтах с простыми паролями и слабой защитой админки.
Если сайт старый, сначала проверьте, не сидит ли на XML-RPC какой-нибудь забытый плагин или интеграция. Это типичная ошибка: отключают механизм, а потом ломают рабочий процесс публикации.
Диагностика: используется ли XML-RPC сейчас
Самый практичный способ — посмотреть, есть ли реальные обращения к xmlrpc.php. Это можно сделать в логах веб-сервера или через инструменты аналитики запросов. Если доступа к логам нет, проверьте зависимости вручную.
Что проверить перед отключением
- используете ли вы Jetpack;
- работает ли публикация из мобильного приложения WordPress;
- подключены ли внешние редакторы и сервисы автопостинга;
- есть ли интеграции с CRM, которые отправляют данные в WordPress через XML-RPC;
- не использует ли ваш хостинг старые инструкции по синхронизации через XML-RPC.
Если вы не уверены, временно ограничьте доступ к файлу, а не удаляйте его. Так проще откатить изменение.
Пошаговое решение: как отключить XML-RPC
Есть три рабочих подхода: через плагин, через код и на уровне веб-сервера. Выбор зависит от того, хотите ли вы быстрое решение без правок темы и насколько жёстко нужно закрыть доступ.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин | Нужно быстро и без кода | Просто откатить, не требует правок файлов | Добавляет ещё один плагин в стек |
Код в functions.php или mu-plugin | Нужен контроль без лишних плагинов | Прозрачно, легко версионировать | Нужно аккуратно обновлять |
| Правило на сервере | Нужно жёстко закрыть доступ | Запросы не доходят до WordPress | Зависит от конфигурации сервера |
Вариант 1: отключение через код
Если вам нужно именно отключить XML-RPC, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Это не самый «красивый» способ с точки зрения архитектуры, но он рабочий и понятный.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress перестанет принимать XML-RPC-запросы. Если позже понадобится вернуть поддержку, достаточно убрать фильтр.
Вариант 2: точечная блокировка на сервере
Если у вас Apache, можно закрыть доступ к xmlrpc.php через .htaccess. Это полезно, когда вы хотите отсечь запросы до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx обычно используют отдельное правило в конфигурации сайта. Формулировка зависит от вашей схемы, но логика одна: вернуть 403 для /xmlrpc.php.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Если вы не управляете сервером напрямую, этот вариант лучше согласовать с администратором хостинга. Неправильное правило может задеть другие location-блоки.
Вариант 3: плагин для отключения
Если нужен быстрый способ без редактирования кода, можно использовать плагин, который отключает XML-RPC или ограничивает его. Но здесь важно не ставить всё подряд: если задача только в закрытии xmlrpc.php, плагин должен делать именно это, без лишней нагрузки и конфликтов.
В ряде случаев удобнее взять комплексный инструмент для технической чистки сайта, например Clearfy Pro, если вам одновременно нужно отключать лишние функции WordPress, убирать дубли и наводить порядок в служебных настройках. Ссылка: https://wpshop.ru/plugins/clearfy
Как проверить, что отключение сработало
Проверка должна быть не формальной, а прикладной. Откройте https://ваш-домен/xmlrpc.php в браузере или отправьте POST-запрос. Если всё закрыто, вы должны получить отказ в доступе или пустой ответ без нормальной обработки WordPress.
Для быстрой проверки можно использовать curl:
curl -i https://example.com/xmlrpc.phpЕсли вы блокировали файл на уровне сервера, ожидайте 403 Forbidden. Если отключали через фильтр WordPress, поведение может отличаться в зависимости от конфигурации, но сам XML-RPC должен перестать принимать рабочие запросы.
Что ещё проверить после изменения
- Jetpack не потерял нужные функции;
- мобильное приложение WordPress не использует старую схему публикации;
- внешние сервисы автопостинга не отваливаются;
- в логах больше нет массовых обращений к
xmlrpc.phpс кодом 200; - админка и REST API работают как раньше.
Частые ошибки и как их исправить
Отключили XML-RPC, но сломали Jetpack
Причина обычно в том, что Jetpack ещё использует старую связку функций, завязанную на XML-RPC. Решение простое: либо не отключать XML-RPC, либо перейти на другой способ защиты и проверить, какие модули Jetpack реально нужны.
Закрыли файл, но запросы всё равно доходят
Так бывает, если правило добавлено не в тот серверный блок или кэш/прокси отдаёт старую конфигурацию. Проверьте, что правило применено именно к нужному виртуальному хосту, и перезапустите конфигурацию, если это требуется.
Удалили файл xmlrpc.php
Так делать не стоит. Обновления WordPress могут восстановить файл, а часть инструментов ожидает его наличие. Безопаснее блокировать доступ, а не ломать структуру ядра.
Отключили через плагин и забыли про обновления
Если плагин давно не обновлялся, он сам становится риском. Для простой задачи лучше код или серверное правило, чем ещё один зависимый компонент.
Безопасность и производительность: что учесть дополнительно
Отключение XML-RPC не заменяет нормальную защиту входа в админку. Если у вас слабые пароли, нет лимита попыток входа и открыт /wp-login.php, ботам есть куда стучаться и без XML-RPC.
- используйте сложные пароли и двухфакторную аутентификацию, если это возможно;
- ограничьте попытки входа;
- проверьте права на файлы и директории;
- не держите лишние плагины, которые дублируют защитные функции;
- после изменений очистите кэш, если у вас стоит серверный или плагинный кэш.
Если сайт большой, отключение XML-RPC само по себе не даст заметного прироста скорости. Но оно может снизить шум в логах и убрать часть бесполезных запросов, что уже полезно для диагностики и поддержки.
Когда XML-RPC лучше не трогать
Если сайт живёт за счёт старых интеграций, мобильной публикации или специфичных внешних сервисов, отключать XML-RPC без теста нельзя. В таких проектах сначала составляют список зависимостей, потом делают изменение на staging, и только после этого переносят в продакшен.
Если нужен более широкий технический аудит WordPress — дубли, служебные функции, SEO-мелочи и чистка лишнего — имеет смысл смотреть на инструменты, которые закрывают несколько задач сразу, а не на точечные «отключалки». Но даже в этом случае XML-RPC лучше проверять отдельно: это один из тех механизмов, которые ломают не сразу, а в самый неудобный момент.