XML-RPC в WordPress часто отключают по двум причинам: лишняя поверхность атаки и ненужные запросы к сайту. Но если сделать это без проверки, можно сломать внешние публикации, мобильные приложения или интеграции, которые до сих пор используют этот интерфейс. Поэтому здесь важен не сам факт отключения, а понимание, кто именно обращается к /xmlrpc.php и нужен ли он вам вообще.
Когда XML-RPC действительно можно отключать
Если сайт живёт на обычной админке, а публикация идёт только через браузер, XML-RPC чаще всего не нужен. Но перед изменениями стоит проверить, нет ли зависимостей. Самые частые сценарии, где он ещё используется: старые мобильные клиенты WordPress, внешние сервисы автопостинга, некоторые интеграции с десктопными редакторами и редкие плагины синхронизации.
Что проверить до отключения
- используете ли вы приложение WordPress на телефоне для публикации;
- есть ли внешние сервисы, которые отправляют записи через XML-RPC;
- настроены ли интеграции с Jetpack или похожими сервисами, если они работают через этот канал;
- есть ли в логах регулярные обращения к
/xmlrpc.phpот ваших же систем; - не завязаны ли на XML-RPC редкие сценарии удалённого редактирования контента.
Диагностика: как понять, нужен ли XML-RPC именно вам
Самый практичный способ — посмотреть, кто обращается к файлу xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это даст более точную картину, чем догадки. В логах ищите POST-запросы к этому пути и оцените IP, частоту и user-agent.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если доступа к серверу нет, можно временно включить логирование на уровне безопасности или посмотреть статистику в панели хостинга. Важен не только факт обращений, но и их источник. Если это боты и сканеры, отключение обычно не ломает рабочие сценарии. Если это ваш сервис или приложение — сначала меняйте интеграцию, потом отключайте XML-RPC.
Пошаговое решение: как отключить XML-RPC безопасно
Есть три рабочих подхода: через код, через сервер и через плагин безопасности. Для большинства проектов удобнее начать с кода, потому что это прозрачно и легко откатить.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Код в теме или mu-plugin | Нужен контролируемый и обратимый вариант | Просто проверить и убрать | Надо не забыть про обновления темы |
| Правило на сервере | Есть доступ к nginx/apache и нужен жёсткий запрет | Срабатывает раньше WordPress | Сложнее сопровождать |
| Плагин безопасности | Уже используется security-плагин | Удобно для админов без кода | Лишняя зависимость от плагина |
Вариант 1: отключить XML-RPC через код
Добавьте код в functions.php дочерней темы или, что лучше, в небольшой mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает сам XML-RPC на уровне WordPress. Если кто-то попытается обратиться к /xmlrpc.php, система не будет обрабатывать запрос как обычно.
Вариант 2: запретить доступ на уровне сервера
Если нужен более жёсткий вариант, можно закрыть сам файл на уровне веб-сервера. Для Apache это обычно делается через .htaccess, для nginx — через правило в конфигурации сайта. Ниже пример для Apache:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика зависит от конфигурации, но суть одна: вернуть 403 на запрос к /xmlrpc.php. Это полезно, если вы хотите отсечь обращения ещё до загрузки WordPress.
Вариант 3: использовать плагин безопасности
Если у вас уже стоит security-плагин, проверьте, есть ли в нём отдельная опция для XML-RPC. Это удобно, когда администратор не хочет править код. Но не стоит ставить отдельный плагин только ради одной галочки: лишний плагин — это ещё одна точка обслуживания и потенциальный конфликт.
Как проверить, что отключение сработало
После изменения нужно проверить не только страницу в браузере, но и сам endpoint. Откройте /xmlrpc.php напрямую или выполните запрос из консоли. Если всё сделано правильно, вы не должны получать обычный ответ XML-RPC.
curl -I https://example.com/xmlrpc.phpОжидаемое поведение зависит от способа блокировки: либо 403 Forbidden на уровне сервера, либо ответ WordPress без активного XML-RPC. Дополнительно проверьте, не сломались ли ваши рабочие сценарии: публикация из мобильного приложения, внешние интеграции, синхронизация контента.
Чек-лист проверки
- страницы сайта открываются без ошибок после изменения;
/xmlrpc.phpне отвечает как рабочий XML-RPC endpoint;- в логах нет критичных ошибок, связанных с отключением;
- мобильное приложение WordPress, если оно используется, не требует XML-RPC для ваших задач;
- внешние сервисы автопостинга или синхронизации не потеряли связь.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли интеграцию
Это типичная ошибка, когда сначала закрывают доступ, а потом вспоминают про внешнюю систему. Исправление простое: верните доступ, найдите конкретный сервис, который использует XML-RPC, и переведите его на другой способ интеграции, если он есть. Если альтернативы нет, оставьте XML-RPC включённым и ограничьте доступ на уровне IP или WAF.
Добавили код в родительскую тему
После обновления темы настройка исчезает. Для таких правок лучше использовать дочернюю тему или mu-plugin. Это не только надёжнее, но и проще для аудита: видно, какие изменения относятся к инфраструктуре сайта, а не к дизайну.
Закрыли файл на сервере, но не проверили логи
В результате можно не заметить, что какой-то внутренний сервис начал получать 403 и перестал публиковать данные. После блокировки обязательно смотрите access- и error-логи хотя бы в первые дни.
Поставили плагин безопасности и забыли про другие меры
Отключение XML-RPC не заменяет обновления WordPress, контроль прав пользователей и ограничение попыток входа. Если сайт уже атакуют, одна настройка проблему не решит. Нужна связка: обновления, сильные пароли, ограничение логинов и нормальная политика плагинов.
Безопасность и производительность: что ещё имеет смысл сделать рядом
Если вы отключаете XML-RPC ради безопасности, логично проверить и другие точки входа. Например, убедиться, что не используется лишний REST-доступ для публичных данных, отключить ненужные эндпоинты только после анализа, а также убрать старые плагины, которые давно не обновлялись. Иногда именно они создают больше риска, чем сам XML-RPC.
Для сайтов с высокой нагрузкой полезно дополнительно проверить кеширование и защиту от ботов. XML-RPC часто сканируют автоматически, и если endpoint остаётся открытым, это создаёт лишний шум в логах и небольшую, но постоянную нагрузку. На слабом хостинге такие мелочи тоже имеют значение.
Если нужен более широкий аудит дублей и технических настроек
Когда вы чистите сайт от лишних технических точек входа, удобно параллельно проверить дубли, служебные страницы и SEO-настройки. Для этого иногда используют Clearfy Pro: он закрывает часть типовых технических задач без ручного правления десятков мелких настроек. Но даже с таким инструментом важно понимать, что именно вы отключаете и зачем.
Главный критерий здесь простой: если XML-RPC не нужен ни одному вашему рабочему сценарию, отключайте его. Если нужен хотя бы одному — не ломайте интеграцию ради абстрактной безопасности, а ограничьте доступ точечно и зафиксируйте, кто его использует.