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

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

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

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

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

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

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

  • Проверьте, используется ли Jetpack и какие его модули активны.
  • Посмотрите access log на обращения к xmlrpc.php.
  • Уточните, публикуют ли контент внешние сервисы или приложения.
  • Проверьте, не подключён ли старый мобильный клиент или интеграция через XML-RPC.

Если сомневаетесь, сначала ограничьте доступ на уровне сервера для части запросов, а не удаляйте поддержку полностью. Так проще откатиться.

Как отключить XML-RPC через код

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

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

Добавить код можно в functions.php дочерней темы или в небольшой mu-plugin. Второй вариант надёжнее: он не зависит от темы и не исчезнет после её смены.

Вариант через mu-plugin

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

Файл положите в wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.

Как закрыть xmlrpc.php на уровне сервера

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

Apache: блокировка через .htaccess

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

Такой вариант работает, если сайт обслуживается Apache и .htaccess обрабатывается сервером. После добавления правила запросы к xmlrpc.php должны получать 403.

Nginx: запрет через location

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

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

Что делать, если нужен Jetpack или внешняя публикация

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

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

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

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

После отключения важно не ограничиться «страница открывается». Проверьте именно тот сценарий, который вы меняли.

  1. Откройте /xmlrpc.php в браузере или через curl.
  2. Убедитесь, что ответ соответствует выбранному способу блокировки: 403 на сервере или сообщение об отключении XML-RPC со стороны WordPress.
  3. Проверьте Jetpack, если он установлен.
  4. Попробуйте выполнить ту внешнюю интеграцию, которая раньше использовала XML-RPC.
  5. Посмотрите error log и access log на повторяющиеся ошибки после изменения.

Для быстрой проверки можно использовать curl:

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

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

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

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

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

Добавили правило в .htaccess, но доступ не закрылся

Чаще всего сайт работает не на Apache, а на Nginx, либо правило стоит не в том месте. Проверьте стек сервера и конфигурацию виртуального хоста.

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

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

Поставили код в тему, а после обновления он исчез

Это типичная ошибка. Для системных ограничений используйте mu-plugin или отдельный мини-плагин, а не обычную тему.

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

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

  • ограничение попыток входа;
  • двухфакторную аутентификацию для администраторов;
  • защиту /wp-login.php на уровне WAF или сервера;
  • обновление ядра, тем и плагинов;
  • проверку прав доступа к файлам и каталогам.

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

Главный критерий здесь простой: после изменения сайт должен выполнять только те сценарии, которые вам реально нужны. Всё остальное лучше закрыть, но только после проверки зависимостей.

Как создать пользовательские типы записей в WordPress: подробное руководство
30.11.2025
Как избежать конфликтов между плагинами WordPress: практические советы и решения
04.12.2025
Как отключить XML-RPC в WordPress и не сломать нужные интеграции
07.09.2026
Оптимизация кода WordPress для увеличения производительности
13.11.2025
Обработка форм на WordPress без плагинов: практическое руководство
21.11.2025
×

AI-плагин от WPShop.ru

анализирует конкурентов

пишет статьи

готовит SEO

генерирует изображения

и еще кое-что...
WPGPT
Плагин, который наполняет ваш сайт WordPress
Узнать больше