XML-RPC в WordPress часто держат включённым «на всякий случай», а потом получают лишние запросы, шум в логах и ненужную поверхность атаки. При этом отключать его вслепую нельзя: у части сайтов через XML-RPC до сих пор работают внешние публикации, мобильные клиенты и некоторые старые интеграции. Pingback и trackback — отдельная история: на большинстве сайтов они не нужны и только создают мусорные входящие запросы.
Ниже — практический разбор: как понять, нужен ли вам XML-RPC, чем отличается отключение pingback от полного запрета XML-RPC, и как проверить, что после изменений сайт не потерял нужную функциональность.
Когда XML-RPC действительно можно отключать
Сначала стоит не править код, а посмотреть на сценарии использования. Если у сайта нет внешней публикации через старые клиенты, нет мобильных приложений, которые отправляют записи через XML-RPC, и нет интеграций, завязанных на этот протокол, отключение обычно безопасно. Для обычного корпоративного сайта, блога или контентного проекта XML-RPC чаще всего не нужен.
Что обычно ломается при отключении
Проблемы возникают не из-за самого WordPress, а из-за внешних клиентов. Чаще всего это:
- старые приложения для публикации постов;
- сервисы автопостинга, которые не умеют работать через REST API;
- мобильные клиенты, использующие XML-RPC вместо REST;
- редкие интеграции для удалённого управления сайтом.
Если у вас есть сомнения, проверьте журналы доступа или список подключённых сервисов. На практике полезно поискать запросы к /xmlrpc.php в логах веб-сервера или в логах безопасности плагина, если он их ведёт.
Диагностика: нужен ли вам XML-RPC прямо сейчас
Перед отключением сделайте короткую проверку. Это занимает меньше времени, чем потом искать, почему не отправляется пост из внешнего сервиса.
- Откройте
https://ваш-домен.ru/xmlrpc.phpв браузере. Если файл доступен, это ещё не значит, что он используется, но точка входа есть. - Проверьте, есть ли в логах обращения к
xmlrpc.php. - Спросите у команды, используют ли они внешнюю публикацию, мобильные клиенты или старые интеграции.
- Если сайт на хостинге с WAF или модулем защиты, посмотрите, не блокируются ли запросы к XML-RPC уже сейчас.
Если вы видите регулярные обращения к этому файлу без понятного источника, это ещё один аргумент в пользу отключения. XML-RPC часто используют для перебора паролей и массовых запросов, поэтому лишний открытый endpoint лучше убрать.
Пошаговое решение: отключить XML-RPC и pingback
Есть несколько рабочих способов. Для большинства сайтов удобнее всего отключать это через код в теме-потомке или в небольшом mu-plugin. Так вы не зависите от настроек темы и не теряете изменения после обновления.
| Способ | Когда подходит | Компромисс |
|---|---|---|
| Код в functions.php | Если нужен быстрый точечный фикс | Зависит от темы, можно потерять при смене темы |
| mu-plugin | Если нужен стабильный системный запрет | Нужно один раз создать файл вручную |
| Плагин безопасности | Если уже используете такой плагин и не хотите писать код | Лишняя зависимость от интерфейса плагина |
Вариант 1: полностью отключить XML-RPC
Добавьте код в functions.php дочерней темы или в собственный mu-plugin:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключает сам XML-RPC endpoint. Если кто-то попробует обратиться к xmlrpc.php, WordPress не будет принимать запросы через этот механизм.
Вариант 2: отключить только pingback и trackback
Если XML-RPC нужен для внешней публикации, но вы хотите убрать именно pingback, используйте более мягкий вариант:
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );
add_filter( 'pings_open', '__return_false' );
add_filter( 'wp_headers', function( $headers ) {
if ( isset( $headers['X-Pingback'] ) ) {
unset( $headers['X-Pingback'] );
}
return $headers;
} );Этот вариант полезен, если вам важно оставить часть XML-RPC-функций, но убрать входящие pingback-запросы и следы этой механики на сайте.
Вариант 3: закрыть доступ на уровне сервера
Если сайт под постоянным брутфорсом, имеет смысл дополнительно ограничить доступ к xmlrpc.php на уровне веб-сервера или WAF. Это уже зависит от стека хостинга, поэтому универсального кода здесь нет. Но логика простая: даже если WordPress умеет отклонять запрос, лучше не доводить их до PHP без необходимости.
Проверка результата после внедрения
После отключения важно не ограничиться «ошибок в админке нет». Проверьте именно те точки, которые могли пострадать.
- Откройте
/xmlrpc.phpи убедитесь, что endpoint больше не отвечает как рабочий API. - Если вы отключали только pingback, проверьте исходный HTML страницы: заголовок
X-Pingbackдолжен исчезнуть. - Попробуйте отправить тестовую запись из внешнего клиента, если он у вас есть.
- Посмотрите логи сервера: количество обращений к
xmlrpc.phpдолжно снизиться или стать нулевым.
Для быстрой проверки заголовков удобно использовать curl:
curl -I https://example.com/ | grep -i pingbackЕсли команда ничего не возвращает, это нормальный результат для сайта, где pingback отключён и заголовок не отдается.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестала работать публикация из внешнего сервиса
Значит, сервис действительно использовал XML-RPC. Решение — либо вернуть endpoint, либо перевести интеграцию на REST API, если сервис это поддерживает. Не стоит держать XML-RPC открытым только из-за одного устаревшего клиента, если можно обновить связку.
Скрыли endpoint, но атаки в логах остались
Это бывает, если запросы блокируются уже на уровне сервера или WAF, а не WordPress. В таком случае это даже хорошо: PHP не тратит ресурсы на обработку. Проверьте, нет ли параллельно открытого пути через альтернативный домен, поддомен или старый сайт-клон.
Добавили код в родительскую тему и потеряли его после обновления
Такой способ работает только до следующего обновления темы. Для постоянного решения используйте дочернюю тему или mu-plugin. Если на сайте уже есть набор технических правок, удобнее собрать их в один маленький mu-plugin, чем распылять по теме.
Отключили pingback, но в админке остались старые настройки
Отключение входящих pingback не всегда автоматически меняет все связанные настройки для уже опубликованных записей. Проверьте параметры обсуждения и массовые настройки для старого контента, если у вас есть записи, где эта механика включалась вручную.
Что ещё стоит сделать для безопасности и производительности
Если вы уже трогаете XML-RPC, имеет смысл заодно проверить соседние технические точки. На сайтах с большим количеством мусорных запросов полезно:
- ограничить частоту запросов к чувствительным endpoint'ам на уровне сервера;
- убедиться, что REST API не закрыт без необходимости;
- проверить, не включены ли лишние механизмы комментариев и trackback на старом контенте;
- посмотреть, не создаёт ли тема или плагин лишние заголовки и запросы к неиспользуемым функциям.
Если вам нужен более широкий набор технических чисток — от дублей до лишних служебных элементов — такие задачи обычно удобнее закрывать отдельным инструментом, а не десятком разрозненных сниппетов. Например, Clearfy Pro часто используют именно для системной чистки WordPress и отключения неиспользуемых функций, но применять его стоит только там, где это действительно нужно, а не ради одной галочки.
Главная проверка здесь простая: после правки сайт должен продолжать работать в тех сценариях, которые вам реально нужны, а лишние точки входа — исчезнуть из логов и из публичного интерфейса. Если это так, отключение XML-RPC и pingback выполнено корректно.