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

Автор: Алексей Жуков | Опубликовано: 30.08.2026

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

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

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

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

Чаще всего XML-RPC можно убрать, если у вас нет:

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

Что именно ломается при отключении

Отключение XML-RPC не влияет на обычную работу сайта, но может остановить:

публикацию и редактирование записей из внешнего клиента;
удалённые вызовы pingback/trackback, если они ещё используются;
часть функций плагинов, которые обращаются к xmlrpc.php напрямую.

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

Диагностика: как понять, нужен ли XML-RPC именно вам

Начните не с кода, а с проверки фактов. На практике это занимает несколько минут и сразу показывает, есть ли зависимость.

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

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

Способы отключения: плагин, код, сервер

Есть три практических подхода. Выбор зависит от того, нужен ли вам полный запрет или только снижение риска.

Способ	Когда подходит	Плюсы	Минусы
Плагин безопасности	Нужно быстро закрыть доступ без правки кода	Просто включить, часто есть дополнительные проверки	Лишняя зависимость, настройки могут конфликтовать
Код в теме или MU-плагине	Нужен контролируемый вариант без тяжёлых плагинов	Прозрачно, легко сопровождать	Нужно не забыть про обновления и место подключения
Правило на сервере	Нужна блокировка ещё до загрузки WordPress	Меньше нагрузки, быстрее отсекает запросы	Требует доступа к конфигу nginx/apache

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

Если вам нужен предсказуемый вариант, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой MU-плагин. Так код не потеряется при смене темы.

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

Это отключает сам XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно, если нет внешних клиентов и старых интеграций.

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

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

Для nginx можно использовать отдельное правило в конфигурации сайта:

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

Для Apache обычно используют правило в .htaccess или в конфиге виртуального хоста:

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

Серверный вариант хорош тем, что запросы не доходят до WordPress и не тратят ресурсы PHP-FPM. Но если у вас есть зависимые сервисы, они тоже перестанут работать сразу и без предупреждения.

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

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

Пошаговое решение без сюрпризов

Ниже — безопасный порядок действий, который подходит для большинства проектов.

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

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

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

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

Откройте /xmlrpc.php напрямую: при серверной блокировке должен быть отказ в доступе, при отключении через WordPress — ответ без возможности использования метода.
Проверьте логи: новых запросов к xmlrpc.php после изменения быть не должно, либо они должны получать отказ на уровне сервера.
Попробуйте выполнить публикацию из того внешнего инструмента, который вы реально используете, если он есть.
Убедитесь, что REST API и обычная авторизация в админке работают как раньше.

Если вы используете мониторинг, добавьте отдельную проверку на доступность /xmlrpc.php. Так вы быстро заметите, если правило случайно убрали при деплое.

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

Отключили XML-RPC, но забыли про Jetpack

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

Спрятали проблему плагином, но не закрыли доступ

Бывает, что плагин только ограничивает методы, а сам файл остаётся доступным. Для безопасности это слабее, чем серверная блокировка. Если атаки продолжаются, лучше закрыть xmlrpc.php на уровне nginx или Apache.

Сломали внешнюю публикацию и не поняли почему

Частая причина — забытый старый сервис автопостинга. Ищите не только в WordPress, но и в сторонних кабинетах, где могли быть сохранены логин и пароль администратора.

Отключили в теме, а потом сменили дизайн

Если код лежит в functions.php активной темы, при смене темы защита исчезнет. Для таких задач лучше использовать MU-плагин или отдельный мини-плагин.

Практические советы по безопасности и производительности

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

ограничить попытки входа в админку;
использовать сложные пароли и 2FA для администраторов;
проверить, не открыт ли xmlrpc.php через CDN или прокси с обходом правил;
убрать ненужные старые плагины, которые могут обращаться к устаревшим endpoint'ам.

Если вам нужен не только ручной контроль, но и системная чистка лишних функций WordPress, можно посмотреть в сторону инструментов вроде Clearfy Pro: у него есть набор настроек для отключения ненужных возможностей и уменьшения технического шума на сайте. Но даже в этом случае логи и проверка зависимостей остаются обязательными.

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