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

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

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

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

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

Типичные причины для отключения:

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

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

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

Диагностика: как понять, используется ли XML-RPC сейчас

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

1. Посмотрите access log и найдите обращения к /xmlrpc.php.
2. Проверьте, используете ли вы Jetpack, мобильное приложение WordPress или сторонний сервис автопостинга.
3. Откройте https://example.com/xmlrpc.php в браузере: если XML-RPC включён, обычно увидите сообщение о том, что сервер принимает только POST-запросы.

Если у вас есть staging-копия, лучше сначала отключить XML-RPC там и проверить сценарии публикации, чем делать это сразу на боевом сайте.

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

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

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

Пошаговое решение через код

Самый предсказуемый вариант — добавить небольшой код в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Так вы не потеряете настройку при обновлении темы.

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

add_filter( 'wp_headers', function( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

add_action( 'init', function() {
    if ( isset( $_SERVER['REQUEST_URI'] ) && strpos( $_SERVER['REQUEST_URI'], 'xmlrpc.php' ) !== false ) {
        status_header( 403 );
        exit;
    }
} );

Первый фильтр отключает сам XML-RPC на уровне WordPress. Второй убирает заголовок X-Pingback, который часто остаётся даже после отключения. Третий блок — дополнительная защита на случай прямого обращения к файлу. Его можно использовать, если вы хотите жёстко закрыть доступ именно из WordPress, но не заменять им серверные правила.

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

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'wp_headers', function( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

Если нужен быстрый способ без кода

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

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

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

После отключения не ограничивайтесь тем, что сайт открывается в браузере. Проверьте именно те точки, которые могли зависеть от XML-RPC.

• Откройте /xmlrpc.php напрямую: доступ должен быть закрыт или не давать рабочий ответ.
• Проверьте заголовки ответа через DevTools или curl -I https://example.com: заголовок X-Pingback не должен возвращаться.
• Если используете внешнюю публикацию, попробуйте создать тестовую запись из этого сервиса.
• Посмотрите access log через 24 часа: количество обращений к xmlrpc.php должно упасть до нуля или почти до нуля.

Пример проверки через командную строку:

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

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

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

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

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

Скрыли проблему только на уровне WordPress, но не на сервере

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

Удалили заголовок X-Pingback, но файл всё ещё доступен

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

Внесли код в родительскую тему

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

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

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

• не нужен ли вам wp-json для внешних интеграций;
• не включён ли pingback, если он не используется;
• нет ли лишних плагинов, которые открывают собственные публичные эндпоинты без необходимости;
• не стоит ли ограничить частоту запросов к админке и wp-login.php на уровне сервера или через WAF.

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