Страницы входа и регистрации почти никогда не должны попадать в поиск. У них нет ценности для посетителя, зато есть риск дублей, лишних URL в индексе и ненужной нагрузки на краулер. На практике проблема обычно не в самом wp-login.php, а в том, что на сайте появляются отдельные страницы с формой входа, регистрации, сброса пароля или закрытые разделы, которые поисковик всё равно находит.
Ниже разберём, как закрыть такие страницы от индексации без поломки авторизации и как проверить, что поисковые системы действительно перестали их учитывать.
Когда это становится проблемой
Сигналы обычно простые: в отчётах Search Console появляются URL вида /wp-login.php, /my-account/, /register/ или кастомные страницы входа; в выдаче видны страницы с формой логина; в логах заметно, что боты часто ходят на служебные URL. Если сайт небольшой, это может быть не критично. Но на проектах с большим количеством закрытых страниц такие URL начинают мешать нормальной индексации.
Что именно нужно закрывать
wp-login.phpи связанные с ним служебные запросы;- страницы входа и регистрации, если они сделаны отдельными страницами;
- страницы сброса пароля и подтверждения email, если они доступны по постоянным URL;
- служебные страницы плагинов, которые дублируют форму авторизации.
Важно не путать индексацию и доступ. Закрыть страницу от индексации — не значит сломать вход пользователям. Обычно достаточно корректных заголовков, мета-тега robots и, при необходимости, правил в robots.txt.
Диагностика: где именно индексируется лишнее
Сначала проверьте, какие URL уже попали в поиск. Для этого используйте оператор site: и отчёт «Страницы» в Google Search Console. Если у вас есть доступ к серверным логам, посмотрите, какие адреса чаще всего запрашивают поисковые боты. Это поможет понять, проблема в стандартном wp-login.php или в кастомной странице.
Полезно проверить и исходный код страницы. Если на странице входа уже есть <meta name="robots" content="noindex, nofollow">, но URL всё равно индексируется, значит поисковик может получать противоречивые сигналы: например, страница доступна по ссылкам, а в robots.txt она не закрыта, или наоборот.
Мини-чек-лист перед правками
- Есть ли отдельная страница входа или регистрации?
- Используется ли плагин, который создаёт свои служебные URL?
- Есть ли ссылки на эти страницы в меню, футере или письмах?
- Не закрыт ли нужный URL только в
robots.txtбезnoindex? - Не мешает ли кэш показывать старую версию страницы после правок?
Рабочие способы закрыть страницы от индексации
Лучший вариант зависит от того, как именно устроен сайт. Если нужна быстрая и предсказуемая настройка, можно использовать SEO-плагин. Если нужен контроль на уровне кода, лучше добавить заголовки и мета-теги вручную. Если задача касается только одного URL, иногда достаточно правил robots.txt, но это не самый надёжный способ в одиночку.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Нужно быстро закрыть отдельные страницы | Просто настроить, меньше риска сломать сайт | Зависимость от плагина, не всегда гибко |
| Код в теме/плагине | Нужен точный контроль над URL | Работает без лишних интерфейсов | Требует аккуратности и тестирования |
robots.txt | Нужно ограничить обход | Быстро и понятно | Не гарантирует удаление из индекса |
Вариант 1: закрыть страницу через мета robots
Если у вас отдельная страница входа или регистрации, добавьте noindex на конкретный шаблон или URL. Ниже пример для кастомной страницы с логином. Код можно разместить в дочерней теме или в небольшом функциональном плагине.
<?php
add_action('wp_head', function () {
if (is_page(array('login', 'register', 'reset-password'))) {
echo '<meta name="robots" content="noindex, nofollow" />' . "\n";
}
});Этот вариант хорош, когда URL известны заранее. Для служебных страниц WordPress, вроде wp-login.php, такой способ не всегда применим напрямую, потому что это не обычная страница записи.
Вариант 2: добавить заголовок X-Robots-Tag для wp-login.php
Для wp-login.php удобнее отправлять HTTP-заголовок X-Robots-Tag. Так поисковик получит явный сигнал, даже если страница не имеет обычного HTML-шаблона.
<?php
add_action('login_init', function () {
header('X-Robots-Tag: noindex, nofollow', true);
});Этот код должен выполняться до вывода любого HTML. Если на сайте уже есть плагин безопасности или кастомный редирект для логина, проверьте, что заголовок не конфликтует с другими обработчиками.
Вариант 3: ограничить обход через robots.txt
Если нужно снизить нагрузку на обход, можно добавить правила в robots.txt. Но важно понимать: запрет в robots.txt не удаляет URL из индекса сам по себе. Если страница уже известна поисковику, он может оставить её в выдаче без содержимого.
User-agent: *
Disallow: /wp-login.php
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpДля wp-admin это стандартная практика, но не стоит закрывать admin-ajax.php, если тема или плагины используют AJAX на фронтенде.
Пошаговое решение для типового сайта
Если нужен практичный порядок действий, я бы делал так: сначала закрывал бы отдельные страницы входа и регистрации через noindex, затем добавлял бы X-Robots-Tag для wp-login.php, и только после этого проверял бы, нужно ли дополнять robots.txt.
- Определите все URL, связанные с авторизацией и регистрацией.
- Добавьте
noindex, nofollowна кастомные страницы. - Для
wp-login.phpвключите заголовокX-Robots-Tag. - Проверьте, нет ли внутренних ссылок на эти страницы в меню и футере.
- Очистите кэш страницы и серверный кэш, если он есть.
- Переобойдите URL в Search Console и отправьте запрос на переиндексацию, если страница уже была в индексе.
Как проверить, что решение сработало
Проверка должна быть не визуальной, а технической. Откройте страницу в браузере и посмотрите исходный код: на кастомной странице должен появиться noindex. Для wp-login.php проверьте заголовки ответа, например через DevTools или curl.
curl -I https://example.com/wp-login.phpВ ответе должен быть заголовок вида X-Robots-Tag: noindex, nofollow. Если его нет, проверьте, не мешает ли кэш, и не перехватывает ли запрос другой плагин.
Дальше откройте Search Console и используйте проверку URL. Если страница уже была проиндексирована, удаление из выдачи может занять время. Это нормально: поисковик сначала должен переобойти страницу и увидеть новый сигнал.
Что считать успешным результатом
- в исходном коде есть
noindexна нужных страницах; - в ответе сервера для
wp-login.phpприсутствуетX-Robots-Tag; - страница не появляется в новых результатах поиска по
site:; - в Search Console уменьшается число URL со статусом, связанным с индексацией служебных страниц.
Частые ошибки и как их исправить
Закрыли URL только в robots.txt
Это частая ошибка. Поисковик может перестать обходить страницу, но уже известный URL останется в индексе. Если цель — именно убрать страницу из поиска, нужен noindex или X-Robots-Tag.
Поставили noindex, но забыли про кэш
После изменения шаблона страница может ещё какое-то время отдавать старую версию из кэша. Очистите кэш плагина, серверный кэш и CDN, если он используется.
Закрыли не тот URL
На практике часто закрывают только /login/, а в индексе остаётся /my-account/ или страница сброса пароля. Сначала соберите список всех служебных адресов, потом вносите правки.
Сломали авторизацию для пользователей
Иногда разработчики добавляют жёсткий редирект или блокировку для всех неавторизованных запросов. Это может мешать форме входа, AJAX-запросам и восстановлению пароля. Проверяйте сценарий входа в приватном окне после каждого изменения.
Безопасность и производительность: что стоит учесть
Если на сайте много попыток входа, закрытие страниц от индексации не решит проблему брутфорса. Для этого нужны отдельные меры: ограничение попыток входа, двухфакторная аутентификация, смена URL входа только если это оправдано, и нормальная защита на уровне сервера или плагина безопасности.
С точки зрения производительности важно не добавлять тяжёлую логику в каждый запрос. Если вы используете код, ограничьте его только нужными хуками и не проверяйте лишние условия на всех страницах сайта. Для типового проекта достаточно точечной проверки is_page() и отдельного обработчика для login_init.
Если у вас уже стоит SEO-плагин, сначала проверьте его возможности. В некоторых случаях проще закрыть служебные страницы там, чем поддерживать собственный код. Если нужен более широкий контроль над дублями, служебными страницами и технической чисткой сайта, можно посмотреть в сторону решений класса Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpreg.ru&utm_medium=article&utm_campaign=kak-zapretit-indeksaciyu-stranic-avtorizacii-i-registracii-v-wordpress
Но даже с плагином полезно знать, какие именно URL вы закрываете и каким способом. Тогда проще понять, почему страница всё ещё висит в индексе: из-за кэша, старых ссылок, отсутствия noindex или потому что поисковик ещё не переобошёл адрес.