В WordPress почти на каждом сайте со временем появляются служебные URL, которые не должны попадать в поиск: страницы логина, служебные архивы, вложения, результаты некоторых внутренних сценариев, тестовые шаблоны, страницы с параметрами, которые не несут ценности для пользователя. Проблема не в самом факте их существования, а в том, что поисковик может тратить на них обход, а в индексе они начинают конкурировать с нормальными страницами.
Задача обычно решается не одним способом. Где-то нужен noindex, где-то достаточно запрета в robots.txt, а где-то лучше вообще убрать генерацию URL на уровне темы или плагина. Ниже — практический разбор без лишней теории.
Какие страницы в WordPress обычно стоит проверить в первую очередь
Не все служебные URL одинаково вредны. Одни просто бесполезны для поиска, другие могут создавать дубли, а третьи вообще не должны быть доступны без авторизации или прямой необходимости. Начинать стоит с аудита того, что реально индексируется.
Типовые кандидаты на закрытие
- страницы авторизации и восстановления пароля;
- архивы без полезной навигационной ценности;
- вложенные медиа-страницы, если они не используются как отдельные посадочные;
- страницы с параметрами сортировки, фильтрации и служебными query string;
- технические шаблоны, которые выводят пустой или почти пустой контент;
- страницы тестового контента, оставшиеся после разработки.
Если у вас уже закрыты дубли авторов, архивов, поиска и старых версий страниц, следующий логичный шаг — посмотреть на технические URL, которые создаются не контентом, а поведением темы, плагинов и шаблонов.
Диагностика проблемы: как понять, что именно надо закрывать
Сначала не трогайте настройки вслепую. Проверьте, какие URL уже есть в индексе и откуда они берутся. Это экономит время и помогает не закрыть то, что должно ранжироваться.
Что смотреть в Google Search Console и в исходном коде
- отчёт по индексированию страниц с пометками
noindex,blocked by robots.txt,duplicate; - страницы, которые попали в индекс по шаблонным URL;
- наличие мета-тега
robotsв HTML; - заголовки ответа сервера, если запрет ставится на уровне HTTP;
- ссылки в меню, хлебных крошках, футере и блоках похожих записей.
Если URL не должен быть найден поиском, но на него есть внутренние ссылки, поисковик всё равно будет его обходить. Поэтому сначала ищем источник генерации, потом решаем, закрывать ли страницу от индексации или убирать саму ссылку.
Быстрая проверка через консоль
Если есть доступ к серверу, полезно посмотреть, как отвечает конкретный URL. Для этого не нужен сложный стек — достаточно curl.
curl -I https://example.com/wp-login.phpИщите в ответе заголовки вроде X-Robots-Tag, редиректы и код ответа. Если страница отдает 200 OK и при этом должна быть скрыта от индекса, значит, запрет пока не настроен или настроен не там, где нужно.
Что выбрать: noindex, robots.txt или удаление ссылки
У каждого способа свой сценарий применения. Ошибка многих сайтов — пытаться закрыть всё через robots.txt. Это не всегда работает так, как ожидается: поисковик может не увидеть запрет на уровне контента и продолжить хранить URL в индексе как известный, но не просканированный.
| Подход | Когда использовать | Плюс | Ограничение |
|---|---|---|---|
noindex | Страница доступна, но не должна быть в выдаче | Явный сигнал поисковику | Страницу нужно разрешить к обходу |
robots.txt | Нужно ограничить обход служебных URL | Снижает нагрузку на crawl budget | Не гарантирует удаление из индекса |
| Удаление ссылки/шаблона | URL не должен существовать для пользователей | Самый чистый вариант | Требует правки темы или плагина |
Практически это выглядит так: если страница нужна пользователю, но не нужна в поиске — ставим noindex. Если URL вообще не должен обходиться — ограничиваем через robots.txt или убираем генерацию. Если URL случайно создается темой или плагином, лучше исправить источник.
Пошаговое решение: как закрыть технические страницы в WordPress
Шаг 1. Закрыть конкретную страницу через мета robots
Для отдельных страниц самый предсказуемый вариант — вывести <meta name="robots" content="noindex,follow"> в <head>. В WordPress это можно сделать через хук wp_head, если нужен точечный контроль.
add_action('wp_head', function () {
if (is_page('thank-you') || is_page('test-page')) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});Такой вариант подходит для страниц благодарности, тестовых лендингов, внутренних посадочных и любых URL, которые не должны ранжироваться. Если страница уже в индексе, после переобхода поисковик должен увидеть запрет и убрать её со временем.
Шаг 2. Ограничить служебные URL в robots.txt
Если нужно сократить обход системных адресов, можно добавить правила в robots.txt. Это не замена noindex, а отдельный инструмент для экономии обхода.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /*?replytocom=Здесь важно не переборщить. Если закрыть слишком много, поисковик может перестать нормально обходить важные разделы. Например, /wp-admin/ обычно закрывают, но admin-ajax.php оставляют доступным, потому что он нужен фронтенду и некоторым плагинам.
Шаг 3. Убрать ненужные ссылки из темы или плагина
Если URL создается автоматически, правильнее убрать сам источник. Например, если тема выводит ссылки на вложения или пустые архивы, лучше отключить это в шаблоне, чем потом пытаться лечить последствия в индексе.
add_filter('post_type_link', function ($permalink, $post) {
if ($post->post_type === 'attachment') {
return '';
}
return $permalink;
}, 10, 2);Этот пример не универсален и не всегда нужен. Но логика понятна: если URL не должен существовать как рабочая точка входа, не надо полагаться только на мета-теги. Сначала убирайте генерацию, потом закрывайте остатки.
Шаг 4. Для массовых сценариев использовать SEO-плагин
Если на сайте много шаблонных страниц и нет желания поддерживать это кодом, удобнее настроить правила в SEO-плагине. У таких решений обычно есть управление noindex для архивов, медиа, таксономий и отдельных типов записей. Это полезно, когда нужно централизованно управлять индексированием без правки темы.
Из практики: если вы уже используете инструмент для чистки дублей и технических настроек, проверьте, не дублирует ли он правила в robots.txt и мета-тегах. Два разных источника запрета иногда создают путаницу при отладке.
Проверка результата после внедрения
После изменений важно не просто открыть страницу в браузере, а проверить, что поисковый робот увидит именно тот сигнал, который вы ожидаете.
Чек-лист проверки
- страница отдает нужный код ответа, обычно
200или301, если был редирект; - в HTML есть
noindex, если вы использовали мета-тег; - в
robots.txtнет случайного запрета на важные разделы; - страница не появляется в меню, хлебных крошках и внутренних блоках без необходимости;
- в Search Console URL доступен для проверки и переобхода;
- через несколько обходов страница уходит из индекса или перестает попадать в новые отчёты.
Для быстрой локальной проверки можно посмотреть HTML-ответ:
curl -s https://example.com/test-page/ | grep -i robotsЕсли мета-тег не выводится, значит, условие в коде не сработало или страница определяется не тем шаблоном, который вы ожидали. Если тег есть, но страница всё равно в индексе, проверьте, не блокируется ли она одновременно в robots.txt. В таком случае поисковик может не увидеть noindex при обходе.
Частые ошибки и как их исправить
Закрыли в robots.txt, но не поставили noindex
Это самая частая ошибка. Страница перестает обходиться, но уже известный URL может оставаться в индексе как отдельная сущность. Если цель — убрать страницу из выдачи, нужен именно noindex или удаление URL с редиректом/404, а не только запрет обхода.
Поставили noindex на страницу, которую сами же прячете в robots.txt
Так делать можно не всегда. Если робот не может зайти на страницу, он не увидит мета-тег. В результате URL может висеть в индексе дольше, чем вы рассчитывали. Для удаления из индекса сначала дайте роботу увидеть страницу, потом уже ограничивайте обход, если это действительно нужно.
Закрыли слишком широкий шаблон
Например, условие в коде сработало не только на тестовую страницу, но и на все записи одного типа. Итог — важные страницы перестали индексироваться. Проверяйте условия через точные идентификаторы, слаг или шаблон страницы, а не через слишком общий фильтр.
Оставили внутренние ссылки на закрытую страницу
Если страница больше не нужна, уберите на неё ссылки из меню, виджетов, блоков и шаблонов. Иначе поисковик будет продолжать её обходить, а пользователи — попадать в тупик.
Путают удаление из индекса и скрытие от пользователей
noindex не делает страницу приватной. Если на странице есть чувствительные данные, нужен не мета-тег, а авторизация, ограничение доступа или удаление URL из публичной зоны.
Безопасность и производительность: что не стоит делать
Технические страницы часто пытаются закрыть «на всякий случай». Это плохая стратегия. Чем больше случайных запретов, тем сложнее отлаживать сайт после обновлений темы, плагинов и ядра.
- не закрывайте весь
wp-adminбез понимания, как это повлияет на AJAX и фронтенд-скрипты; - не блокируйте в
robots.txtто, что должно быть доступно для переобхода и снятия из индекса; - не полагайтесь только на плагины, если URL генерирует тема;
- не оставляйте тестовые страницы с открытым доступом после запуска проекта;
- не используйте одинаковые правила для всех сайтов без проверки структуры шаблонов.
Если на сайте много технического мусора, сначала уберите его источник: лишние шаблоны, неиспользуемые архивы, дублирующие блоки, лишние ссылки. Уже потом настраивайте индексацию. Такой порядок обычно дает более стабильный результат, чем попытка закрыть всё одним файлом robots.txt.
Если нужен инструмент, который помогает централизованно чистить технические дубли и управлять SEO-настройками, имеет смысл смотреть в сторону решений уровня Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином базовая логика не меняется: сначала диагностика, потом точечное правило, потом проверка в индексе.