XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильные приложения, внешние публикации и часть интеграций. Отдельная история — pingback и trackback: они почти не дают пользы на современных сайтах, но продолжают создавать лишние запросы и шум в логах.
Ниже — рабочая схема, как отключить XML-RPC и pingback точечно: без лишних побочных эффектов, с проверкой зависимостей и понятным откатом.
Когда отключение действительно уместно
Сначала стоит понять, что именно вы хотите убрать. XML-RPC — это не только «старый протокол», но и точка входа для внешних клиентов. Pingback и trackback — механика уведомлений между сайтами, которая на большинстве проектов уже не нужна. Если сайт не использует внешнюю публикацию, мобильные клиенты WordPress и сторонние сервисы синхронизации, отключение обычно оправдано.
Типичные сценарии, где отключение помогает
- в логах много обращений к
/xmlrpc.phpот ботов; - на сайте включены комментарии, но pingback/trackback не используются;
- есть требования по снижению поверхности атаки;
- нужно убрать лишние запросы и шум в мониторинге;
- сайт работает только через админку и обычный фронтенд.
Диагностика: что сломается, если отключить XML-RPC
Перед изменениями проверьте, не завязаны ли на XML-RPC реальные процессы. Самый простой способ — посмотреть, кто обращается к xmlrpc.php, и пройтись по интеграциям.
Что проверить в первую очередь
- мобильное приложение WordPress;
- Jetpack и похожие сервисы, если они используются;
- внешние редакторы и планировщики публикаций;
- синхронизацию с CRM или сервисами автопостинга;
- старые плагины для удалённой публикации.
Если сомневаетесь, сначала не отключайте протокол полностью, а закройте pingback и ограничьте доступ к XML-RPC только там, где это действительно нужно. Это проще откатить.
Пошаговое решение: отключаем pingback и trackback
Для большинства сайтов достаточно убрать именно pingback и trackback. Это не ломает внешние клиенты, но убирает лишнюю механику уведомлений.
// functions.php темы или mu-plugin
add_filter('xmlrpc_methods', function ($methods) {
unset($methods['pingback.ping']);
unset($methods['pingback.extensions.getPingbacks']);
return $methods;
});
add_filter('pre_option_default_pingback_flag', '__return_zero');
add_filter('pre_option_default_ping_status', '__return_zero');
add_filter('pre_option_default_trackback_status', '__return_zero');Этот вариант отключает pingback на уровне WordPress и убирает его по умолчанию для новых записей. Если у вас уже есть старые записи с включёнными уведомлениями, их настройки останутся прежними, пока вы не измените их отдельно.
Если нужно отключить XML-RPC полностью
Полное отключение имеет смысл только тогда, когда вы точно знаете, что внешние клиенты не нужны. Самый надёжный способ — блокировать доступ на уровне WordPress, а при необходимости дополнительно закрыть маршрут на уровне веб-сервера.
Вариант через WordPress
// mu-plugin или functions.php
add_filter('xmlrpc_enabled', '__return_false');Этот фильтр отключает XML-RPC штатно. Для большинства задач этого достаточно. Но если на сайт идут массовые запросы к /xmlrpc.php, полезно дополнительно вернуть 403 на уровне сервера, чтобы не тратить ресурсы PHP.
Вариант через Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой блок лучше ставить только если вы уверены, что XML-RPC не нужен вообще. Иначе вы отрежете все внешние клиенты сразу, без возможности обойти ограничение из WordPress.
Сравнение подходов
| Подход | Что отключает | Плюсы | Минусы |
|---|---|---|---|
| Только pingback/trackback | Уведомления между сайтами | Безопаснее для интеграций | XML-RPC остаётся доступным |
xmlrpc_enabled | Полностью XML-RPC | Просто и штатно | Ломает внешние клиенты |
| Блокировка на сервере | Запросы к /xmlrpc.php | Снижает нагрузку и шум | Нужен доступ к конфигу сервера |
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой в админке. Нужно убедиться, что endpoint ведёт себя так, как вы ожидаете.
Что проверить вручную
- откройте
/xmlrpc.phpв браузере или черезcurl; - проверьте, что pingback больше не создаётся при ссылке на другой сайт;
- посмотрите логи веб-сервера на повторяющиеся обращения;
- если используете внешние клиенты, попробуйте тестовую публикацию;
- убедитесь, что комментарии и обычная публикация работают как раньше.
Простой тест через curl помогает быстро понять, закрыт ли endpoint:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали маршрут на сервере, ожидаемым результатом будет 403 или 404 в зависимости от конфигурации. Если отключали только через WordPress, ответ может отличаться, но сам XML-RPC не должен выполнять методы.
Частые ошибки и как их исправить
Отключили всё, а потом перестал работать Jetpack
Jetpack и похожие сервисы могут использовать XML-RPC для части функций. Решение простое: либо вернуть XML-RPC, либо перевести интеграцию на другой способ подключения, если он поддерживается конкретным сервисом.
Скрыли проблему, но не убрали нагрузку
Если вы отключили XML-RPC только фильтром WordPress, а бот продолжает стучаться в /xmlrpc.php, PHP всё равно будет получать запросы. В таком случае лучше добавить блокировку на уровне Nginx или Apache.
Сломали pingback, но забыли про старые записи
На старых постах могут остаться включённые уведомления. Это не критично, но если вы чистите сайт системно, проверьте массовые настройки записей и шаблоны новых публикаций.
Поставили плагин, который делает больше, чем нужно
Для этой задачи не всегда нужен отдельный плагин. Если сайт уже перегружен, лишний плагин ради одной настройки — не лучший вариант. Иногда проще использовать mu-plugin или код в теме. Если нужен более широкий набор технических настроек, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Практические советы по безопасности и производительности
Отключение XML-RPC не заменяет базовую защиту. Если на сайте слабые пароли, устаревшие плагины и открытая админка, один закрытый endpoint не решит проблему.
- держите WordPress, тему и плагины в актуальном состоянии;
- не отключайте XML-RPC, пока не проверили внешние интеграции;
- если endpoint не нужен, блокируйте его и на уровне приложения, и на уровне сервера;
- после изменений проверьте логи 24–48 часов, чтобы увидеть, не осталось ли зависимых сервисов;
- не смешивайте отключение XML-RPC с другими изменениями в одном коммите, если потом нужен быстрый откат.
Если задача шире и вы параллельно чистите сайт от технического мусора, лучше делать это поэтапно: сначала отключить pingback, затем проверить XML-RPC, потом уже трогать другие настройки индексации и генерации дублей. Так проще понять, что именно повлияло на сайт.