Как отключить XML-RPC в WordPress без поломки сайта

Автор: Игорь Титов | Опубликовано: 29.09.2026

XML-RPC в WordPress часто отключают из соображений безопасности, но на практике проблема почти всегда не в самом факте отключения, а в том, что сайт после этого перестаёт работать с нужной интеграцией. Типичный сценарий: админ видит подозрительные запросы к /xmlrpc.php, хочет закрыть точку входа, а потом внезапно отваливаются Jetpack, публикация из стороннего клиента или удалённый доступ к сайту.

Ниже — рабочий порядок действий: сначала понять, нужен ли XML-RPC вообще, потом отключить его так, чтобы не сломать нужные сценарии, и в конце проверить результат не «на глаз», а по факту ответа сервера.

Когда XML-RPC действительно стоит отключать

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

Но отключение не универсально. Перед изменениями проверьте, не завязан ли на XML-RPC один из ваших сценариев:

Jetpack и некоторые его функции;
публикация из внешних приложений и десктопных клиентов;
старые интеграции, которые используют xmlrpc.php вместо REST API;
синхронизация с сервисами, которые давно не обновлялись.

Быстрая диагностика проблемы

Сначала посмотрите, действительно ли endpoint доступен извне. Откройте в браузере https://site.ru/xmlrpc.php. Если XML-RPC включён, WordPress обычно отвечает сообщением о том, что на этом endpoint принимаются только POST-запросы. Это не ошибка само по себе, а признак того, что файл доступен.

Если есть доступ к серверу, можно проверить ответ точнее:

curl -I https://site.ru/xmlrpc.php

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

Как отключить XML-RPC в WordPress

Есть три практических подхода: через код, через серверный конфиг и через плагин. Если нужен предсказуемый результат и вы контролируете тему или mu-plugin, код обычно удобнее. Если сайт под атакой и нужно закрыть доступ на уровне веб-сервера, лучше резать запросы раньше, чем они дойдут до WordPress.

Вариант 1: отключение через код

Самый аккуратный способ — добавить фильтр в functions.php дочерней темы или, что лучше, в небольшой mu-plugin. Так вы не потеряете настройку при обновлении темы.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Этот вариант отключает XML-RPC на уровне WordPress. Если какой-то плагин или интеграция обращается к xmlrpc.php, она получит отказ уже от ядра.

Вариант 2: блокировка на уровне сервера

Если цель — именно снизить нагрузку и убрать лишние запросы ещё до загрузки WordPress, можно закрыть файл на уровне веб-сервера. Для Apache это обычно делают через .htaccess:

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

Для Nginx логика другая, правило добавляют в конфигурацию сайта:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Серверный вариант полезен, если на сайт идёт много мусорных запросов и вы хотите отсечь их до PHP. Но не забывайте: если потом понадобится интеграция, доступ придётся вернуть именно в конфиге сервера.

Вариант 3: плагин для защиты

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

Подход	Плюсы	Минусы
Фильтр `xmlrpc_enabled`	Просто, прозрачно, легко откатить	Не режет запросы до WordPress
Apache/Nginx правило	Ранний отказ, меньше нагрузки	Нужно править конфиг сервера
Плагин	Без кода	Лишняя зависимость, возможны конфликты

Как не сломать нужные интеграции

Самая частая ошибка — отключить XML-RPC «вслепую», а потом искать причину, почему перестала работать публикация из внешнего клиента или синхронизация с сервисом. Поэтому сначала составьте короткий список того, что у вас реально использует сайт.

Проверьте, подключён ли Jetpack и какие его функции используются.
Посмотрите, есть ли сторонние сервисы публикации или импорта контента.
Уточните у команды, не используют ли они старые мобильные приложения WordPress.
Если сайт корпоративный, проверьте интеграции с CRM или контентными сервисами.

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

Проверка результата после внедрения

После отключения важно убедиться, что endpoint действительно закрыт, а не просто ведёт себя иначе из-за кеша или редиректа.

Откройте /xmlrpc.php в браузере и убедитесь, что он больше не отвечает как рабочий endpoint.
Проверьте заголовки ответа через curl -I https://site.ru/xmlrpc.php.
Если вы блокировали через сервер, проверьте, что запросы не доходят до PHP-логов.
Протестируйте все интеграции, которые могли использовать XML-RPC.

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

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

Отключили XML-RPC, но Jetpack перестал синхронизироваться

Значит, интеграция реально использовала этот канал. Решение простое: либо вернуть доступ, либо перенастроить сценарий работы Jetpack, если это возможно в вашей конфигурации. Не стоит оставлять сайт в поломанном состоянии ради «чистой» безопасности.

Добавили правило в .htaccess, но ничего не изменилось

Часто причина в том, что сайт работает не на Apache, а на Nginx, либо правило стоит не в том месте файла. Ещё один вариант — конфиг перезаписывается панелью хостинга. В таком случае проверяйте именно активный конфиг, а не копию в админке.

Использовали плагин, но endpoint всё ещё отвечает

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

Сломали публикацию из внешнего редактора

Здесь проблема обычно в том, что редактор не умеет работать через REST API, а вы отключили XML-RPC без замены. Перед изменениями проверяйте, чем именно пользуется клиент, а не ориентируйтесь на название приложения.

Что ещё стоит сделать для безопасности

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

ограничить попытки входа в админку;
включить двухфакторную аутентификацию для администраторов;
проверить актуальность ядра, темы и плагинов;
убрать неиспользуемые плагины и темы;
посмотреть, нет ли лишних публичных REST-эндпоинтов от сторонних плагинов.

Если нужен более широкий набор технических чисток, в таких задачах часто помогает Clearfy Pro: он закрывает часть типовых проблем с дублями и лишними элементами сайта, но XML-RPC всё равно лучше контролировать отдельно, потому что это уже вопрос безопасности и совместимости, а не только SEO.

Мини-чек-лист перед отключением

Проверил, используется ли Jetpack или внешняя публикация.
Выбрал способ отключения: код, сервер или плагин.
Сделал бэкап или хотя бы сохранил исходный конфиг.
Проверил доступ к /xmlrpc.php после изменений.
Протестировал все интеграции, которые могли зависеть от XML-RPC.

Если нужен самый безопасный путь для типового сайта, начните с фильтра xmlrpc_enabled в mu-plugin: его легко откатить, он не зависит от темы и не требует сложной инфраструктуры. Если же сайт под нагрузкой или атакой, закрывайте endpoint на уровне веб-сервера и уже потом проверяйте, не осталось ли рабочих сценариев, которым нужен этот интерфейс.