Служебные страницы вроде /wp-login.php, /wp-register.php или кастомных URL для входа часто попадают в индекс не потому, что они нужны пользователю, а потому что их кто-то случайно открыл, на них ведут внешние ссылки или они доступны без ограничений. Для сайта это почти всегда лишний шум: в поиске появляются бесполезные URL, а в отчётах по индексации растёт количество страниц без ценности.
Задача здесь не в том, чтобы «спрятать» вход в админку любой ценой, а в том, чтобы правильно закрыть от индексации именно служебные страницы и не сломать авторизацию, восстановление пароля и редиректы после логина.
Как понять, что проблема действительно есть
Прежде чем что-то менять, проверьте, что именно индексируется. В Google Search Console и Яндекс.Вебмастере ищите URL с признаками служебных страниц: wp-login, login, register, lost-password, reset-password, а также кастомные страницы входа, если они создавались плагином.
На самом сайте откройте такие URL и посмотрите, что отдаётся в HTML. Если страница доступна для робота, но в ней нет полезного контента, её лучше закрыть от индексации. Если же это публичная страница регистрации для membership-сайта, решение может быть другим: не удалять её из индексации полностью, а оставить только нужные URL и убрать технические дубли.
Что проверить в первую очередь
- Есть ли в индексе URL с
/wp-login.phpили кастомным логином. - Не создаёт ли плагин отдельные страницы для входа, регистрации и сброса пароля.
- Нет ли дублей с параметрами вроде
?redirect_to=или?action=lostpassword. - Не закрыт ли случайно доступ к нужной странице для обычных пользователей.
Какие варианты решения есть и чем они отличаются
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| meta robots noindex | Для отдельных служебных страниц | Просто внедрить, не ломает доступ | Нужно убедиться, что страница реально отдает HTML |
| X-Robots-Tag в заголовке | Для PHP-страниц и нестандартных URL | Работает даже без правки шаблона | Требует аккуратной настройки на сервере или в коде |
| robots.txt | Для снижения обхода роботом | Быстрое ограничение crawl | Не гарантирует удаление из индекса, если URL уже известен |
На практике для WordPress лучше использовать не один способ, а комбинацию: noindex для самой страницы и, при необходимости, robots.txt для снижения лишнего обхода. Если URL уже в индексе, robots.txt сам по себе проблему не решит.
Пошаговое решение через код
Если у вас есть кастомная страница входа или регистрации в теме или плагине, самый надёжный способ — добавить noindex на уровне шаблона. Это не влияет на работу формы, но подсказывает поисковику не включать страницу в индекс.
1. Добавьте meta robots noindex на служебные страницы
<?php
add_action('wp_head', function () {
if (is_page(array('login', 'register', 'lost-password', 'reset-password'))) {
echo '<meta name="robots" content="noindex, nofollow" />' . "\n";
}
});
Этот пример подходит для страниц, которые существуют как обычные записи WordPress. Если у вас другие слаги, замените массив на свои значения. Для страницы входа, сделанной через плагин, иногда удобнее использовать фильтр самого плагина или отдельный шаблон страницы.
2. Закройте системные URL через X-Robots-Tag
Для wp-login.php и похожих PHP-эндпоинтов meta-тег не всегда применим, потому что это не обычная страница темы. В таком случае можно отдать заголовок X-Robots-Tag.
<?php
add_action('login_init', function () {
header('X-Robots-Tag: noindex, nofollow', true);
});
Этот вариант полезен, если вы не хотите менять серверную конфигурацию. Но он должен выполняться до вывода любого контента, иначе заголовок не отправится. Если на сайте уже есть вывод до header(), проверьте, нет ли лишних пробелов или раннего echo в подключаемых файлах.
3. Добавьте правила в robots.txt только как дополнительный слой
Если нужно уменьшить обход служебных URL, можно закрыть их в robots.txt. Это не замена noindex, а вспомогательная мера.
User-agent: *
Disallow: /wp-login.php
Disallow: /wp-register.php
Disallow: /?action=lostpassword
Disallow: /?action=register
С параметрами в robots.txt есть нюанс: поисковики не всегда трактуют их одинаково, а часть URL может быть доступна по другим путям. Поэтому сначала ставьте noindex, а robots.txt используйте как дополнительное ограничение обхода.
Если используется плагин для скрытия логина
Многие плагины меняют URL входа на кастомный, например /my-login/. Это удобно, но часто создаёт новые проблемы: старая страница остаётся доступной по прямому адресу, появляются редирект-цепочки, а в индекс попадает и старая, и новая версия.
В такой ситуации проверьте три вещи:
- Старый
/wp-login.phpотдаёт редирект на новый URL или закрыт от индексации. - Новый URL не открыт для индексации, если он нужен только для авторизации.
- Страница восстановления пароля не дублируется на нескольких адресах.
Если плагин позволяет задать noindex для страницы логина — включите это. Если нет, проще добавить собственный фильтр или шаблон, чем надеяться, что поисковик сам «поймёт» назначение URL.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой. Нужно убедиться, что страница действительно отдаёт нужные сигналы для робота.
- Откройте URL в браузере и посмотрите исходный код страницы.
- Проверьте наличие
<meta name="robots" content="noindex, nofollow" />или заголовкаX-Robots-Tag. - В Search Console отправьте URL на повторную проверку, если он уже был в индексе.
- Через несколько дней проверьте статус URL в отчёте по индексированию.
Для быстрой диагностики удобно использовать curl:
curl -I https://example.com/wp-login.php
В ответе ищите заголовок X-Robots-Tag. Если его нет, значит код не сработал или выполняется слишком поздно. Для обычной страницы можно посмотреть HTML и убедиться, что meta robots реально присутствует в <head>.
Частые ошибки и как их исправить
Закрыли URL в robots.txt, но он всё равно в индексе
Это ожидаемо. Robots.txt ограничивает обход, но не удаляет уже известный URL из индекса. Добавьте noindex и дождитесь переобхода.
Поставили noindex на страницу и сломали редирект после входа
Сама директива noindex не ломает редирект. Проблема обычно в другом: плагин авторизации или тема неправильно обрабатывают redirect_to, либо на странице входа есть лишняя логика, которая мешает отправке формы.
Закрыли не ту страницу
Часто путают страницу входа с публичной страницей регистрации. Если регистрация нужна пользователям, не закрывайте её бездумно. Лучше закрыть только технические варианты с параметрами и оставить один канонический URL.
Использовали nofollow вместо noindex
nofollow не означает запрет индексации самой страницы. Для служебных URL нужен именно noindex, а nofollow — дополнительная опция, если не хотите передавать ссылки дальше.
Безопасность и производительность: что учесть дополнительно
Если вы закрываете страницу входа от индексации, это не делает её защищённой. Для безопасности всё равно нужны ограничение попыток входа, двухфакторная аутентификация и актуальные обновления. С точки зрения производительности полезно убрать лишние редирект-цепочки и не плодить дубли URL с параметрами.
Если на сайте много технических дублей, имеет смысл проверить и другие служебные страницы: поиск по сайту, архивы с пустым контентом, страницы вложений, результаты фильтров. Для этого уже полезны инструменты чистки дублей и SEO-настроек, например возможности Clearfy Pro, если вы используете такой стек, но сам принцип остаётся тем же: не индексировать то, что не несёт самостоятельной ценности.
Мини-чек-лист перед публикацией изменений
- Проверен список URL, которые должны быть закрыты.
- На нужных страницах есть
noindexилиX-Robots-Tag. - Служебные URL не закрыты только через robots.txt.
- Нет редирект-цепочек между старым и новым логином.
- В Search Console отправлен запрос на переобход.
- Проверено, что авторизация и восстановление пароля работают.
Если задача сводится к одному-двум URL, правка в теме или небольшом плагине обычно надёжнее, чем тяжёлое SEO-решение. Для WordPress это как раз тот случай, когда точечный код даёт больше контроля, чем попытка «починить всё» одним общим плагином.