Как отключить XML-RPC в WordPress без поломки публикаций и интеграций

Автор: Руслан Смирнов | Опубликовано: 14.09.2026

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

Когда XML-RPC действительно мешает

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

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

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

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если доступа к логам нет, проверьте сам endpoint из браузера или через curl. Нормально, если файл отвечает текстом про XML-RPC сервер WordPress; после отключения он должен возвращать 403 или 404 в зависимости от способа блокировки.

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

Ещё один практический шаг — вспомнить, какие сервисы подключены к сайту:

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

Как отключить XML-RPC: сравнение подходов

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

Способ	Плюсы	Минусы
Код в `functions.php` или мини-плагине	Просто внедрить, легко откатить	Не блокирует запрос на уровне веб-сервера, а только отключает обработку в WordPress
Правило в Nginx/Apache	Режет доступ раньше, меньше лишней нагрузки	Нужно править конфиг сервера и иметь доступ к нему
Плагин безопасности	Удобно для админов без доступа к серверу	Добавляет ещё один слой логики и зависимость от плагина

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

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

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

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

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

Если у вас Nginx, можно отдать 403 для /xmlrpc.php. Это полезно, когда вы хотите не просто отключить функциональность, а ещё и не тратить ресурсы на обработку запроса.

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

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

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

Если сайт работает за CDN или прокси, проверьте, что блокировка не ломает кэширование и не конфликтует с правилами безопасности на уровне хостинга.

Вариант 3: отключить только pingback, если XML-RPC нужен частично

Иногда XML-RPC нужен для внешнего клиента, но pingback и trackback — нет. Тогда можно точечно убрать pingback, не трогая весь механизм. Это более аккуратный вариант, если вы не уверены, что все интеграции уже переведены на REST API.

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

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

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

Если вы предпочитаете плагин, выбирайте тот, который явно умеет отключать XML-RPC и не навязывает лишние функции. Для сайтов, где одновременно нужно чистить технические дубли, отключать лишние скрипты и убирать мусор из head, иногда удобнее использовать комплексный инструмент вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но если задача только в XML-RPC, код или серверное правило обычно проще и прозрачнее.

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

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

Откройте /xmlrpc.php в браузере или через curl -I.
Убедитесь, что ответ стал 403 или 404, если вы блокировали доступ.
Проверьте, не сломалась ли публикация из мобильного приложения или внешнего клиента.
Посмотрите access log: запросы к xmlrpc.php должны либо исчезнуть, либо получать отказ.
Если у вас включён мониторинг ошибок, проверьте, не появились ли новые записи после изменения.

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

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

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

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

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

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

Заблокировали файл на сервере, но WordPress всё равно отвечает

Так бывает, если правило добавили не в тот виртуальный хост, не в тот .htaccess или запрос обрабатывается через другой слой прокси. Проверьте конфигурацию именно того сервера, который реально принимает запрос.

Отключили XML-RPC, но брутфорс не уменьшился

Это нормально, если атакуют не только через XML-RPC, но и через wp-login.php. В этом случае нужно отдельно смотреть ограничения по логину, rate limiting, двухфакторную аутентификацию и защиту на уровне WAF.

Безопасность и производительность: что ещё стоит сделать рядом

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

ограничение попыток входа;
двухфакторную аутентификацию для админов;
отключение ненужных pingback/trackback, если они не используются;
актуальность ядра, тем и плагинов;
наличие WAF или хотя бы базовых правил на уровне хостинга.

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

Если нужен аккуратный технический аудит сайта после таких изменений, удобно проверять не только endpoint, но и связанные настройки индексации, дубли и лишние элементы в шаблоне. Именно здесь часто всплывают проблемы, которые маскируются под «безопасность», но на деле связаны с общей гигиеной WordPress.