Если на сайте в логах появляются запросы к xmlrpc.php, а в панели безопасности или на хостинге растёт число подозрительных обращений, часто проблема не в самом XML-RPC как технологии, а в конкретной функции pingback. Она исторически использовалась для уведомлений между сайтами, но на практике чаще создаёт лишний шум: боты сканируют endpoint, а некоторые конфигурации получают ненужную нагрузку.
Важно не путать отключение pingback с полным отключением XML-RPC. Полный запрет может задеть Jetpack, мобильное приложение WordPress и отдельные внешние сервисы. Если задача точечная, лучше убрать именно pingback, а не рубить всё подряд.
Когда имеет смысл отключать pingback
Сценарий обычно такой: сайт не использует уведомления о входящих ссылках, но xmlrpc.php постоянно светится в access log. Иногда это сопровождается попытками брутфорса, иногда — просто лишними запросами от сканеров. В обоих случаях pingback не даёт пользы, а поверхность атаки и шум в логах остаются.
Ещё один частый случай — сайт работает на слабом хостинге, и даже небольшая волна обращений к XML-RPC заметно увеличивает нагрузку. Тогда отключение pingback помогает убрать один из популярных векторов мусорного трафика без вмешательства в остальной функционал WordPress.
Диагностика проблемы перед изменениями
Сначала проверьте, действительно ли запросы идут именно на XML-RPC и связаны ли они с pingback. Это можно сделать по логам веб-сервера или через инструменты хостинга. Ищите обращения к /xmlrpc.php с повторяющимися IP, странными user-agent или большим количеством POST-запросов.
Полезно также понять, используется ли XML-RPC чем-то ещё. Если на сайте подключён Jetpack, мобильное приложение WordPress или интеграции публикации через сторонние сервисы, полный запрет XML-RPC может создать проблемы. В такой ситуации точечное отключение pingback безопаснее.
Что проверить до правки кода
- Есть ли в логах обращения к
xmlrpc.phpи как часто они повторяются. - Используется ли Jetpack или мобильное приложение WordPress.
- Есть ли внешние сервисы, которые публикуют записи через XML-RPC.
- Не включён ли уже плагин безопасности, который блокирует XML-RPC на уровне сервера или WordPress.
Как отключить pingback через код
Самый надёжный способ — убрать поддержку pingback в WordPress через фильтр xmlrpc_methods. Это не ломает сам endpoint, но удаляет метод, который отвечает за pingback.
add_filter( 'xmlrpc_methods', function( $methods ) {
if ( isset( $methods['pingback.ping'] ) ) {
unset( $methods['pingback.ping'] );
}
return $methods;
} );Код можно добавить в дочернюю тему, в небольшой mu-plugin или в собственный функциональный плагин. Для production-сайта mu-plugin часто удобнее: он не зависит от темы и не потеряется при обновлении.
Вариант через mu-plugin
Создайте файл, например wp-content/mu-plugins/disable-pingback.php, и добавьте туда такой код:
<?php
/**
* Plugin Name: Disable Pingback
*/
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );Если папки mu-plugins нет, её можно создать вручную. WordPress подхватит файл автоматически, без активации в админке.
Если нужен более жёсткий вариант
Иногда pingback отключают не только на уровне метода, но и полностью блокируют обращения к xmlrpc.php. Это уже более грубое решение, и оно подходит только если вы точно не используете XML-RPC вообще.
Для полного запрета обычно применяют либо правила веб-сервера, либо фильтр xmlrpc_enabled. Но если цель статьи — убрать именно pingback, не стоит сразу идти в полный бан: это часто избыточно и создаёт лишние риски для интеграций.
| Подход | Что делает | Когда выбирать |
|---|---|---|
Удалить pingback.ping через xmlrpc_methods | Отключает только pingback | Если XML-RPC нужен частично |
xmlrpc_enabled | Отключает XML-RPC целиком | Если интеграции не используются |
| Правило на сервере | Блокирует доступ к xmlrpc.php | Если нужен жёсткий сетевой запрет |
Проверка результата после внедрения
После добавления кода не ограничивайтесь визуальной проверкой в админке. Нужно убедиться, что метод действительно исчез из XML-RPC и что сайт не потерял нужный функционал.
Как проверить вручную
- Откройте
https://ваш-домен.ru/xmlrpc.php— сам файл может отвечать, это нормально. - Проверьте, что pingback-запросы больше не проходят через тестовый клиент или внешний сервис.
- Посмотрите логи сервера: количество обращений к
xmlrpc.phpможет остаться, но ошибки поpingback.pingдолжны исчезнуть. - Если используется Jetpack, убедитесь, что он продолжает подключаться без ошибок.
Если у вас есть доступ к WP-CLI или тестовому окружению, можно быстро проверить, не сломались ли публикации и авторизация через внешние сервисы. Для этого достаточно пройтись по основным сценариям, которые реально используются на сайте.
Частые ошибки и как их исправить
Отключили XML-RPC целиком вместо pingback
Это самая частая ошибка. Администратор видит запросы к xmlrpc.php и сразу ставит жёсткую блокировку. В результате перестаёт работать то, что было завязано на XML-RPC. Если нужен только отказ от pingback, удаляйте именно метод pingback.ping.
Добавили код в тему, а потом потеряли его после обновления
Если правка лежит в родительской теме, она исчезнет при обновлении. Для таких задач лучше использовать mu-plugin или собственный мини-плагин. Это надёжнее и проще для сопровождения.
Смешали отключение pingback с блокировкой REST API
Это разные механизмы. Если на сайте уже отключён REST API, не стоит автоматически считать, что XML-RPC тоже не нужен. У них разные потребители и разные риски.
Не проверили сторонние интеграции
Иногда сайт выглядит «обычным», но публикации из мобильного приложения, автопостинг или старый сервис импорта завязаны на XML-RPC. Перед изменением проверьте реальные сценарии использования, а не только список установленных плагинов.
Практические советы по безопасности и производительности
Если на сайте регулярно идут атаки на xmlrpc.php, отключение pingback — только часть решения. Имеет смысл дополнительно ограничить доступ на уровне WAF, fail2ban или правил веб-сервера, если это поддерживает ваш хостинг. Но не стоит ставить несколько конфликтующих решений одновременно: потом сложно понять, что именно заблокировало запрос.
Для сайтов с высокой посещаемостью полезно периодически смотреть access log и выделять повторяющиеся шаблоны запросов. Если endpoint атакуют массово, лучше решать проблему на уровне сервера, а не только средствами WordPress. Так вы снизите нагрузку до того, как запрос попадёт в PHP.
Если вам нужен более широкий набор инструментов для технической чистки WordPress — отключение дублей, лишних функций и части служебного шума — можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае важно понимать, что именно отключается и как это влияет на конкретный сайт.
Короткий чек-лист перед публикацией правки
- Поняли, нужен ли сайту XML-RPC целиком.
- Проверили, используются ли Jetpack или мобильное приложение WordPress.
- Удалили только
pingback.ping, если нужен точечный сценарий. - Добавили код в mu-plugin или другой устойчивый к обновлениям слой.
- Проверили логи и реальные сценарии после изменения.
Если после отключения pingback в логах всё ещё много обращений к xmlrpc.php, значит, проблема уже не в pingback как функции, а в самом факте доступности endpoint. Тогда нужен отдельный разбор блокировки XML-RPC на уровне сервера или WordPress.