Как отключить XML-RPC в WordPress и не сломать приложение или Jetpack

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

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

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

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

Не отключайте его вслепую, если у вас есть хотя бы один из этих сценариев:

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

Диагностика: как понять, используется ли xmlrpc.php

Самый простой способ — посмотреть логи веб-сервера или статистику запросов. Если к /xmlrpc.php идут регулярные обращения, это уже повод проверить источник. На живом сайте полезно сначала посмотреть, не завязаны ли на него реальные клиенты, а уже потом резать доступ.

Быстрая проверка через ответ сервера

Откройте https://example.com/xmlrpc.php в браузере или выполните запрос из консоли. Нормальный ответ WordPress — сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это значит, что файл доступен.

curl -I https://example.com/xmlrpc.php

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

Проверка зависимостей

Перед отключением пройдитесь по чек-листу:

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

Как отключить XML-RPC: три рабочих варианта

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

Способ	Плюсы	Минусы
Код в теме или mu-plugin	Прозрачно, легко откатить, не требует отдельного плагина	Нужно помнить о дочерней теме или mu-plugin
Отключение на сервере	Режет запросы раньше WordPress, меньше нагрузки	Зависит от стека: Apache, Nginx, конфигурация хостинга
Плагин безопасности	Быстро для админов без доступа к коду	Добавляет ещё один слой логики и зависимость от плагина

Вариант 1: отключить XML-RPC через фильтр

Это самый аккуратный способ, если вы контролируете код сайта. Добавьте в functions.php дочерней темы или в собственный mu-plugin:

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

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

Вариант 2: закрыть xmlrpc.php на уровне сервера

Если вы хотите отсечь запросы до загрузки WordPress, можно настроить сервер. Для Apache часто используют правило в .htaccess:

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

Для Nginx логика обычно задаётся в конфигурации сайта. Точный блок зависит от вашей схемы, но смысл один: запросы к xmlrpc.php должны получать отказ до передачи в PHP. Это особенно полезно на нагруженных сайтах, где лишние запросы к PHP-FPM не нужны.

Вариант 3: использовать плагин безопасности

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

Пошаговое решение без лишних рисков

Если нужен практический порядок действий, лучше идти так:

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

Если вы ведёте сайт через Git или деплой, кодовый вариант обычно удобнее: он прозрачен, не зависит от интерфейса хостинга и легко отслеживается в истории изменений.

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

После внедрения проверьте не только сам URL, но и побочные эффекты. Нужен именно рабочий контроль, а не визуальная галочка.

Проверка ответа сервера

Выполните запрос:

curl -i https://example.com/xmlrpc.php

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

Проверка логов и интеграций

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

Отдельно проверьте:

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

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

Отключили XML-RPC, а потом перестал работать Jetpack

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

Закрыли файл в .htaccess, но запросы всё равно проходят

Так бывает на Nginx или при нестандартной конфигурации хостинга. .htaccess работает только там, где Apache действительно читает этот файл. Если сервер другой, правило нужно переносить в его конфигурацию или закрывать доступ через код WordPress.

Поставили плагин, а защита исчезла после обновления

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

Сломали удалённую публикацию, о которой никто не знал

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

Что делать, если нужен не полный запрет, а ограничение доступа

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

Если задача не в полном запрете, а в снижении шума и дублей в технической части сайта, иногда полезнее смотреть шире: чистка лишних функций, отключение ненужных эндпоинтов, контроль индексации и защита админки. Для таких задач уместны инструменты вроде Clearfy Pro, если вам нужен набор типовых технических настроек в одном месте: https://wpshop.ru/plugins/clearfy?utm_source=wpfaq.ru&utm_medium=article&utm_campaign=otklyuchit-xmlrpc-v-wordpress.

Практический минимум для безопасного отключения

сначала проверьте зависимости, потом отключайте;
предпочитайте серверный запрет, если есть доступ к конфигу;
для WordPress-кода используйте дочернюю тему или mu-plugin;
после изменений обязательно тестируйте /xmlrpc.php и реальные интеграции;
не полагайтесь только на плагин, если сайт критичен по безопасности.

Если после отключения XML-RPC сайт работает как раньше, а запросы к xmlrpc.php больше не проходят, значит задача решена правильно. Если же что-то отвалилось, проблема почти всегда в забытом внешнем клиенте или в слишком грубом способе блокировки. В таких случаях лучше вернуться на шаг назад и закрывать доступ точечно, а не «рубить» всё без разбора.