XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация или старые интеграции. Проблема не в самом протоколе, а в том, что его убирают без диагностики. Если на сайте нет зависимых сервисов, отключение оправдано: это снижает поверхность атаки и убирает лишний входной путь в админку. Если зависимости есть, нужен более аккуратный сценарий.
Когда XML-RPC действительно стоит отключать
Сначала проверьте, используется ли он вообще. На большинстве современных сайтов XML-RPC не нужен, если вы не публикуете через сторонние клиенты, не синхронизируете контент через старые сервисы и не используете интеграции, которые до сих пор опираются на этот протокол. Отдельно стоит проверить мобильные приложения, старые плагины автопостинга и внешние сервисы мониторинга.
Быстрая диагностика
Откройте URL /xmlrpc.php. Если файл доступен, это еще не значит, что он используется, но это отправная точка. Дальше смотрите логи доступа и запросы к этому endpoint. Если у вас есть серверные логи, ищите обращения к xmlrpc.php за последние дни. Если логов нет, проверьте интеграции вручную: публикация из внешнего клиента, подключение мобильного приложения, автопостинг.
- есть ли публикация через внешние редакторы;
- используется ли мобильное приложение WordPress;
- есть ли старые плагины, которые отправляют запросы через XML-RPC;
- есть ли в логах регулярные обращения к
xmlrpc.php; - не завязаны ли на него сторонние сервисы синхронизации.
Как отключить XML-RPC: код, плагин или сервер
Есть три рабочих подхода. Выбор зависит от того, где вам удобнее управлять правилом и нужен ли быстрый откат. Если вы ведете несколько сайтов, удобнее централизовать это на уровне кода или безопасности-плагина. Если доступ к коду ограничен, можно использовать серверную блокировку, но она требует аккуратности.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Прозрачно, легко откатить, не зависит от внешнего плагина | Нужно не забыть про обновления темы и место размещения |
| Плагин безопасности | Быстро включить, часто есть дополнительные проверки | Лишняя зависимость, иногда слишком агрессивные правила |
| Серверная блокировка | Режет запросы до WordPress, экономит ресурсы | Нужен доступ к конфигу веб-сервера, сложнее тестировать |
Вариант 1: отключение через код
Самый предсказуемый способ — добавить фильтр в mu-plugin или в functions.php дочерней темы. Для постоянного правила лучше использовать mu-plugin, чтобы оно не исчезло после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен более жесткий вариант, можно вернуть 403 на сам файл xmlrpc.php. Но здесь важно не сломать легитимные запросы, если вы не проверили зависимости.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Первый вариант предпочтительнее: он отключает сам механизм WordPress штатно. Второй — уже грубая блокировка, и ее стоит применять только если вы точно понимаете последствия.
Вариант 2: через плагин безопасности
Если вы уже используете плагин для hardening, проверьте, есть ли в нем отдельная опция отключения XML-RPC. Это удобно, когда нужно быстро включить и выключить правило без правки кода. Но не стоит ставить отдельный плагин только ради одной галочки, если задача решается одной строкой кода.
Если вам нужен комплексный набор технических настроек, имеет смысл смотреть в сторону решений, где отключение XML-RPC идет вместе с чисткой лишних endpoint'ов и служебных ссылок. Например, в Clearfy Pro есть набор функций для технической оптимизации и уменьшения лишней поверхности сайта.
Вариант 3: блокировка на сервере
Если у вас Nginx или Apache и доступ к конфигу есть, можно закрыть xmlrpc.php на уровне веб-сервера. Это полезно, когда нужно отсечь запросы до загрузки WordPress. Но перед этим убедитесь, что не используете сервисы, которым нужен этот endpoint.
# Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверная блокировка хороша как дополнительный слой, но не заменяет проверку зависимостей. Если потом понадобится временно вернуть доступ, правка конфигурации должна быть у вас под контролем.
Пошаговое решение без сюрпризов
Надежный порядок такой: сначала инвентаризация, потом мягкое отключение, затем проверка логов и только после этого — более жесткая блокировка, если она действительно нужна.
- Проверьте, кто и как использует XML-RPC на сайте.
- Сделайте бэкап конфигурации и файлов, если меняете серверные правила.
- Отключите XML-RPC через
xmlrpc_enabledили через настройку плагина. - Протестируйте внешние интеграции и мобильные клиенты.
- Если все работает, при необходимости добавьте серверную блокировку.
Если вы ведете несколько сайтов, удобно оформить это как небольшой mu-plugin. Тогда правило не потеряется после обновления темы и не зависит от активного шаблона.
<?php
/**
* Plugin Name: Disable XML-RPC
* Description: Отключает XML-RPC на сайте.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере или выполните запрос через curl. В зависимости от способа блокировки вы увидите либо ответ WordPress о том, что XML-RPC отключен, либо HTTP 403.
curl -I https://example.com/xmlrpc.phpДальше проверьте реальные сценарии:
- публикация из внешнего клиента не проходит, если вы ее отключали намеренно;
- мобильное приложение не теряет доступ, если оно вам нужно;
- в логах больше нет регулярных обращений к
xmlrpc.php; - основные формы, REST API и админка работают как раньше.
Если после отключения что-то сломалось, значит, зависимость была скрытой. В этом случае не возвращайте XML-RPC полностью «потому что так проще» — сначала найдите конкретный сервис, который его использует.
Частые ошибки и как их исправить
Отключили файл, но забыли про интеграции
Самая типичная ошибка — закрыть xmlrpc.php на сервере и только потом обнаружить, что один из сервисов автопубликации перестал работать. Исправление простое: сначала аудит, потом блокировка. Если интеграция нужна, оставьте XML-RPC доступным и ограничьте его другими способами.
Поставили отдельный плагин ради одной функции
Если задача только в отключении XML-RPC, отдельный плагин часто избыточен. Он добавляет еще один слой поддержки и потенциальный источник конфликтов. Код в mu-plugin обычно проще и надежнее.
Сломали обновления темы
Если правило лежало в functions.php родительской темы, после обновления или смены шаблона оно может исчезнуть. Для технических ограничений лучше использовать mu-plugin или отдельный маленький плагин.
Слишком рано включили жесткую серверную блокировку
Когда вы сразу закрываете xmlrpc.php на уровне Nginx или Apache, откат требует доступа к серверу. Для рабочих сайтов безопаснее сначала протестировать отключение через WordPress-фильтр, а потом уже решать, нужен ли более жесткий слой.
Что еще имеет смысл проверить рядом с XML-RPC
Если вы уже занимаетесь технической чисткой сайта, не ограничивайтесь одним endpoint'ом. Посмотрите, нет ли лишних публичных точек входа, старых плагинов автопостинга, неиспользуемых REST-маршрутов от отключенных расширений и мусорных служебных ссылок в <head>. На практике такие мелочи часто дают больше шума, чем один конкретный файл.
Для сайтов, где важны именно SEO и техническая гигиена, удобно держать под рукой инструменты, которые закрывают несколько задач сразу: чистка лишнего кода, отключение дублей и служебных элементов, контроль индексации. Но даже в этом случае проверка должна идти от фактических зависимостей, а не от списка «рекомендуемых настроек».
Если коротко: XML-RPC можно отключать, но только после проверки, что он не нужен вашим интеграциям. Само решение занимает минуту, а вот разбор поломки внешнего сервиса может занять заметно больше времени.