Как отключить XML-RPC в WordPress и защитить сайт от лишних запросов

Автор: Ольга Громова | Опубликовано: 03.09.2026

XML-RPC в WordPress до сих пор включён на многих сайтах по умолчанию, хотя далеко не всегда нужен. На практике он часто становится источником лишних запросов, шумит в логах и расширяет поверхность атаки, если сайт не использует мобильное приложение WordPress, внешние сервисы публикации или старые интеграции.

Ниже разберём, как понять, нужен ли вам XML-RPC, как отключить его без поломки сайта и чем заменить, если интеграция всё-таки требуется.

Когда XML-RPC действительно мешает

Проблема обычно всплывает не в админке, а по косвенным признакам: в логах появляются повторяющиеся обращения к /xmlrpc.php, хостинг ругается на нагрузку, а в отчётах безопасности видны попытки подбора паролей через системные методы WordPress. Сам по себе файл xmlrpc.php не является ошибкой, но если вы им не пользуетесь, держать его открытым нет смысла.

Типичные сценарии

сайт работает только через браузер, без мобильного приложения WordPress;
публикация идёт вручную или через REST API, а не через старые XML-RPC клиенты;
в логах много запросов с методами system.multicall и pingback.ping;
на дешёвом хостинге заметна лишняя нагрузка от ботов и сканеров.

Диагностика: нужен ли вам XML-RPC вообще

Перед отключением проверьте, не завязаны ли на XML-RPC ваши сценарии работы. Это важно: если выключить его вслепую, можно сломать публикацию из стороннего клиента или синхронизацию с сервисом, который ещё не переведён на REST API.

Что проверить в первую очередь

используете ли вы мобильное приложение WordPress;
есть ли внешние сервисы, которые публикуют записи через XML-RPC;
нужны ли вам pingback/trackback — в большинстве случаев нет;
есть ли в логах обращения к xmlrpc.php от реальных пользователей или только от ботов.

Если сомневаетесь, откройте access log и посмотрите частоту запросов. Для большинства обычных сайтов ответ будет простой: XML-RPC не нужен.

Как отключить XML-RPC без плагина

Самый прямой способ — заблокировать доступ к xmlrpc.php на уровне WordPress. Это не требует сторонних плагинов и легко откатывается.

<?php
// functions.php дочерней темы или mu-plugin
add_filter( 'xmlrpc_enabled', '__return_false' );

Этот фильтр отключает сам XML-RPC на уровне WordPress. Если кто-то попытается обратиться к файлу напрямую, WordPress не будет обрабатывать запрос как XML-RPC-сессию.

Если нужен более жёсткий вариант, можно дополнительно закрыть файл на уровне веб-сервера. Это полезно, когда боты продолжают стучаться в /xmlrpc.php и вы хотите отрезать их раньше, чем запрос дойдёт до PHP.

<Files xmlrpc.php>
    Require all denied
</Files>

Для Nginx логика будет другой: блокировку обычно добавляют в конфигурацию сайта, а не в .htaccess. Конкретный блок зависит от вашей схемы, поэтому здесь важно не копировать чужой фрагмент без проверки синтаксиса и перезагрузки конфигурации.

Если XML-RPC нужен частично

Иногда отключать его полностью нельзя. Например, сайт использует старую интеграцию или мобильное приложение, а вы пока не готовы переводить процесс на REST API. В таком случае лучше не оставлять всё как есть, а ограничить поверхность атаки.

Что можно сделать вместо полного отключения

закрыть доступ к pingback.ping, если он не нужен;
ограничить XML-RPC на уровне WAF или firewall;
оставить доступ только для доверенных IP, если интеграция работает с фиксированного адреса;
перевести публикацию на REST API с авторизацией по application passwords.

Последний вариант обычно самый практичный: REST API в WordPress поддерживается штатно, а для внешних приложений можно использовать application passwords, не открывая XML-RPC.

Сравнение подходов

Подход	Когда подходит	Минус
Фильтр `xmlrpc_enabled`	Нужно быстро отключить XML-RPC в WordPress	Не всегда блокирует прямой доступ на уровне веб-сервера
Блокировка в веб-сервере	Нужно отсечь запросы до PHP	Нужно аккуратно править конфигурацию
Оставить и ограничить	Есть зависимость от старой интеграции	Поверхность атаки остаётся, пусть и меньше

Пошаговое решение для обычного сайта

Если у вас нет внешних клиентов, делайте так:

Проверьте, что мобильное приложение WordPress и старые интеграции не используются.
Добавьте фильтр xmlrpc_enabled в functions.php дочерней темы или в mu-plugin.
При необходимости закройте xmlrpc.php на уровне веб-сервера.
Очистите кэш, если на сайте есть page cache или CDN.
Проверьте логи и убедитесь, что обращения к xmlrpc.php больше не проходят.

Если вы ведёте проект на нескольких средах, лучше вынести отключение в mu-plugin. Так настройка не потеряется при смене темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Как проверить, что всё сработало

После внедрения не ограничивайтесь визуальной проверкой. Нужны именно технические признаки, что XML-RPC больше не отвечает.

откройте /xmlrpc.php в браузере — вместо рабочего ответа вы должны увидеть отказ или пустую страницу в зависимости от способа блокировки;
проверьте access log: новые запросы к этому пути не должны доходить до PHP;
если у вас был мониторинг безопасности, убедитесь, что число попыток через XML-RPC снизилось;
проверьте публикацию и авторизацию в штатной админке, чтобы не сломать обычный вход в WordPress.

Если после отключения что-то перестало работать, почти всегда причина одна: на сайте есть забытая интеграция, которая использовала XML-RPC, а не REST API.

Частые ошибки и как их исправить

Отключили XML-RPC, но запросы продолжают идти

Это нормально, если вы закрыли только WordPress-фильтром. Боты всё равно будут стучаться в файл, но WordPress уже не обработает запрос. Если хотите убрать шум раньше, добавьте блокировку на уровне веб-сервера или WAF.

Сломалась публикация из внешнего сервиса

Значит, сервис был завязан на XML-RPC. Проверьте, есть ли у него режим работы через REST API. Если нет — оставьте XML-RPC только для этого сценария и ограничьте доступ по IP или правилам firewall.

Поставили плагин, который «защищает всё», и не поняли, что он делает

С такими плагинами часто проблема в том, что они отключают не только XML-RPC, но и соседние функции, а потом сложно понять, где именно возник конфликт. Для точечной задачи лучше использовать код или понятный security-плагин с прозрачной настройкой. Если нужен более широкий набор мер по чистке и SEO-оптимизации, имеет смысл смотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wppartner.ru&utm_medium=article&utm_campaign=kak-otklyuchit-xmlrpc-v-wordpress-i-zashchitit-sajt-ot-lishnih-zaprosov

Безопасность и производительность: что ещё стоит учесть

Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает один из лишних входов для атак и сканеров. На практике это особенно полезно вместе с нормальной политикой паролей, ограничением попыток входа и актуальными обновлениями ядра, темы и плагинов.

Если сайт работает на слабом хостинге, не забывайте про кэширование и логику обработки запросов. Даже небольшой поток мусорных обращений к xmlrpc.php может мешать, если PHP-FPM и база уже загружены контентными запросами. В таких случаях блокировка на уровне веб-сервера даёт более заметный эффект, чем только фильтр в WordPress.

И ещё один практический момент: если вы отключаете XML-RPC на продакшене, зафиксируйте это в документации проекта. Через полгода никто не вспомнит, почему старый клиент перестал публиковать записи, и это сэкономит время на разборе инцидента.