В WordPress часто нужно закрыть от поиска не весь сайт, а только конкретные страницы: результаты поиска, архивы с дублями, служебные URL, тестовые разделы, страницы пагинации в некоторых сценариях. Ошибка здесь типичная: ставят noindex везде подряд, а потом удивляются, почему поисковик перестал видеть нужные страницы или почему в индексе остаются старые URL.
Разберём, чем отличаются robots.txt, noindex и canonical, когда использовать каждый вариант и как проверить, что закрытие работает без побочных эффектов.
Когда проблема действительно в индексации, а не в настройках SEO-плагина
Сначала нужно понять, что именно происходит. Если страница есть в поиске, но не должна там быть, это один сценарий. Если страница не индексируется, хотя должна, — другой. Не смешивайте их: одинаковое решение для обоих случаев обычно ломает видимость сайта.
Признаки лишней индексации
- В поиске всплывают страницы внутреннего поиска WordPress с параметром
?s=. - Индексируются архивы автора на сайтах, где один автор и архивы не несут пользы.
- В выдаче есть страницы пагинации, которые дублируют основной архив.
- В индексе остаются технические страницы после миграции или чистки контента.
Что проверить до изменений
- Есть ли у страницы реальный контент и трафик.
- Не используется ли она как точка входа из внутренних ссылок.
- Не закрыта ли она уже в SEO-плагине или в теме.
- Не стоит ли на ней редирект, который маскирует проблему.
Если страница уже получает переходы из поиска, не закрывайте её только потому, что она кажется «служебной». Сначала проверьте запросы и фактическую роль URL в структуре сайта.
Что выбрать: robots.txt, noindex или canonical
Эти механизмы решают разные задачи. robots.txt запрещает обход, но не гарантирует удаление из индекса, если URL уже известен поисковику. noindex говорит не индексировать страницу, но для этого поисковик должен её увидеть. canonical помогает указать основную версию, когда есть дубли.
| Подход | Когда применять | Ограничения |
|---|---|---|
robots.txt | Для служебных разделов, которые не должны обходиться | Не убирает уже известные URL из индекса мгновенно |
noindex | Для страниц, которые можно обойти, но не нужно показывать в поиске | Нужно, чтобы поисковик мог увидеть мета-тег или заголовок ответа |
canonical | Для дублей и близких версий одной страницы | Не подходит для полного скрытия служебных URL |
На практике чаще всего нужен noindex для архивов, поиска и пагинации, а canonical — для дублей с параметрами. robots.txt оставляют для экономии краулингового бюджета, но не как единственный способ убрать URL из выдачи.
Пошаговое решение через код: закрываем отдельные типы страниц
Если не хочется зависеть от интерфейса SEO-плагина или нужно точечно управлять логикой, можно добавить фильтры в тему или мини-плагин. Ниже пример для WordPress, который ставит noindex,follow на внутренний поиск, архивы автора и страницы пагинации архивов.
<?php
add_filter('wp_robots', function (array $robots) {
if (is_search() || is_author() || is_paged()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот вариант работает на уровне стандартного API WordPress и не требует выдуманных хуков. Но использовать его нужно аккуратно: is_paged() закрывает вообще все страницы пагинации, а это не всегда правильно. Если у вас есть разделы, где пагинация должна индексироваться, лучше уточнить условие.
Более точечный вариант для архивов и поиска
Если нужно закрыть только конкретные типы страниц, лучше разделить условия. Например, внутренний поиск и архивы автора можно закрыть, а остальные архивы оставить открытыми.
<?php
add_filter('wp_robots', function (array $robots) {
if (is_search()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if (is_author() && ! is_admin()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Если на сайте установлен SEO-плагин, он может уже выводить свои мета-теги. Тогда важно не дублировать noindex двумя способами одновременно. Иначе в HTML появятся конфликтующие инструкции, а диагностика станет сложнее.
Как закрыть дубли через canonical, а не через запрет индексации
Если проблема не в служебной странице, а в дубле, лучше не прятать URL, а указать основную версию. Это актуально для страниц с параметрами сортировки, фильтрации или UTM-метками, если они создают отдельные URL с тем же контентом.
В WordPress canonical часто уже выводится автоматически. Но если тема или плагин вмешиваются в <head>, проверьте, не ломается ли ссылка на основную версию страницы.
<?php
add_filter('get_canonical_url', function ($canonical, $post) {
if ($post instanceof WP_Post && has_category('news', $post)) {
return get_permalink($post);
}
return $canonical;
}, 10, 2);Этот пример полезен только как шаблон логики. Не подменяйте canonical без причины: если у страницы есть реальные вариации контента, поисковик может начать игнорировать важные версии.
Диагностика после внедрения: как понять, что всё сработало
Проверка нужна не только в браузере. Откройте исходный код страницы и убедитесь, что нужная директива действительно присутствует. Затем проверьте ответ сервера и поведение поискового робота.
- Посмотрите исходный HTML и найдите
<meta name="robots"или заголовокX-Robots-Tag, если он используется. - Проверьте, что на закрытых страницах нет конфликтующего canonical на другой URL без причины.
- Откройте страницу в Google Search Console и посмотрите, как её видит робот.
- Если закрывали дубль, убедитесь, что основная страница осталась индексируемой.
Для быстрой проверки можно использовать curl и посмотреть заголовки ответа:
curl -I https://example.com/?s=testЕсли вы используете X-Robots-Tag на уровне сервера или плагина, он должен быть виден в заголовках. Если работает только мета-тег в HTML, заголовок не появится — это нормально, но тогда проверяйте именно исходник страницы.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt и ждёте мгновенного удаления
Это не всегда работает. Если URL уже известен поисковику, он может оставаться в индексе без возможности переобхода. Для удаления из выдачи обычно нужен noindex или корректная переобработка через Search Console.
Ставят noindex на всё подряд
Так часто ломают архивы, категории и даже полезные посадочные страницы. Сначала определите, какие URL реально мусорные, а какие просто не нравятся визуально.
Используют canonical вместо noindex для служебных страниц
Canonical не скрывает страницу как таковую. Если URL служебный и не должен попадать в поиск, canonical — не замена noindex.
Дублируют управление в теме и SEO-плагине
Если часть правил живёт в коде темы, а часть — в настройках плагина, легко получить конфликт. Лучше выбрать один источник правды: либо код, либо плагин, либо разделить зоны ответственности.
Чек-лист перед публикацией изменений
- Поняли, какой тип страницы нужно закрыть: дубль, служебный URL или архив.
- Проверили, не приносит ли страница трафик и не нужна ли она пользователю.
- Выбрали правильный механизм:
noindex,canonicalилиrobots.txt. - Убедились, что правило не конфликтует с SEO-плагином.
- Проверили исходный HTML и заголовки ответа.
- Сверили результат в Search Console после переобхода.
Что делать, если нужен более удобный контроль без правки кода
Если задача повторяется часто и на сайте много дублей, удобнее управлять техническими настройками через один инструмент, а не разносить логику по теме и сниппетам. В таких случаях полезны плагины, которые умеют чистить лишние мета-теги, управлять индексацией и не плодить конфликты в <head>. Например, для части таких задач подходит Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Но даже с плагином принцип остаётся тем же: сначала определяете тип страницы и только потом выбираете способ закрытия. Иначе можно скрыть не то, что нужно, и получить лишнюю работу по переиндексации.
Проверка результата через 2–3 типовых сценария
После внедрения прогоните несколько реальных URL:
- внутренний поиск с запросом;
- архив автора;
- страница пагинации архива;
- дубль с параметром, если он есть на сайте.
У каждого URL должно быть предсказуемое поведение: либо noindex, либо canonical на основную страницу, либо отсутствие обхода через robots.txt там, где это оправдано. Если результат отличается, ищите конфликт в теме, SEO-плагине или серверных правилах.