Как запретить индексацию XML-RPC и убрать его из robots.txt в WordPress

XML-RPC в WordPress часто всплывает не из-за реальной функции, а как технический хвост: его видят сканеры, он попадает в robots.txt, а в отчётах по безопасности и SEO появляется лишний мусор. Если вы не используете мобильное приложение WordPress, внешние публикации через XML-RPC или старые интеграции, этот интерфейс обычно проще закрыть и убрать из публичного следа.

Важно не путать две задачи: отключить сам endpoint и убрать упоминание о нём из robots.txt. Это разные уровни. Первый снижает поверхность атаки, второй убирает лишний URL из технических файлов и отчётов.

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

Сценарий обычно выглядит так: в /robots.txt есть строка вроде Disallow: /xmlrpc.php, в логах идут запросы к /xmlrpc.php, а в аудитах безопасности endpoint отмечается как доступный. При этом сайт XML-RPC не использует, но полностью убрать следы никто не удосужился.

Проверить это можно быстро:

• откройте https://ваш-домен.ru/xmlrpc.php в браузере;
• посмотрите, отвечает ли файл сообщением WordPress или отдаёт 403/404;
• проверьте /robots.txt на наличие строки про xmlrpc.php;
• посмотрите access-логи веб-сервера на частые обращения к этому адресу.

Что считать нормой

Если XML-RPC не нужен, нормальный результат — endpoint либо недоступен, либо явно заблокирован на уровне сервера или WordPress, а в robots.txt нет лишней строки, которая создаёт видимость отдельной зоны для индексации. Сам по себе Disallow не защищает endpoint, он только сообщает роботам не ходить туда.

Какие есть варианты решения

Если задача техническая и нужна на постоянной основе, лучше идти через код. Плагин имеет смысл, когда вы не хотите трогать тему и у вас уже есть централизованный security-стек.

Пошаговое решение без лишних зависимостей

1. Заблокировать XML-RPC на уровне WordPress

Самый безопасный вариант для сайта без XML-RPC — отключить его фильтром xmlrpc_enabled. Это не ломает обычную работу админки и не затрагивает REST API.

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

Код лучше добавить в mu-plugin или в отдельный мини-плагин, а не в functions.php активной темы. Так настройка не исчезнет после смены темы.

2. Убрать XML-RPC из robots.txt

Если в robots.txt есть строка Disallow: /xmlrpc.php, её можно убрать через фильтр robots_txt. Это полезно, когда robots.txt генерируется WordPress и вы хотите оставить файл чистым.

<?php
add_filter( 'robots_txt', function( $output, $public ) {
	$lines = preg_split( '/\r\n|\r|\n/', $output );
	$lines = array_filter( $lines, function( $line ) {
		return trim( $line ) !== 'Disallow: /xmlrpc.php';
	} );

	return implode( "\n", $lines );
}, 10, 2 );

Этот код не трогает другие правила robots.txt. Он просто вырезает конкретную строку, если она присутствует.

3. Если нужен жёсткий запрет — закрыть файл на уровне сервера

Когда endpoint активно атакуют или он не должен отвечать вообще, лучше дополнительно закрыть xmlrpc.php на уровне веб-сервера. Это уже не WordPress-логика, а защита на входе.

Для Nginx можно использовать отдельное правило в конфигурации сайта:

location = /xmlrpc.php {
	deny all;
	access_log off;
	log_not_found off;
}

Для Apache обычно используют правила в .htaccess, но если сайт работает через Nginx, ориентируйтесь именно на конфиг Nginx, а не на примеры из чужих статей.

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

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

• откройте /xmlrpc.php — он не должен отдавать рабочий XML-RPC-ответ;
• проверьте /robots.txt — строки Disallow: /xmlrpc.php там быть не должно, если вы её убирали;
• посмотрите HTTP-статус в DevTools, curl или через серверные логи;
• убедитесь, что обычный вход в админку, REST API и публикация записей работают как раньше.

Простой тест через curl:

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

Если вы закрывали endpoint на уровне сервера, ожидаемым результатом будет 403 или 404 в зависимости от настроек. Если отключали только через WordPress-фильтр, ответ может отличаться, но XML-RPC-запросы должны перестать проходить.

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

Путают robots.txt и реальную защиту

Строка Disallow: /xmlrpc.php не блокирует доступ. Роботам она что-то подсказывает, но злоумышленнику не мешает. Если нужна безопасность, отключайте endpoint или режьте его на сервере.

Правят файл robots.txt вручную, а потом WordPress его перезаписывает

Если robots.txt виртуальный, ручные изменения в корне сайта могут не дать эффекта. В таком случае используйте фильтр robots_txt или создайте физический файл, если у вас действительно такой сценарий.

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

Иногда security-плагин выключает endpoint, но другое правило или серверная конфигурация оставляет его доступным. Проверяйте итоговый HTTP-ответ, а не только настройки в админке.

Ломают интеграции, которые завязаны на XML-RPC

Если у вас есть старое мобильное приложение, внешняя публикация через сторонний сервис или legacy-интеграция, сначала проверьте зависимость. В таких случаях лучше ограничить доступ точечно, а не рубить endpoint без анализа.

Практические советы по безопасности и производительности

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

Для сайтов, где нужно централизованно убирать дубли, чистить технические хвосты и держать SEO-настройки под контролем, удобно использовать инструменты уровня Clearfy Pro. Но если вам нужна точечная и прозрачная настройка, код в mu-plugin обычно надёжнее и проще для аудита.

Хорошая практика — после любых изменений в доступности endpoint'ов проверять:

• не появились ли ошибки в логах веб-сервера;
• не сломались ли внешние сервисы, если они были;
• не остались ли старые правила в кэше CDN или reverse proxy;
• не дублируется ли настройка в плагине, теме и сервере одновременно.

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