AJAX в WordPress часто оставляет после себя мусорные URL в логах, в поиске и в отчётах краулеров. Типичный пример — /wp-admin/admin-ajax.php, который сам по себе не должен быть посадочной страницей, но может попадать в обход роботов из-за ссылок, параметров или ошибок конфигурации. Если не отделить рабочие запросы от того, что реально нужно индексировать, сайт получает лишние точки обхода и шум в отчётах.
Здесь важный момент: закрывать нужно не всё подряд. Формы, фильтры, подгрузка контента и корзинные сценарии должны работать для пользователя. Задача — убрать из индекса и из обхода только технические AJAX-точки, которые не несут ценности как страницы.
Какие AJAX-URL действительно стоит проверить
В WordPress и плагинах чаще всего всплывают три сценария: admin-ajax.php, REST-запросы с параметрами, и кастомные endpoint'ы, которые разработчик повесил на отдельный URL. Сам по себе AJAX не обязан быть проблемой. Проблемой он становится, когда:
- URL доступен по GET и возвращает HTML или JSON без авторизации;
- на него есть внутренние ссылки;
- он попал в sitemap или в отчёты как отдельная страница;
- по нему можно получить дубли контента или служебные ответы с параметрами.
Диагностика проблемы
Сначала посмотрите, что именно индексируется или обходится. Для этого достаточно открыть отчёт краулера, поиск по сайту в Google и логи сервера. Если у вас есть доступ к Search Console, проверьте, нет ли там URL с admin-ajax.php или похожими служебными адресами. На сервере полезно посмотреть, какие запросы реально приходят от ботов:
grep -E "admin-ajax\.php|wp-json|ajax" access.log | tail -n 50Если в логах видны повторяющиеся запросы к одному и тому же AJAX-адресу с разными параметрами, это уже повод проверить, не отдаёт ли он лишний контент или не создаёт ли дубли.
Что закрывать, а что оставлять открытым
Не стоит пытаться запретить весь /wp-admin/ или весь /wp-json/ только потому, что там есть служебные запросы. Это ломает редактор, формы, блоки, интеграции и иногда даже фронтенд. Разделяйте сценарии по назначению.
| Вариант | Что делает | Плюс | Минус |
|---|---|---|---|
| robots.txt | Подсказывает роботам не обходить URL | Просто и быстро | Не убирает уже известные URL из индекса |
| X-Robots-Tag | Даёт директиву на уровне ответа сервера | Работает для не-HTML ответов | Нужно настраивать сервер или PHP |
| noindex в ответе | Запрещает индексацию страницы | Подходит для HTML-страниц | Для AJAX JSON обычно неприменимо |
Для admin-ajax.php чаще всего достаточно не создавать на него публичных ссылок и не включать его в sitemap. Если же какой-то плагин отдаёт через AJAX HTML-страницу, лучше убрать саму точку входа из публичного доступа или перевести её на POST с проверкой nonce и авторизации.
Пошаговое решение: как убрать служебные AJAX-URL из индекса
1. Проверьте, не генерирует ли плагин публичные ссылки
Иногда проблема не в самом AJAX, а в теме или плагине, который вставляет ссылку вида /wp-admin/admin-ajax.php?action=... в HTML. Это плохая практика. Ссылка должна вызываться через JavaScript, а не быть обычным переходом для робота.
Если у вас есть доступ к шаблону, проверьте, не выводится ли такой URL в href. Для фронтенда AJAX лучше вызывать через fetch или jQuery.post, а не через обычный a-тег.
<script>
fetch(window.ajaxurl, {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8'
},
body: new URLSearchParams({
action: 'my_filter',
nonce: MyTheme.nonce,
term: 'news'
})
})
.then(function(response) {
return response.json();
})
.then(function(data) {
console.log(data);
});
</script>В этом примере запрос не создаёт индексируемую страницу. Он нужен только для обмена данными между браузером и сервером.
2. Запретите индексацию служебного ответа на уровне сервера
Если ваш сервер или прокси позволяет добавить заголовок X-Robots-Tag, это хороший вариант для не-HTML ответов. Для admin-ajax.php можно вернуть noindex, nofollow, если вы уверены, что этот ответ не нужен в поиске.
<?php
add_action('send_headers', function () {
if (defined('DOING_AJAX') && DOING_AJAX) {
header('X-Robots-Tag: noindex, nofollow', true);
}
});Этот подход не решает проблему сам по себе, если URL уже активно обходится. Но он помогает явно показать поисковым системам, что ответ не предназначен для индексации.
3. Не добавляйте AJAX-адреса в sitemap и внутренние ссылки
Проверьте генератор карты сайта, шаблоны меню, хлебные крошки и блоки с кнопками. Служебные URL не должны попадать в sitemap.xml. Если они туда попали из-за ошибки плагина, отключите соответствующий тип записи, таксономию или шаблон генерации.
Если вы используете SEO-плагин, проверьте, не создаёт ли он отдельные карты сайта для нестандартных endpoint'ов. Иногда это происходит после установки дополнений или кастомного кода.
4. Ограничьте доступ к кастомным AJAX-обработчикам
Если AJAX-обработчик возвращает данные только для авторизованных пользователей, не оставляйте его открытым для всех. Используйте проверку nonce и прав доступа. Это не только про безопасность, но и про то, чтобы поисковый робот не получал бессмысленный ответ.
<?php
add_action('wp_ajax_my_private_action', 'my_private_action');
function my_private_action() {
check_ajax_referer('my_private_action_nonce', 'nonce');
if (!current_user_can('edit_posts')) {
wp_send_json_error(array('message' => 'Forbidden'), 403);
}
wp_send_json_success(array(
'html' => '<p>OK</p>'
));
}Если обработчик не должен быть доступен гостям, не регистрируйте его через wp_ajax_nopriv_*. Это частая ошибка, когда разработчик оставляет публичный доступ «на всякий случай».
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой на сайте. Нужно убедиться, что URL действительно перестал быть проблемным для обхода и индексации.
- Откройте служебный URL в браузере и проверьте заголовки ответа.
- Убедитесь, что он не попал в sitemap.xml.
- Проверьте, нет ли на него внутренних ссылок в HTML.
- Посмотрите логи сервера через несколько дней: бот должен реже ходить по этому адресу.
- В Search Console проверьте, не растёт ли число обнаруженных, но не проиндексированных служебных URL.
Для быстрой проверки заголовков удобно использовать curl:
curl -I https://example.com/wp-admin/admin-ajax.phpЕсли вы добавляли X-Robots-Tag, он должен быть виден в ответе. Если URL возвращает JSON, проверьте, что ответ не содержит HTML-шаблонов и не выглядит как страница сайта.
Частые ошибки и как их исправить
Закрыли весь wp-admin в robots.txt
Это грубая ошибка. wp-admin нужен не только для админки, но и для некоторых технических запросов. Полный запрет часто ломает интеграции и не решает проблему с уже известными URL. Лучше точечно работать с конкретными endpoint'ами.
Поставили noindex на всё подряд
Если вы без разбора добавили noindex на ответы, которые участвуют в работе интерфейса, можно сломать сценарии фильтрации, подгрузки и авторизации. Сначала определите, какой URL служебный, а какой реально нужен пользователю.
Оставили GET там, где должен быть POST
Публичный GET-запрос проще случайно проиндексировать и проще вызвать ботом. Если запрос меняет состояние или возвращает служебные данные, переводите его на POST и проверяйте nonce.
Забыли про кэш
Иногда вы уже закрыли URL, но кэш плагина или CDN продолжает отдавать старую версию с индексируемыми ссылками. После правок очистите кэш страницы, объектный кэш и, если есть, кэш на уровне CDN.
Практические советы по безопасности и производительности
Если AJAX используется активно, не делайте из него универсальный транспорт для всего. Чем больше логики вы вешаете на один endpoint, тем сложнее отлаживать и тем выше риск утечек. Разделяйте публичные и приватные действия, а ответы делайте минимальными по размеру.
Ещё один полезный шаг — логировать только действительно важные AJAX-события, а не каждый клик. Иначе вы получите шум в логах и лишнюю нагрузку на базу. Для тяжёлых сценариев лучше использовать отдельные REST-маршруты с понятной схемой доступа, чем перегружать admin-ajax.php.
Если вам нужно быстро почистить сайт от технических дублей, служебных страниц и лишних точек обхода, посмотрите на инструменты, которые умеют работать с SEO- и технической гигиеной WordPress, например Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, какие URL вы закрываете и почему.
Итоговая проверка простая: служебный AJAX-URL не должен быть посадочной страницей, не должен попадать в sitemap, не должен иметь внутренних ссылок и не должен возвращать контент, который можно принять за обычную страницу сайта. Если всё это выполнено, проблема решена без побочных эффектов для фронтенда.