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

Если в логах постоянно мелькают запросы к /xmlrpc.php, а в отчётах безопасности — попытки pingback, проблема обычно не в самом WordPress, а в том, что сайт принимает лишний тип удалённых вызовов. Полностью рубить XML-RPC не всегда удобно: у части сайтов через него ещё работают старые мобильные клиенты, внешние сервисы публикации и некоторые интеграции. Но pingback почти всегда можно отключить отдельно.

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

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

Сначала стоит убедиться, что вы боретесь именно с нужной причиной. Pingback — это механизм уведомления между сайтами. На практике он часто создаёт шум в логах, лишнюю нагрузку и иногда используется для злоупотреблений, когда на ваш сайт шлют массовые запросы на проверку ссылок.

Типичные признаки

• в access-логах много обращений к /xmlrpc.php с кодами 200, 403 или 405;
• в панели безопасности есть предупреждения о pingback-атаках;
• на сайте не нужны старые внешние клиенты WordPress, но нужен обычный вход в админку и REST API;
• после отключения XML-RPC целиком ломается интеграция, которую вы не планировали отключать.

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

Что отключать: pingback или весь XML-RPC

Это важный момент. Полное отключение XML-RPC — более жёсткая мера. Она подходит, когда вы точно знаете, что удалённые вызовы не используются. Отключение pingback — более точечное решение: WordPress перестаёт принимать и отправлять уведомления о ссылках, но сам XML-RPC как интерфейс остаётся доступным для других сценариев.

Диагностика перед изменениями

Перед правкой полезно быстро проверить, что именно сейчас отвечает на запросы XML-RPC. Это можно сделать без установки плагинов.

curl -I https://example.com/xmlrpc.php

Если сервер отвечает 200 OK, 403 Forbidden или 405 Method Not Allowed, это уже подсказка, что endpoint доступен и его поведение зависит от настроек сервера, плагинов безопасности или темы. Для pingback важнее не код ответа сам по себе, а то, что endpoint вообще открыт для обращений.

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

Пошаговое решение через код

Самый надёжный способ — добавить небольшой фрагмент в functions.php дочерней темы или в собственный мини-плагин. Так вы не зависите от настроек стороннего плагина и понимаете, что именно меняется.

1. Отключить pingback-заголовок и сам механизм

// Убираем ссылку на pingback в <head> и отключаем сам pingback-ответчик.
add_action('init', function () {
    remove_action('wp_head', 'rsd_link');
    remove_action('wp_head', 'wlwmanifest_link');
});

add_filter('xmlrpc_methods', function ($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    return $methods;
});

Этот вариант не ломает весь XML-RPC, но убирает наиболее проблемные методы, связанные с pingback. Если вам не нужен Windows Live Writer и RSD-ссылка, их тоже можно убрать, но это уже отдельная задача.

2. Если нужно закрыть XML-RPC полностью

Такой вариант стоит применять только после проверки интеграций. Самый простой способ — через фильтр xmlrpc_enabled.

add_filter('xmlrpc_enabled', '__return_false');

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

3. Если нужен контроль на уровне сервера

Иногда логичнее блокировать сам запрос к xmlrpc.php на уровне веб-сервера. Это полезно, если атаки идут массово и вы не хотите, чтобы WordPress вообще запускался на этих запросах. Но такой способ стоит использовать только если вы уверены, что XML-RPC не нужен.

Для Nginx это обычно делают через отдельное правило в конфигурации сайта. Для Apache — через .htaccess или правила виртуального хоста. Конкретная реализация зависит от хостинга, поэтому здесь важнее принцип: сначала проверьте, что на сайте нет зависимостей от XML-RPC, и только потом режьте endpoint на сервере.

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

После правки не ограничивайтесь открытием главной страницы. Нужно проверить именно те точки, которые вы меняли.

• Откройте /xmlrpc.php в браузере и убедитесь, что поведение соответствует выбранному сценарию.
• Проверьте логи сервера: количество обращений к xmlrpc.php может остаться, но успешных вызовов pingback быть не должно.
• Если вы отключали только pingback, убедитесь, что другие XML-RPC-вызовы не сломались.
• Посмотрите, не появились ли ошибки в плагинах публикации или мобильных клиентах.

Для более точной проверки можно отправить тестовый XML-RPC-запрос. Если pingback отключён, метод pingback.ping должен возвращать ошибку или быть недоступным, а не проходить как раньше.

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

Отключили XML-RPC целиком, хотя нужен был только pingback

Это самая частая ошибка. В результате перестают работать внешние сервисы, а причина была только в лишних уведомлениях о ссылках. Если интеграции важны, откатите xmlrpc_enabled и оставьте только фильтрацию методов pingback.

Добавили код в родительскую тему

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

Проверили только главную страницу

Так можно пропустить сломанный XML-RPC или ошибку в логике плагина безопасности. Проверяйте именно /xmlrpc.php, а не только фронтенд.

Смешали отключение pingback с отключением комментариев

Это разные механизмы. Pingback не равен комментариям. Если задача — убрать спам-комментарии, нужен отдельный сценарий, а не правка XML-RPC.

Безопасность и производительность: что реально даёт отключение

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

Если вы хотите закрыть вопрос аккуратно, лучше идти по ступеням:

1. сначала отключить только pingback;
2. проверить внешние интеграции;
3. если XML-RPC не нужен вообще — отключить его полностью;
4. при массовых атаках дополнительно ограничить доступ на уровне сервера или WAF.

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

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

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

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