Как отключить XML-RPC pingback в WordPress и убрать лишние запросы

Если на сайте в логах много обращений к xmlrpc.php, это не всегда означает атаку. Часто проблема в том, что WordPress принимает pingback-запросы, а они создают лишнюю нагрузку и шум в логах. На блогах, корпоративных сайтах и статейниках это обычно не нужно: комментарии и уведомления о ссылках редко дают пользу, зато добавляют лишние HTTP-запросы.

Ниже разберём, как точечно отключить именно pingback, а не рубить XML-RPC целиком. Это важно, если у вас есть мобильное приложение WordPress, внешняя публикация через сторонний сервис или старые интеграции, которые ещё завязаны на XML-RPC.

Когда проблема действительно в pingback

Сначала стоит убедиться, что вы боретесь именно с причиной, а не с симптомом. Откройте access-логи веб-сервера или логи WAF и посмотрите, что чаще всего бьёт в /xmlrpc.php. Если там идут запросы с методами вроде pingback.ping, pingback.extensions.getPingbacks или массовые POST-запросы без полезной нагрузки, это типичный кандидат на отключение.

Что обычно видно в диагностике

• много POST-запросов к xmlrpc.php с одинаковых или разных IP;
• в логах появляются ошибки 403, 400 или 500 на xmlrpc.php;
• на сайте нет задач, где XML-RPC реально нужен;
• после публикации статей появляются уведомления о «ссылках» с сомнительных доменов.

Если у вас включён плагин безопасности, он может уже показывать попытки обращения к XML-RPC. Но не стоит отключать всё подряд только по факту наличия запросов: сначала проверьте, используется ли этот канал чем-то полезным.

Как отключить pingback без полного отключения XML-RPC

Самый аккуратный вариант — убрать поддержку pingback-функций через фильтр. Тогда остальные XML-RPC-методы останутся доступны, если они нужны. Добавлять код лучше в functions.php дочерней темы или в небольшой mu-plugin, если вы не хотите зависеть от темы.

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );

    return $methods;
} );

Этот вариант не блокирует сам файл xmlrpc.php, а лишь убирает методы, которые чаще всего используют для лишних обращений и спама. Если какой-то внешний сервис попытается отправить pingback, он получит отказ, но обычные XML-RPC вызовы при этом не пострадают.

Если нужен более жёсткий вариант

Когда XML-RPC на сайте не используется вообще, можно отключить его целиком. Но это уже более грубое решение, и его стоит применять только после проверки интеграций. В таком случае лучше делать это через код, а не через случайный сниппет из интернета.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Если вы используете мобильное приложение WordPress, Jetpack или сторонний сервис публикации, сначала проверьте, не завязаны ли они на XML-RPC. Иначе после отключения получите не «защиту», а сломанный рабочий процесс.

Сравнение подходов: что выбрать на практике

Проверка результата после внедрения

После добавления фильтра не ограничивайтесь тем, что сайт «открылся без ошибок». Проверьте именно поведение xmlrpc.php и логи.

• откройте /xmlrpc.php в браузере — сам файл может отвечать, это нормально;
• попробуйте отправить тестовый pingback с внешнего ресурса или через инструмент разработчика, если он у вас есть;
• посмотрите access-лог: запросы должны либо исчезнуть, либо получать отказ на уровне метода;
• если используете мониторинг, проверьте, не выросло ли число ошибок 5xx после изменения.

Для более точной проверки можно временно включить логирование на стороне веб-сервера и сравнить картину до и после. Если у вас есть WAF или плагин безопасности, посмотрите, не начал ли он блокировать что-то лишнее после изменения правил.

Частые ошибки и как их исправить

Отключили XML-RPC, а потом перестало работать приложение

Это классическая ошибка, когда отключают всё целиком, не проверив зависимости. Если вам нужен только антиспам по pingback, возвращайтесь к варианту с xmlrpc_methods и не трогайте xmlrpc_enabled.

Добавили код в активную тему и потеряли его после обновления

Если правка лежит в functions.php родительской темы, обновление может затереть изменения. Для таких задач безопаснее использовать дочернюю тему или mu-plugin.

Поставили блокировку в .htaccess и сломали сторонний сервис

Жёсткая блокировка на уровне сервера полезна только когда вы уверены, что XML-RPC нигде не используется. Если сомневаетесь, начинайте с отключения pingback-методов, а не с запрета всего файла.

Проверили только главную страницу и решили, что всё в порядке

Главная страница может открываться нормально, даже если xmlrpc.php продолжает принимать мусорные запросы. Проверять нужно именно логи и поведение метода, а не только визуальную доступность сайта.

Что ещё стоит сделать для безопасности и производительности

Отключение pingback не заменяет нормальную защиту. Если на сайт идёт много мусорных запросов, проверьте базовые вещи: актуальные версии WordPress, темы и плагинов, ограничение попыток входа, корректный кэш страниц и отсутствие тяжёлых плагинов, которые делают лишние запросы на каждом хите.

Если задача шире и вам нужно навести порядок в технических настройках сайта, удобно держать под рукой инструменты, которые убирают дубли, чистят лишние элементы и помогают с SEO-обвязкой. Например, для таких задач уместно посмотреть Clearfy Pro, если вам нужен набор точечных оптимизаций без ручного разбрасывания по теме и плагинам.

Короткий чек-лист перед публикацией правки

• проверили, нужен ли XML-RPC внешним сервисам;
• выбрали отключение только pingback или всего XML-RPC;
• добавили код в дочернюю тему или mu-plugin;
• посмотрели логи xmlrpc.php до и после;
• убедились, что публикация и админка работают как раньше;
• зафиксировали изменение в журнале правок, если сайт поддерживается командой.

Если после отключения pingback нагрузка и шум в логах не изменились, значит источник запросов другой: боты могут бить в wp-login.php, REST API или старые URL. Тогда уже нужно смотреть не на XML-RPC, а на общую картину трафика и правил защиты.