XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно ломают мобильное приложение, внешнюю публикацию или старые интеграции. На практике вопрос не в том, нужен ли он вообще, а в том, какие сценарии у вас реально используются и как аккуратно убрать лишнюю поверхность атаки.
Если задача простая — закрыть лишний вход для брутфорса и старых клиентов — решение есть. Но сначала стоит понять, не завязаны ли на XML-RPC ваши сервисы, потому что после отключения ошибка обычно проявляется не в админке, а в стороннем приложении или плагине.
Когда XML-RPC действительно мешает
XML-RPC — это отдельная точка входа в WordPress, обычно по адресу /xmlrpc.php. Через неё работают некоторые внешние клиенты и старые интеграции. Если вы не используете такие сценарии, держать endpoint открытым смысла мало: он часто попадает в логи как цель перебора паролей и запросов на pingback.
Типичные случаи, когда его отключают:
- сайт не использует мобильные приложения WordPress и внешние редакторы;
- нет интеграций, которые публикуют записи через XML-RPC;
- pingback и trackback не нужны;
- в логах видно много запросов к
xmlrpc.phpс ошибками авторизации.
Что может сломаться после отключения
Чаще всего страдают не «обычные» посетители, а внешние сервисы. Например, приложение для публикации постов, старый клиент для удалённого управления сайтом или интеграция, которая до сих пор использует XML-RPC вместо REST API. Если вы не уверены, проверьте список подключений и сценариев до изменения конфигурации.
| Подход | Плюсы | Минусы |
|---|---|---|
| Плагин безопасности | Быстро, без правки кода | Добавляет зависимость от плагина |
| Код в теме или mu-plugin | Контроль, минимум лишнего | Нужно аккуратно внедрять и тестировать |
| Блокировка на уровне сервера | Жёстко и эффективно | Можно случайно задеть нужные запросы |
Диагностика: нужен ли XML-RPC именно вам
Перед отключением проверьте, есть ли реальные обращения к endpoint. Самый простой способ — посмотреть логи веб-сервера и поискать запросы к xmlrpc.php. Если у вас есть доступ к аналитике ошибок или security-логам, там обычно видно повторяющиеся попытки авторизации.
Ещё один практичный тест — временно ограничить доступ и проверить внешние сценарии. Если вы используете публикацию через сторонний клиент, синхронизацию с сервисом или старое приложение, оно быстро покажет проблему.
- проверьте логи Nginx/Apache за последние дни;
- посмотрите, есть ли обращения к
/xmlrpc.php; - сверьте список плагинов и внешних сервисов;
- проверьте, не используется ли Jetpack или другой сервис, которому может понадобиться XML-RPC в конкретной конфигурации.
Как отключить XML-RPC в WordPress: рабочие варианты
Вариант 1. Отключение через код
Если нужен предсказуемый результат без лишних плагинов, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Для большинства сайтов этого достаточно.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Если вы потом решите вернуть endpoint, достаточно убрать фильтр.
Если хотите не просто отключить функциональность, а ещё и отдать корректный статус для прямых запросов, можно дополнительно закрыть доступ на уровне сервера. Но это уже зависит от конфигурации хостинга и веб-сервера.
Вариант 2. Через плагин безопасности
Если вы не хотите трогать код, используйте плагин, где есть отдельная настройка для XML-RPC. Важно не ставить тяжёлый комбайн только ради одной галочки: если у вас уже есть security-плагин, проверьте его настройки прежде чем добавлять новый.
Плюс плагина в том, что он удобен для админов без доступа к файлам. Минус — лишняя зависимость и риск конфликтов, если плагин делает больше, чем нужно.
Вариант 3. Блокировка на уровне сервера
Если задача именно в снижении шума и нагрузки от постоянных запросов, можно закрыть доступ к xmlrpc.php на уровне Nginx или Apache. Это уже серверная мера, и её стоит применять только если вы точно понимаете, что endpoint не нужен.
# Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правила в .htaccess, но в managed-хостингах доступ к ним может быть ограничен. В этом случае проще и безопаснее применить фильтр WordPress или настройку плагина.
Пошаговое решение без лишнего риска
- Соберите список внешних сервисов, которые подключены к сайту.
- Проверьте логи на обращения к
xmlrpc.php. - Сделайте резервную копию конфигурации и файлов, если меняете код или правила сервера.
- Отключите XML-RPC через фильтр
xmlrpc_enabledили через существующий security-плагин. - Проверьте, не сломалась ли публикация из внешнего клиента и не появились ли ошибки в логах.
Если у вас сайт на продакшене, лучше сначала протестировать на staging-копии. Это особенно важно, если сайт давно живёт и на нём могли остаться старые интеграции, о которых никто не помнит.
Как проверить, что решение сработало
После отключения откройте /xmlrpc.php в браузере или выполните запрос из терминала. В норме endpoint не должен отвечать как рабочий интерфейс WordPress.
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали endpoint через WordPress-фильтр, поведение может отличаться в зависимости от сервера и кэша. Поэтому проверяйте не только код ответа, но и фактическую возможность выполнить XML-RPC-запрос из внешнего клиента.
Полезно дополнительно посмотреть:
- нет ли новых ошибок в error log;
- не выросло ли число 403/404 на
xmlrpc.php; - работают ли публикации из тех сервисов, которые вы оставили;
- не ломается ли авторизация в мобильном приложении, если вы его используете.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про внешний сервис
Это самая частая проблема. Сайт вроде бы работает, но публикация из приложения перестаёт отправляться. Решение простое: верните endpoint или переведите интеграцию на REST API, если сервис это поддерживает.
Поставили плагин, который делает слишком много
Иногда ради одной настройки ставят тяжёлый security-плагин, который добавляет лишние проверки, уведомления и конфликты с кэшем. Если вам нужен только XML-RPC, лучше использовать точечное решение через код или уже установленный плагин безопасности.
Закрыли endpoint на сервере, но не проверили кэш и CDN
Если перед сайтом стоит CDN или reverse proxy, старые ответы могут какое-то время кэшироваться. После изменения правил обязательно очистите кэш на всех уровнях: плагин кэша, серверный кэш и CDN, если он есть.
Путали XML-RPC и REST API
Отключение XML-RPC не влияет на REST API WordPress. Это разные механизмы. Если у вас ломается интеграция после отключения, значит она использовала именно XML-RPC, а не современный REST endpoint.
Практические советы по безопасности и производительности
Если цель — уменьшить поверхность атаки, одного отключения XML-RPC может быть мало. Проверьте ещё и другие базовые вещи: ограничение попыток входа, актуальные версии WordPress и плагинов, нормальные пароли и двухфакторную аутентификацию для админов.
С точки зрения производительности выгода от отключения XML-RPC обычно не драматическая, но на сайтах с постоянным мусорным трафиком это может уменьшить количество бесполезных запросов в логах и нагрузку на обработку входящих обращений. Особенно если endpoint регулярно атакуют брутфорсом.
Если вам нужен более широкий контроль над дублями, индексацией и технической чисткой сайта, имеет смысл смотреть не только на XML-RPC, но и на другие точки, которые создают лишний шум. Например, в Clearfy Pro есть инструменты для технической оптимизации и удаления части лишнего функционала, если это подходит вашему стеку: https://wpshop.ru/plugins/clearfy.
В итоге правильный подход здесь простой: сначала понять, кто реально использует XML-RPC, потом отключить его самым коротким и обратимым способом, а затем проверить внешние сценарии и логи. Это тот случай, где аккуратная диагностика важнее «жёсткого» решения.