XML-RPC в WordPress часто отключают по одной причине: через него удобно стучаться в сайт извне, а значит он становится лишней точкой атаки, если вы не используете удалённую публикацию, Jetpack или сторонние сервисы, которым нужен этот интерфейс. Но выключать его «в лоб» стоит не всегда: сначала нужно понять, кто именно его использует на вашем сайте.
Когда XML-RPC можно отключать, а когда нет
Если у вас обычный блог, корпоративный сайт или лендинг, и вы публикуете контент только из админки WordPress, XML-RPC чаще всего не нужен. Если же подключены Jetpack, мобильное приложение WordPress, внешние сервисы автопостинга или интеграции для удалённой публикации, отключение может сломать часть сценариев.
Что обычно ломается после отключения
- мобильное приложение WordPress перестаёт отправлять записи;
- Jetpack может потерять часть функций, завязанных на XML-RPC;
- сервисы автопостинга и планирования публикаций начинают получать ошибки авторизации;
- некоторые старые интеграции с CMS и CRM перестают синхронизироваться.
Диагностика: используется ли XML-RPC на вашем сайте
Перед отключением проверьте, есть ли реальные обращения к /xmlrpc.php. Самый простой способ — посмотреть логи веб-сервера или статистику в панели хостинга. Если доступа к логам нет, можно временно открыть файл в браузере: при включённом XML-RPC WordPress обычно отвечает сообщением о том, что сервер XML-RPC принимает только POST-запросы.
Ещё один практичный признак — ошибки в сторонних сервисах после тестового отключения на staging-копии. Если интеграция не используется, лучше убрать точку входа заранее, чем оставлять её «на всякий случай».
Способ 1: отключить XML-RPC через .htaccess
Этот вариант подходит для Apache или совместимых конфигураций, где WordPress использует .htaccess. Он блокирует прямой доступ к файлу xmlrpc.php на уровне веб-сервера, то есть запросы даже не доходят до WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Если у вас старый Apache 2.2, синтаксис будет другим:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Блок лучше добавлять выше правил WordPress, чтобы он сработал независимо от остальных редиректов. После правки сохраните файл и проверьте, что запросы к /xmlrpc.php получают ответ 403.
Способ 2: отключить XML-RPC через PHP
Если вы не хотите трогать правила сервера или сайт работает на Nginx без .htaccess, можно отключить XML-RPC через код. Самый безопасный вариант — добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот способ отключает сам механизм на уровне WordPress. Он удобен, если у вас несколько окружений и вы хотите управлять поведением из кода, а не из конфигурации веб-сервера.
Что выбрать: .htaccess или PHP
| Способ | Плюсы | Минусы |
|---|---|---|
| .htaccess | Блокирует запросы до WordPress, меньше лишней нагрузки | Работает только на Apache/совместимых серверах |
| PHP-фильтр | Просто внедрить, подходит для любого хостинга | Запрос до WordPress всё равно доходит |
Пошаговое решение без лишнего риска
- Проверьте, используются ли Jetpack, мобильное приложение WordPress или внешние интеграции.
- Сделайте резервную копию файла
.htaccessили подготовьте дочернюю тему/му-plugin. - Выберите один способ отключения: на сервере или через PHP, не смешивайте оба без необходимости.
- После изменения откройте
/xmlrpc.phpи убедитесь, что доступ закрыт. - Проверьте публикацию записи в админке, вход в панель и работу всех подключённых сервисов.
Как проверить, что решение сработало
Проверка должна быть не формальной, а прикладной. Откройте в браузере адрес https://ваш-домен.ru/xmlrpc.php. Если всё сделано через .htaccess, сервер должен вернуть 403 Forbidden. Если использован PHP-фильтр, WordPress не должен показывать рабочий XML-RPC-ответ.
Дополнительно проверьте логи. После отключения в них не должно быть регулярных обращений к xmlrpc.php с успешным ответом 200. Если обращения продолжаются, значит блокировка стоит не там, где нужно, или запросы идут через кэш/прокси, который не учитывает правило.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал работать
Это нормальная ситуация, если Jetpack использует функции, завязанные на XML-RPC. Решение простое: либо вернуть доступ, либо отказаться от конкретных функций Jetpack и оставить блокировку только если они не нужны.
Добавили правило в .htaccess, но доступ не закрылся
Чаще всего причина в том, что сайт работает на Nginx, а .htaccess вообще не используется. В этом случае нужно закрывать /xmlrpc.php в конфигурации Nginx или использовать PHP-фильтр.
Сайт начал отдавать 500 после правки
Обычно это синтаксическая ошибка в .htaccess или вставка кода PHP не в тот файл. Проверьте, что вы не смешали Apache-правила и PHP-код, и верните резервную копию перед повторной правкой.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, лучше закрыть его на уровне сервера. Это уменьшает поверхность атаки и убирает лишние запросы до WordPress. На сайтах с высокой посещаемостью это ещё и небольшой выигрыш по нагрузке, потому что сервер не тратит ресурсы на обработку заведомо ненужных обращений.
Если вы ведёте несколько сайтов и часто включаете/выключаете такие ограничения, удобнее оформить их в отдельный mu-plugin. Тогда правило не потеряется при смене темы и не исчезнет после обновления.
Для комплексной чистки сайта и отключения лишних технических сущностей иногда используют Clearfy Pro, но даже в этом случае полезно понимать, что именно он меняет, и отдельно проверять доступ к xmlrpc.php после настройки.
Если после отключения вы заметили ошибки в интеграциях, не пытайтесь «лечить» их возвратом XML-RPC без анализа. Сначала проверьте, какой сервис реально использует этот канал, и можно ли заменить его REST API или обычным HTTP-вебхуком.