Если сайт не использует мобильные клиенты старого формата, pingback или внешние сервисы на XML-RPC, этот интерфейс обычно только добавляет лишнюю поверхность атаки. При этом отключать его нужно аккуратно: многие путают XML-RPC с REST API и случайно ломают интеграции, редактор или обычный вход в админку.
Ниже разберём рабочий вариант без плагинов: через functions.php дочерней темы или через маленький must-use плагин. Заодно покажу, как проверить, что именно XML-RPC закрыт, а REST API остался доступен.
Когда XML-RPC действительно стоит отключить
Сначала полезно понять, есть ли у вас вообще зависимость от этого интерфейса. XML-RPC нужен не каждому сайту. Чаще всего его оставляют по привычке, а потом получают лишние запросы на /xmlrpc.php и попытки брутфорса.
Типичные признаки, что XML-RPC можно закрывать
- вы не пользуетесь приложением WordPress для мобильного управления сайтом;
- не подключали внешние сервисы, которым нужен XML-RPC;
- не используете старые интеграции для публикации материалов по удалёнке;
- в логах есть регулярные обращения к
xmlrpc.phpбез понятной причины.
Если сайт работает на современном редакторе и обычной админке, в большинстве случаев REST API достаточно. Но это не значит, что XML-RPC можно просто удалить файлом: лучше отключить его контролируемо и потом проверить результат.
Диагностика: что именно нужно отключить
Перед изменениями проверьте два разных механизма:
xmlrpc.php— отдельная точка входа;- REST API — используется редактором Gutenberg, блоками, некоторыми плагинами и внешними интеграциями.
Их часто смешивают. Если заблокировать всё подряд на уровне сервера, можно получить неочевидные ошибки в редакторе или в приложениях, которые работают через REST.
| Подход | Что отключает | Плюсы | Минусы |
|---|---|---|---|
| Код в теме | XML-RPC на уровне WordPress | Просто откатить, не трогает сервер | Запрос всё равно доходит до WordPress |
| MU-плагин | XML-RPC на уровне WordPress | Не зависит от темы | Нужно создать отдельный файл |
| .htaccess / nginx | XML-RPC до PHP | Меньше нагрузки | Нужно аккуратно править конфиг сервера |
Если задача — быстро и безопасно закрыть XML-RPC без изменения конфигурации сервера, код в теме или MU-плагин обычно удобнее. Для production-сайта я бы предпочёл MU-плагин, потому что он не исчезнет при смене темы.
Пошаговое решение через functions.php
Если вам нужен самый простой вариант, добавьте фильтр в functions.php дочерней темы. Не в родительскую тему: обновление её перетрёт правку.
add_filter( 'xmlrpc_enabled', '__return_false' );Эта строка отключает XML-RPC на уровне WordPress. После этого запросы к /xmlrpc.php должны перестать работать как раньше.
Если хотите оставить возможность точечно включать XML-RPC в будущем, лучше оформить это отдельной функцией:
add_filter( 'xmlrpc_enabled', function( $enabled ) {
return false;
} );Оба варианта рабочие. Первый короче, второй удобнее, если потом понадобится добавить условие, например отключать XML-RPC только на боевом сайте.
Вариант через MU-плагин
Если не хотите привязываться к теме, создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );MU-плагин загружается автоматически и не отключится при смене темы. Для технической чистоты это часто лучший вариант, особенно если сайт поддерживает несколько разработчиков.
Как не сломать REST API и обычный вход
Самая частая ошибка — пытаться закрыть XML-RPC через слишком широкий запрет на уровне сервера. Например, блокировать по пути всё, что связано с wp-json, или ставить правила, которые режут POST-запросы без разбора. В результате ломается не XML-RPC, а редактор, формы или интеграции.
Если вы отключаете XML-RPC через фильтр xmlrpc_enabled, REST API не затрагивается. Это и есть безопасный вариант для большинства сайтов.
Если всё же нужен серверный уровень, правило должно касаться только xmlrpc.php. Для Apache это может выглядеть так:
<Files xmlrpc.php>
Require all denied
</Files>Такой вариант блокирует именно файл XML-RPC и не трогает остальные маршруты WordPress. Но перед применением проверьте, что у вас не используется nginx с отдельной конфигурацией: там синтаксис будет другим.
Проверка результата после внедрения
После правки не ограничивайтесь тем, что сайт “открылся”. Нужно проверить конкретно XML-RPC и REST API.
Что проверить вручную
- Откройте
/xmlrpc.phpв браузере или черезcurl. - Проверьте, что REST API отвечает на
/wp-json/. - Убедитесь, что вход в
/wp-admin/работает как обычно. - Если есть внешние интеграции, протестируйте их отдельно.
Пример проверки через curl:
curl -i https://example.com/xmlrpc.php
curl -i https://example.com/wp-json/После отключения XML-RPC первый запрос должен вернуть отказ или пустой ответ в зависимости от способа блокировки. Второй запрос должен продолжать отдавать JSON, если REST API не трогали.
Если хотите проверить именно WordPress-уровень, посмотрите, не возвращает ли сайт заголовок или страницу, характерную для XML-RPC. В идеале запрос должен упираться в запрет ещё до выполнения полезной логики.
Частые ошибки и как их исправить
- Правка внесена в родительскую тему. После обновления всё пропадёт. Решение: перенести код в дочернюю тему или MU-плагин.
- Отключили не только XML-RPC, но и REST API. Обычно это следствие слишком жёстких правил на сервере. Решение: убрать блокировку
/wp-json/и оставить толькоxmlrpc.php. - Проверяли только главную страницу. Сайт может открываться, а XML-RPC при этом продолжает отвечать. Решение: тестировать конкретный URL
/xmlrpc.php. - Сломались внешние сервисы. Значит, у вас был реальный потребитель XML-RPC. Решение: либо вернуть доступ, либо перевести интеграцию на REST API, если сервис это поддерживает.
- Добавили код в активную тему и забыли. При смене темы защита исчезнет. Решение: для постоянной настройки использовать MU-плагин.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт “защищённым”, но убирает один из лишних векторов атаки. На сайтах с регулярными попытками брутфорса это полезная гигиена.
Если у вас уже есть набор технических чисток, удобно держать такие правки в одном месте: часть — в MU-плагине, часть — в отдельном мини-плагине для сайта. Так проще сопровождать проект и не искать настройки по разным файлам темы.
Для сайтов, где важны SEO и техническая чистота, можно дополнительно проверить, не создают ли лишние запросы другие старые интерфейсы и дубли. Если нужен более широкий набор точечных оптимизаций, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но если задача только в XML-RPC, отдельный кодовый фикс обычно проще и прозрачнее.
Короткий чек-лист перед публикацией изменения
- код добавлен в дочернюю тему или MU-плагин;
/xmlrpc.phpбольше не отвечает как раньше;/wp-json/продолжает работать;- вход в админку не сломан;
- внешние интеграции проверены отдельно;
- изменение задокументировано в репозитории или заметках проекта.
Если после отключения XML-RPC у вас остались только современные интеграции, это обычно хороший знак: сайт стал чуть проще в поддержке и меньше зависит от устаревшего механизма.