XML-RPC в WordPress часто отключают по одной причине: его не используют, но он остаётся лишней точкой входа для брутфорса и шумных запросов. При этом у многих сайтов на нём держатся внешние публикации, мобильные клиенты, старые интеграции и часть сервисов синхронизации. Поэтому задача не в том, чтобы «вырубить всё подряд», а в том, чтобы сначала понять, нужен ли endpoint вообще, а потом закрыть его так, чтобы не сломать рабочие сценарии.
Ниже — два рабочих способа: через серверный запрет в .htaccess и через PHP-фильтр в теме или мини-плагине. Первый вариант жёстче и быстрее, второй удобнее, если нужен управляемый код без правок конфигурации веб-сервера.
Когда XML-RPC можно отключать без риска
Если сайт живёт только в браузере, публикация идёт через админку WordPress, а внешние сервисы не используют xmlrpc.php, отключение обычно безопасно. Но это нужно не предполагать, а проверить. На практике проблемы всплывают у сайтов, где подключены:
- мобильное приложение WordPress;
- Jetpack и похожие сервисы, которые завязаны на удалённый доступ;
- старые интеграции для публикации по API;
- внешние редакторы и планировщики постов;
- сервисы мониторинга, которые обращаются к WordPress через XML-RPC.
Если хотя бы один из этих сценариев есть, сначала тестируйте на staging-копии. На боевом сайте отключение без проверки может выглядеть как «всё работает», пока не придёт первая автоматическая публикация или синхронизация.
Диагностика: нужен ли вам xmlrpc.php
Самый простой способ — открыть /xmlrpc.php в браузере. Если endpoint доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не ошибка, а признак того, что файл жив и отвечает.
Дальше проверьте логи и интеграции:
- есть ли обращения к
xmlrpc.phpв access log; - использует ли сайт Jetpack или внешние публикации;
- есть ли мобильные клиенты WordPress у редакторов;
- не настроены ли автопостинг и синхронизация через старые плагины;
- не завязаны ли на XML-RPC сторонние CRM или планировщики.
Если вы не уверены, временно ограничьте доступ только на тестовой копии и посмотрите, не появятся ли ошибки в интеграциях. Это лучше, чем сразу закрывать endpoint на проде и потом искать, почему перестали отправляться материалы.
Способ 1: запретить XML-RPC через .htaccess
Если сервер работает на Apache или совместимом стеке и вы можете править .htaccess, это самый прямой вариант. Он блокирует запросы ещё до загрузки WordPress, поэтому экономит ресурсы и не даёт endpoint’у отвечать вообще.
Добавьте правило в начало или рядом с другими правилами безопасности:
<Files xmlrpc.php>
Require all denied
</Files>Если у вас старый Apache 2.2, синтаксис может быть другим:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Этот способ хорош тем, что не зависит от темы и плагинов. Но есть нюанс: если хостинг использует Nginx перед Apache, блокировку иногда удобнее делать на уровне Nginx-конфигурации. Если доступа к серверной конфигурации нет, переходите к PHP-варианту ниже.
Способ 2: отключить XML-RPC через PHP-фильтр
Если вы не хотите трогать серверные правила, можно отключить XML-RPC через код. Для этого подойдёт мини-плагин или functions.php дочерней темы. Я бы не советовал вносить такое изменение в родительскую тему: при обновлении оно потеряется.
Пример для мини-плагина:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый короткий и понятный вариант. WordPress перестанет отдавать XML-RPC как доступный механизм, а попытки обращения к endpoint будут блокироваться на уровне ядра.
Если вам нужно не просто отключить XML-RPC, а ещё и убрать конкретные методы, можно использовать фильтр xmlrpc_methods. Но для обычной задачи это избыточно: проще и надёжнее отключить всё целиком, если endpoint не нужен.
Что выбрать: .htaccess, PHP или плагин безопасности
| Вариант | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| .htaccess | Есть доступ к Apache-конфигу | Блокирует запросы до WordPress, меньше нагрузки | Не работает на всех стеках, нужен доступ к серверу |
| PHP-фильтр | Нужен переносимый код | Просто внедрить, легко откатить | WordPress всё равно загрузится до блокировки |
| Плагин безопасности | Нужен интерфейс и централизованные настройки | Удобно для админов, меньше ручных правок | Лишняя зависимость, иногда дублирует функции |
Если сайт небольшой и у вас есть доступ к серверу, я бы начинал с .htaccess. Если проект поддерживается через кодовую базу и деплой, удобнее держать запрет в мини-плагине.
Пошаговое решение без сюрпризов
1. Проверьте, не используется ли XML-RPC
Сначала отключите только на staging или в рабочее время с возможностью быстрого отката. Зафиксируйте, какие сервисы подключены к сайту, и протестируйте публикацию, авторизацию и синхронизацию.
2. Выберите способ блокировки
Если есть доступ к серверу — используйте .htaccess. Если нет — добавьте фильтр xmlrpc_enabled в мини-плагин. Не смешивайте оба способа без необходимости: для диагностики потом сложнее понять, что именно блокирует запрос.
3. Очистите кеш
После изменения правил обязательно очистите кеш страницы, серверный кеш и кеш CDN, если он есть. Иначе можно увидеть старый ответ и решить, что правило не сработало.
4. Проверьте доступ к endpoint
Откройте /xmlrpc.php напрямую. При корректной блокировке вы должны получить отказ в доступе или пустой ответ в зависимости от способа. Если endpoint продолжает отвечать как раньше, значит правило не применилось или его перебивает другая конфигурация.
Проверка результата после внедрения
Проверять нужно не только браузером. Лучше пройтись по нескольким сценариям:
- открыть
/xmlrpc.phpнапрямую и убедиться, что доступ закрыт; - посмотреть access log и убедиться, что endpoint не отвечает 200;
- проверить вход в админку и публикацию постов вручную;
- если есть внешние сервисы, протестировать их подключение;
- посмотреть, не выросло ли число ошибок в логах после изменения.
Для быстрой проверки через терминал можно использовать curl:
curl -I https://example.com/xmlrpc.phpЕсли вы видите 403 Forbidden, запрет сработал. Если приходит обычный ответ WordPress, правило не применилось или его нужно перенести в другое место конфигурации.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали Jetpack
Это типичный сценарий. Jetpack и похожие сервисы могут использовать удалённые вызовы, поэтому перед отключением проверьте, не завязана ли на XML-RPC статистика, публикация или синхронизация. Если сервис нужен, не блокируйте endpoint целиком — ищите точечное ограничение на уровне безопасности или пересматривайте саму интеграцию.
Правило в .htaccess не сработало
Причина обычно одна из трёх: сайт работает не на Apache, правило стоит ниже конфликтующего блока, либо хостинг переписывает конфигурацию. В таком случае проверьте серверный стек и попробуйте PHP-вариант.
Всё отключили, но endpoint по-прежнему отвечает
Часто виноват кеш или прокси перед сайтом. Очистите кеш на уровне плагина, сервера и CDN. Если используется Nginx, проверьте его правила отдельно: Apache-фрагмент может вообще не участвовать в обработке запроса.
Добавили код в родительскую тему
После обновления темы правило исчезнет. Для таких задач используйте мини-плагин или дочернюю тему. Это особенно важно, если сайт обслуживается не одним разработчиком.
Безопасность и производительность: что ещё стоит учесть
Отключение XML-RPC не заменяет нормальную защиту входа. Если у вас слабые пароли, открытая регистрация или нет ограничений на попытки входа, брутфорс найдёт другой путь. Поэтому вместе с запретом XML-RPC обычно имеет смысл проверить:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальность ядра, темы и плагинов;
- наличие лишних пользователей с правами администратора;
- логи безопасности и подозрительные запросы.
Если задача шире и вы регулярно чистите сайт от дублей, лишних точек входа и технического мусора, удобно держать это в одном наборе настроек. В такой связке часто используют Clearfy Pro: он закрывает часть типовых технических проблем WordPress, включая SEO-дубли и лишние функции, без ручного разбрасывания по коду. Но даже в этом случае важно понимать, что именно отключается, а не включать всё подряд.
Когда лучше не отключать XML-RPC полностью
Если сайт активно работает с внешними клиентами, мобильными приложениями или автоматизированной публикацией, полный запрет может быть слишком грубым. В таких случаях безопаснее сначала ограничить доступ на уровне WAF, настроить защиту от брутфорса и только потом решать, нужен ли полный отказ от XML-RPC. Для старых проектов это часто единственный способ не сломать рабочие процессы.
Практический ориентир простой: если вы не можете назвать хотя бы один сервис, который использует XML-RPC, скорее всего, endpoint можно закрыть. Если можете — сначала проверьте интеграцию на тестовой копии и только потом вносите изменения на проде.