Как отключить XML-RPC и pingback в WordPress без лишних поломок

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

Когда отключение действительно нужно

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

Отключать стоит, если:

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

Диагностика: что именно используется сейчас

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

<?php
add_action('xmlrpc_call', function ($method) {
    error_log('XML-RPC method: ' . $method);
});

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

Что проверить до внедрения

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

Пошаговое решение: отключаем XML-RPC и pingback

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

Вариант 1: отключение через mu-plugin

Это самый предсказуемый способ. Создайте файл wp-content/mu-plugins/disable-xmlrpc-pingback.php. Если папки mu-plugins нет, создайте её вручную.

<?php
/**
 * Plugin Name: Disable XML-RPC and pingback
 */

add_filter('xmlrpc_enabled', '__return_false');

add_filter('wp_headers', function ($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

add_filter('pings_open', '__return_false', 9999);

add_action('init', function () {
    if (isset($_SERVER['SCRIPT_NAME']) && basename($_SERVER['SCRIPT_NAME']) === 'xmlrpc.php') {
        status_header(403);
        exit;
    }
});

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

Вариант 2: запрет на уровне сервера

Если сайт под нагрузкой или вы хотите отсечь запросы до запуска PHP, можно закрыть xmlrpc.php на уровне веб-сервера. Для Apache это обычно делается через .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

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

Как проверить, что решение сработало

Проверка должна быть не только визуальной. Откройте https://ваш-домен/xmlrpc.php в браузере или через curl. Если всё отключено корректно, вы не должны получать рабочий XML-RPC-ответ.

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

Ожидаемый результат — 403 или другой отказ в доступе, в зависимости от способа блокировки. Дополнительно проверьте:

• в исходном HTML главной страницы больше нет заголовка X-Pingback;
• новые комментарии не создают pingback-уведомления на внутренних ссылках;
• Jetpack и другие интеграции не потеряли нужные функции;
• в логах сервера исчезли регулярные обращения к /xmlrpc.php с успешным ответом.

Если используете мониторинг безопасности, посмотрите, не осталось ли успешных POST-запросов к xmlrpc.php после внедрения. Один только статус 403 ещё не всё: важно, чтобы файл не обрабатывался как раньше.

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

Отключили XML-RPC, но сломали публикацию из внешнего сервиса

Это типичный сценарий, когда сайт использовал сторонний редактор, автопостинг или старое приложение. Решение простое: сначала выяснить источник запросов, потом либо оставить XML-RPC включённым, либо перевести интеграцию на REST API, если сервис это поддерживает.

Скрыли заголовок X-Pingback, но pingback всё равно работает

Удаление заголовка не равно отключению pingback. Нужно отдельно выключить pings_open и, если требуется, закрыть обработку на уровне темы или сервера. Иначе уведомления могут продолжать создаваться на уровне комментариев.

Закрыли xmlrpc.php в .htaccess, а сайт начал отдавать 500

Чаще всего причина в синтаксисе или в том, что правило вставили не в тот блок. Если есть сомнения, сначала проверьте конфиг в staging-окружении. Для Apache правило должно быть минимальным и без лишних условий.

Поставили плагин, который отключает всё подряд

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

Безопасность и производительность: что ещё имеет смысл сделать

Если вы уже трогаете входные точки, полезно проверить и соседние вещи: лимит попыток входа, актуальность ядра, отключение лишних REST-эндпоинтов только там, где это действительно нужно, и очистку старых плагинов, которые давно не используются. Не стоит пытаться «усилить безопасность» отключением всего подряд — это часто ломает админку или интеграции.

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

Практический чек-лист перед выкладкой на прод

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

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