Как отключить xmlrpc.php в WordPress через functions.php и вернуть 403 без лишних рисков

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

Если на сайте не используются мобильное приложение WordPress, Jetpack, внешние публикации через XML-RPC и старые интеграции, xmlrpc.php чаще всего остается лишней точкой входа. Закрыть его можно без правок .htaccess или nginx-конфига — через фильтры WordPress. Это удобно, когда доступ есть только к теме, mu-plugin или обычному плагину.

Ниже разберем именно этот сценарий: как отключить XML-RPC на уровне WordPress, отдать 403 Forbidden вместо «тихого» ответа и не сломать то, что реально может зависеть от этого интерфейса.

Когда этот способ подходит

Метод имеет смысл, если вы хотите закрыть XML-RPC без вмешательства в сервер. Это рабочий вариант для хостинга с ограниченным доступом, для проектов, где изменения надо вносить быстро, и для случаев, когда вы не хотите держать отдельную настройку в Apache/nginx.

Что важно проверить до отключения

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

Диагностика: как понять, нужен ли XML-RPC вообще

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

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

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

Если у вас есть доступ к логам, посмотрите запросы к этому URL за последние дни или недели. Если там только сканеры и брутфорс, а не реальные клиенты, закрывать endpoint можно без сожалений.

Как отключить xmlrpc.php через WordPress

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

Ниже — рабочий вариант, который отключает XML-RPC и одновременно возвращает 403 для прямых обращений к xmlrpc.php.

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

add_filter( 'wp_headers', function( $headers ) {
    if ( isset( $_SERVER['SCRIPT_NAME'] ) && false !== strpos( $_SERVER['SCRIPT_NAME'], 'xmlrpc.php' ) ) {
        $headers['X-Robots-Tag'] = 'noindex, nofollow';
    }

    return $headers;
} );

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

Здесь ключевая часть — xmlrpc_enabled. Она отключает сам механизм. Дополнительная проверка с 403 полезна, если вы хотите, чтобы при прямом обращении к файлу сервер не отдавал «живой» ответ.

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

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

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

Почему не всегда стоит просто удалять файл

Удаление или переименование xmlrpc.php на сервере выглядит жестко, но это не лучший путь. WordPress и плагины ожидают стандартную структуру файлов, а ручные правки в ядре плохо переживают обновления и восстановление из бэкапа.

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

Подход	Плюсы	Минусы
Фильтр `xmlrpc_enabled`	Просто откатить, не зависит от веб-сервера	Endpoint может оставаться доступным на уровне файла
Правка `.htaccess` / nginx	Жестко закрывает запросы до WordPress	Нужен доступ к серверу, выше риск ошибки конфигурации
Удаление файла	Быстро и радикально	Плохая практика, неудобно поддерживать

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

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

Что проверить вручную

открывается ли /xmlrpc.php в браузере;
что возвращает curl -I https://example.com/xmlrpc.php;
не ругается ли Jetpack, если он установлен;
работает ли обычный вход в админку и публикация записей;
нет ли ошибок в debug.log, если включен WP_DEBUG.

Если вы ожидаете именно 403, а получаете 200 или 405, значит фильтр не сработал или код добавлен не туда. Частая причина — правка сделана в неактивной теме или в файле, который не загружается на фронтенде.

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

Код добавили в родительскую тему

После обновления темы настройка исчезает. Перенесите код в дочернюю тему или mu-plugin.

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

Значит, у вас реально был зависимый сценарий. Верните фильтр назад и сначала проверьте, какие функции Jetpack нужны именно этому сайту. Иногда достаточно закрыть только brute-force, а не весь endpoint.

Ожидали 403, но сервер отдает 404

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

Код вставили в произвольный плагин и сломали админку

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

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

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

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

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

Когда лучше выбрать серверную блокировку

Если у вас есть доступ к nginx или Apache и вы хотите отрезать запросы раньше, чем они попадут в WordPress, серверная блокировка будет жестче и дешевле по ресурсам. Но это уже другой уровень ответственности: одна ошибка в конфиге может затронуть весь сайт. Для большинства редакционных и клиентских проектов фильтр WordPress — более безопасная отправная точка.

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

⭐⭐⭐⭐⭐