Как закрыть admin-ajax.php и xmlrpc.php в robots.txt без поломки WordPress

Автор: Наталья Николаева | Опубликовано: 29.08.2026

Если на сайте всплывают лишние запросы к /wp-admin/admin-ajax.php или в логах регулярно светится /xmlrpc.php, первое желание — запретить их в robots.txt. Это рабочий шаг, но только в одном смысле: он помогает подсказать поисковым роботам, что эти URL не нужны для индексации. От реальных запросов пользователей, плагинов и атак robots.txt не защищает.

Поэтому задача здесь не в том, чтобы «запретить всё лишнее», а в том, чтобы понять, что именно вы хотите получить: убрать технические URL из обхода, снизить шум в отчётах, или реально ограничить доступ. Для каждого сценария решение будет разным.

Когда robots.txt помогает, а когда нет

robots.txt уместен, если вы хотите:

снизить вероятность попадания служебных URL в индекс;
показать поисковым роботам, что эти адреса не предназначены для обхода;
убрать из отчётов лишние страницы, которые не должны ранжироваться.

Но он не решает такие задачи:

не блокирует запросы к admin-ajax.php со стороны темы и плагинов;
не останавливает ботов, которые игнорируют robots.txt;
не защищает xmlrpc.php от перебора и массовых запросов.

Диагностика проблемы

Перед правкой файла проверьте, что именно происходит на сайте.

Откройте /robots.txt и убедитесь, что файл вообще доступен.
Посмотрите логи веб-сервера: есть ли частые обращения к admin-ajax.php и xmlrpc.php.
Проверьте, не завязан ли сайт на XML-RPC: например, старые мобильные клиенты, внешние сервисы публикации или интеграции с Jetpack.
Убедитесь, что admin-ajax.php не используется критичными функциями темы, формами, фильтрами, поиском или конструктором.

Если вы просто закроете эти адреса в robots.txt, а потом обнаружите, что форма отправки или AJAX-фильтр перестали работать, причина будет не в robots.txt, а в том, что вы перепутали индексацию с доступом.

Как правильно закрыть URL в robots.txt

Для WordPress обычно достаточно добавить директивы для конкретных служебных адресов. Делать это лучше аккуратно, без лишних запретов на весь /wp-admin/, если вы не понимаете последствия.

User-agent: *
Disallow: /wp-admin/admin-ajax.php
Disallow: /xmlrpc.php

Sitemap: https://example.com/sitemap_index.xml

Если у вас уже есть свой robots.txt, не затирайте его целиком. Добавьте только нужные строки и сохраните существующие правила для sitemap, публичных разделов и специальных директив.

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

Иногда robots.txt недостаточно, и тогда нужно ограничивать доступ на уровне сервера. Например, если xmlrpc.php не используется вообще, его можно закрыть через Nginx или Apache. Это уже не про индексацию, а про реальную блокировку.

Для Nginx это может выглядеть так:

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

Такой подход имеет смысл только если вы уверены, что XML-RPC не нужен ни одному сервису. Иначе вы сломаете внешние публикации, мобильные клиенты или интеграции, которые завязаны на этот endpoint.

Сравнение подходов: robots.txt, noindex и серверная блокировка

Подход	Что делает	Плюс	Минус
robots.txt	Подсказывает роботам не обходить URL	Безопасно для сайта, легко откатить	Не блокирует реальные запросы
noindex	Просит поисковик не индексировать страницу	Подходит для публичных страниц	Для служебных endpoint'ов часто бесполезен или неудобен
Серверная блокировка	Запрещает доступ на уровне веб-сервера	Реально ограничивает запросы	Можно сломать интеграции и AJAX

Для admin-ajax.php обычно достаточно не трогать его в серверной блокировке, а для xmlrpc.php — наоборот, часто имеет смысл именно серверный запрет, если функциональность не используется.

Пошаговое решение без лишнего риска

Сделайте резервную копию текущего robots.txt.
Проверьте, используется ли xmlrpc.php на практике.
Добавьте в robots.txt только директивы для служебных URL.
Не запрещайте весь /wp-admin/, если не понимаете, как это влияет на админку и AJAX.
После правки проверьте доступность сайта и критичных форм.

Если вы редактируете robots.txt через плагин, убедитесь, что он не переписывает файл при каждом сохранении настроек. На практике это частая причина, почему правки «исчезают» через день.

Пример проверки через PHP

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

<?php
$response = wp_remote_get( home_url( '/xmlrpc.php' ), array(
    'timeout' => 10,
) );

if ( is_wp_error( $response ) ) {
    echo $response->get_error_message();
} else {
    echo wp_remote_retrieve_response_code( $response );
}

Если серверная блокировка включена, вы увидите 403 или другой отказ в зависимости от конфигурации. Если только robots.txt — код ответа, как правило, останется обычным, потому что файл robots не влияет на HTTP-доступ.

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

Проверка должна быть не формальной, а по факту поведения сайта.

Откройте /robots.txt в браузере и убедитесь, что директивы на месте.
Проверьте, не пропали ли AJAX-формы, фильтры, поиск, загрузка контента без перезагрузки.
Если закрывали xmlrpc.php на сервере, проверьте внешние интеграции, которые могли его использовать.
Посмотрите логи через 1–2 дня: количество обращений к служебным URL должно измениться только в том сценарии, который вы реально ограничивали.

Если цель была убрать URL из индекса, проверьте отчёты поисковой системы и убедитесь, что они не появляются как отдельные страницы. Если цель была снизить нагрузку, смотрите не на robots.txt, а на серверные логи и метрики ответов.

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

Закрывают весь wp-admin

Ошибка выглядит так: Disallow: /wp-admin/. В некоторых случаях это допустимо, но если вы не понимаете, как сайт использует админские AJAX-запросы, можно получить побочные эффекты. Для точечного сценария лучше закрывать только конкретные endpoint'ы.

Путают robots.txt и защиту

Robots.txt не защищает от атак. Если цель — остановить перебор или мусорные запросы, нужен серверный запрет, ограничение по IP, WAF или настройка безопасности на уровне хостинга.

Ломают интеграции с XML-RPC

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

Редактируют robots.txt не там, где нужно

Если файл генерируется плагином, ручная правка через FTP может не пережить следующее сохранение настроек. В таком случае меняйте файл в том месте, где его контролирует система, или отключите автогенерацию.

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

Если задача — не только убрать URL из обхода, но и снизить шум на сайте, действуйте по приоритету:

robots.txt — для подсказки поисковикам;
серверная блокировка — для реально ненужных endpoint'ов;
проверка логов — чтобы увидеть, что именно создаёт нагрузку;
аудит плагинов — чтобы понять, кто вообще использует AJAX и XML-RPC.

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

Если вам нужно не просто «спрятать» служебные URL, а убрать реальную точку входа для атак, сначала определите, используется ли endpoint в рабочем процессе. Только после этого решайте, достаточно ли robots.txt или нужна блокировка на уровне сервера.