Как отключить XML-RPC и убрать его из robots.txt в WordPress

XML-RPC в WordPress часто отключают не ради «чистоты», а чтобы убрать лишнюю поверхность атаки и не держать открытым старый механизм, который многим сайтам уже не нужен. Но на практике одной строки в коде мало: если просто выключить обработчик, а потом не проверить robots.txt, .htaccess и внешние интеграции, можно получить ложное ощущение безопасности или сломать мобильный клиент, Jetpack или сторонний сервис публикации.

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

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

Если сайт редактируется только через wp-admin и блоковый редактор, а внешние сервисы не используют XML-RPC, этот интерфейс обычно не нужен. Особенно это касается сайтов, где:

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

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

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

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

Проверка ответа endpoint’а

До отключения выполните запрос:

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

Если endpoint открыт, вы обычно увидите ответ сервера, а не 404. Это ещё не значит, что он нужен, но уже показывает, что точка доступа активна.

Дополнительно проверьте, не упоминается ли XML-RPC в robots.txt:

curl -s https://example.com/robots.txt | grep -i xmlrpc

Если там есть правило для xmlrpc.php, его можно убрать вручную или через код, если robots.txt формируется WordPress-ом.

Пошаговое решение: отключаем XML-RPC без лишних побочных эффектов

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

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

Добавьте код в дочернюю тему или в свой мини-плагин:

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

Это самый прямой способ: WordPress перестаёт принимать XML-RPC-запросы на уровне ядра.

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

Если у вас Apache и сайт работает через .htaccess, можно отрезать доступ к файлу до загрузки WordPress:

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

Для nginx логика обычно выносится в конфигурацию виртуального хоста. Пример:

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

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

Вариант 3: убрать XML-RPC из robots.txt

Если robots.txt генерируется WordPress-ом и там есть упоминание xmlrpc.php, можно добавить фильтр и не отдавать это правило поисковикам. Для стандартного виртуального robots.txt WordPress позволяет менять содержимое через robots_txt:

<?php
add_filter( 'robots_txt', function( $output, $public ) {
    $lines = explode( "\n", $output );
    $lines = array_filter( $lines, function( $line ) {
        return stripos( $line, 'xmlrpc.php' ) === false;
    } );

    return implode( "\n", $lines );
}, 10, 2 );

Если robots.txt у вас статический и лежит в корне сайта, правьте его вручную. WordPress не сможет удалить из него строку фильтром.

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

После отключения проверьте не только код ответа, но и поведение сайта в реальных сценариях.

• Откройте /xmlrpc.php в браузере или через curl.
• Убедитесь, что WordPress не принимает XML-RPC-запросы.
• Проверьте robots.txt на отсутствие упоминаний xmlrpc.php.
• Если используете Jetpack, мобильное приложение или внешнюю публикацию, протестируйте их отдельно.

Минимальная проверка через консоль:

curl -I https://example.com/xmlrpc.php
curl -s https://example.com/robots.txt | grep -i xmlrpc

Если серверный запрет настроен правильно, запрос к xmlrpc.php должен завершаться отказом, а не обычным ответом WordPress.

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

Отключили XML-RPC, но забыли про внешний сервис

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

Убрали правило из robots.txt, но endpoint остался открыт

Это не защита, а только косметика. Поисковики и боты ориентируются на robots.txt, но атакующий всё равно может стучаться в /xmlrpc.php напрямую. Нужен именно запрет обработки или блокировка на сервере.

Сломали .htaccess

Если после правки Apache начал отдавать 500, проверьте синтаксис блока <Files> и место вставки. В .htaccess нельзя бездумно смешивать правила разных модулей. При сомнениях сначала тестируйте на staging-сайте.

Ожидали, что плагин безопасности всё сделает сам

Некоторые плагины действительно умеют отключать XML-RPC, но не всегда убирают его из robots.txt или не блокируют запросы на уровне веб-сервера. Если нужен предсказуемый результат, лучше понимать, какой именно слой защиты вы включили.

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

Если XML-RPC вам не нужен, лучше отключить его на уровне сервера и дополнительно оставить фильтр в WordPress. Это снижает шанс, что кто-то случайно вернёт endpoint при смене темы или отключении плагина.

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

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

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