XML-RPC в WordPress часто держат включённым по привычке, хотя для большинства сайтов он не нужен. Проблема в том, что этот интерфейс до сих пор используют старые мобильные клиенты, внешние сервисы публикации и некоторые интеграции. Если отключить его без проверки, можно неожиданно сломать удалённую публикацию, приложения для администрирования и часть автоматизаций.
Ниже — практический разбор: когда XML-RPC действительно стоит отключать, как это сделать безопасно и как убедиться, что сайт не потерял нужные сценарии.
Когда XML-RPC становится лишним
На обычном корпоративном сайте, блоге или проекте с ручным управлением контентом XML-RPC чаще всего не нужен. Если вы не публикуете записи из внешних клиентов и не используете старые интеграции, этот endpoint только расширяет поверхность атаки и добавляет лишний публичный вход в систему.
Типовые признаки, что XML-RPC можно отключать:
- вы работаете только через wp-admin и блоковый редактор;
- нет мобильных приложений или внешних сервисов, которые публикуют записи через WordPress;
- в логах видны частые запросы к
/xmlrpc.phpбез понятной бизнес-логики; - на сайте уже есть REST API, и именно его используют интеграции.
Диагностика: используется ли XML-RPC сейчас
Перед отключением проверьте, не завязан ли на него какой-то процесс. Самая частая ошибка — выключить endpoint на сайте, где редакторы до сих пор публикуют через сторонний клиент или где подключён старый сервис автопостинга.
Что проверить в первую очередь
- логи веб-сервера: запросы к
xmlrpc.php; - настроенные интеграции: IFTTT, старые приложения, внешние CMS-коннекторы;
- мобильные клиенты WordPress, если ими кто-то реально пользуется;
- плагины синхронизации, которые могли быть настроены давно и забыты.
Если доступа к логам нет, можно временно посмотреть обращения через плагин для безопасности или мониторинга запросов. Но не делайте вывод только по отсутствию ошибок в админке: XML-RPC может быть нужен внешнему сервису, который не сообщает о проблеме внутри WordPress.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, как у вас устроен проект. Для небольшого сайта обычно достаточно кода в functions.php или мини-плагина. Если нужен быстрый вариант без разработки, можно использовать плагин безопасности. Если есть доступ к серверу, иногда удобнее закрыть endpoint на уровне веб-сервера.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Код в теме или mu-plugin | Нужен точечный контроль | Прозрачно и без лишних зависимостей | Нужно не забыть про обновления темы |
| Плагин безопасности | Админ не хочет править код | Быстро включается | Лишняя зависимость от плагина |
| Правило на сервере | Есть доступ к nginx/apache | Запросы режутся раньше WordPress | Нужно аккуратно тестировать другие правила |
Вариант 1: отключить XML-RPC через код
Самый понятный способ — отключить обработку запросов на уровне WordPress. Для этого можно использовать фильтр xmlrpc_enabled.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если вы не хотите привязываться к теме, лучше положить этот код в небольшой mu-plugin. Тогда он не исчезнет после смены шаблона.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант отключает сам механизм внутри WordPress. Для большинства сайтов этого достаточно.
Вариант 2: закрыть xmlrpc.php на уровне сервера
Если задача — не просто отключить функциональность, а ещё и убрать лишние обращения к файлу, можно отдать 403 на уровне веб-сервера. Это полезно, когда сайт регулярно сканируют боты.
Для nginx правило может выглядеть так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Этот подход особенно полезен на нагруженных сайтах, потому что запросы не доходят до PHP. Но если у вас есть легитимная интеграция, она тоже перестанет работать.
Вариант 3: использовать плагин безопасности
Если на проекте уже стоит плагин, который умеет отключать XML-RPC, это допустимый вариант для редактора или администратора без доступа к коду. Но я бы не ставил отдельный плагин только ради одной функции, если задача простая.
На практике удобнее, когда отключение XML-RPC идёт как часть общей гигиены сайта: чистка лишних endpoint-ов, ограничение REST там, где это нужно, контроль заголовков и базовая защита админки. В этом сценарии можно смотреть в сторону комплексных решений вроде Clearfy Pro, если вам нужен не один переключатель, а набор технических настроек сайта: Clearfy Pro.
Пошаговое внедрение без сюрпризов
- Проверьте, есть ли внешние интеграции, которые используют XML-RPC.
- Сделайте резервную копию или хотя бы снимок конфигурации.
- Выберите способ отключения: код, сервер или плагин.
- Внедрите изменение сначала на staging, если он есть.
- Проверьте ответ
/xmlrpc.phpи работу админки. - Посмотрите логи на предмет ошибок у внешних сервисов.
Если у вас несколько сайтов на одном сервере, не копируйте правило вслепую. На одном проекте XML-RPC может быть лишним, а на другом — использоваться для синхронизации публикаций.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте https://ваш-домен/xmlrpc.php в браузере или через curl. Если всё закрыто правильно, вы увидите отказ в доступе или сообщение о том, что метод не поддерживается, в зависимости от выбранного способа.
curl -I https://example.com/xmlrpc.phpЧто считать нормальным результатом:
- сервер возвращает
403 Forbidden, если вы закрывали файл на уровне nginx/apache; - WordPress не принимает XML-RPC вызовы, если использован фильтр
xmlrpc_enabled; - в админке и редакторе нет побочных ошибок;
- в логах больше не появляются массовые обращения к endpoint.
Если после отключения сломалась публикация из внешнего клиента, значит, этот сценарий был живым. В такой ситуации не нужно искать «обходной путь» — лучше вернуть XML-RPC и перевести интеграцию на REST API или другой поддерживаемый способ.
Частые ошибки и как их исправить
Отключили в теме, а потом сменили шаблон
Если код лежал в functions.php, он исчезнет после смены темы. Для системной настройки используйте mu-plugin или отдельный мини-плагин.
Закрыли xmlrpc.php, но забыли про внешние сервисы
Симптом простой: публикации из мобильного клиента или автопостинга перестали уходить. Решение — проверить, кто именно использует endpoint, и либо вернуть доступ, либо перевести интеграцию на другой механизм.
Поставили плагин только ради одной функции
Это рабочий, но не всегда рациональный путь. Если задача одна и понятная, код обычно надёжнее и легче в сопровождении. Плагин оправдан, когда он уже нужен для других задач безопасности.
Смешали отключение XML-RPC с блокировкой REST API
Это разные вещи. REST API нужен многим современным сценариям: редактору, интеграциям, мобильным приложениям, внешним сервисам. Не отключайте его без отдельного анализа.
Практические советы по безопасности и производительности
Если сайт регулярно атакуют боты, закрытие XML-RPC на уровне сервера даёт более чистый результат, чем только фильтр в WordPress. Но не стоит считать это полной защитой: это лишь один из лишних входов, а не универсальный щит.
- не храните отключение только в теме;
- проверяйте логи после изменения конфигурации;
- не отключайте REST API без причины;
- если используете плагин безопасности, следите, чтобы его настройки не конфликтовали с кэшем и правилами сервера;
- после правок очищайте кэш страницы и, если нужно, объектный кэш.
Если вам нужен более широкий набор технических настроек WordPress — от чистки лишнего до контроля SEO-элементов и системных опций — удобнее держать это в одном месте, а не разносить по теме и случайным сниппетам.
Когда XML-RPC лучше не трогать
Не отключайте его, если:
- редакторы реально публикуют через сторонние клиенты;
- есть старые интеграции, которые сложно быстро переписать;
- вы не уверены, кто использует endpoint, и не можете проверить логи;
- на проекте есть внешняя автоматизация, завязанная на публикацию через XML-RPC.
В таких случаях сначала инвентаризируйте интеграции, а уже потом принимайте решение. Это дешевле, чем потом искать, почему перестал работать давно забытый сервис.
