Как запретить отображение xmlrpc.php в WordPress и убрать его из открытых запросов

Автор: Олеся Семенова | Опубликовано: 24.08.2026

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

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

Когда xmlrpc.php действительно стоит отключать

Сначала проверьте сценарии, которые завязаны на XML-RPC. Если хотя бы один из них используется, блокировать файл без замены нельзя:

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

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

Диагностика: как понять, что файл открыт и кто его дергает

Начните с простой проверки ответа сервера. Это покажет, доступен ли файл извне и как именно он отвечает.

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

Нормальные варианты ответа для открытого файла — 200 OK или 405 Method Not Allowed на запросы без нужного метода. Если вы уже что-то блокировали, можете увидеть 403 Forbidden или 404 Not Found.

Полезно посмотреть и логи веб-сервера. На практике именно там видно, идёт ли массовый перебор:

# Apache/Nginx access log — ищем обращения к xmlrpc.php
# пример фильтрации
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20

Если запросы идут пачками с одинаковых IP или с большим числом POST, блокировка на уровне сервера даст больше эффекта, чем только фильтр внутри WordPress.

Как отключить XML-RPC в WordPress кодом

Если нужен мягкий вариант без правок конфигурации сервера, можно отключить обработку XML-RPC из WordPress. Это удобно, когда у вас нет доступа к .htaccess или конфигу Nginx, но есть возможность добавить код в тему или мини-плагин.

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

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

Когда этого недостаточно

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

Блокировка xmlrpc.php на сервере: Apache и Nginx

Это основной способ, если задача — убрать файл из открытых запросов. Он не зависит от темы, плагинов и состояния WordPress.

Apache через .htaccess

Если сайт работает на Apache, добавьте правило в корень сайта, в .htaccess:

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

Такой вариант проще и чище, чем попытки ловить запросы через rewrite. Он прямо запрещает доступ к файлу.

Nginx через конфигурацию сайта

Для Nginx используйте отдельное правило в блоке server:

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

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

Сравнение подходов: код, сервер, плагин

Подход	Что делает	Плюсы	Минусы
Фильтр `xmlrpc_enabled`	Отключает обработку в WordPress	Быстро, без доступа к серверу	Файл остаётся доступным извне
Правило в Apache/Nginx	Блокирует доступ к файлу	Лучше для безопасности и логов	Нужен доступ к конфигу
Плагин безопасности	Отключает или ограничивает XML-RPC	Удобно для админов без кода	Лишняя зависимость, не всегда точечная настройка

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

Пошаговое решение без лишних рисков

Проверьте, нужен ли XML-RPC вашим интеграциям.
Сделайте резервную копию конфигурации и файлов.
Добавьте фильтр xmlrpc_enabled в мини-плагин или functions.php.
Если есть доступ к серверу, закройте xmlrpc.php через Apache или Nginx.
Очистите кеш сайта и кеш на уровне CDN, если он есть.
Проверьте ответ на /xmlrpc.php и посмотрите логи.

Мини-плагин удобнее, чем правка темы: он не исчезнет после обновления шаблона. Пример:

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

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

Проверка должна быть не только визуальной. Нужны минимум три шага:

выполните curl -I https://example.com/xmlrpc.php и убедитесь, что доступ закрыт;
попробуйте отправить POST-запрос на файл и проверьте, что сервер отвечает отказом;
посмотрите access log через 10–15 минут и убедитесь, что обращения к файлу не проходят дальше веб-сервера.

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

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

Отключили XML-RPC, но забыли про мобильное приложение

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

Добавили правило не в тот блок конфигурации

На Nginx правило должно быть внутри нужного server-блока. Если добавить его в общий include без понимания порядка загрузки, можно не получить ожидаемого эффекта. После правки всегда проверяйте конфиг командой nginx -t.

Скрыли файл, но не закрыли доступ

Удаление ссылок, noindex и даже отсутствие упоминаний в sitemap не мешают ботам обращаться к xmlrpc.php напрямую. Это не SEO-задача, а задача безопасности и снижения нагрузки.

Не очистили кеш после изменений

Если на сайте стоит кеширующий плагин или CDN, старые ответы могут сохраняться. После блокировки обязательно сбросьте кеш страницы и, если нужно, кеш на уровне прокси.

Что ещё стоит отключить вместе с XML-RPC

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

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

Практический чек-лист перед выкладкой

Проверен реальный сценарий использования XML-RPC.
Есть резервная копия конфигурации.
Добавлен фильтр xmlrpc_enabled или серверное правило.
Проверен ответ /xmlrpc.php через curl.
Очищен кеш WordPress и CDN.
Просмотрены логи на предмет повторных обращений.

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