Поисковые страницы WordPress часто попадают в индекс как тонкие и дублирующие URL: ?s=, страницы авторов, архивы по датам, внутренний поиск по тегам и другие служебные адреса. Проблема не в самом наличии этих страниц, а в том, что поисковик тратит краулинговый бюджет и иногда показывает в выдаче бесполезные URL вместо нормальных посадочных страниц.
Ниже разберём, что именно закрывать, чем это делать в WordPress и как не сломать внутренний поиск для пользователей.
Какие страницы действительно стоит закрывать
Не нужно бездумно ставить noindex на весь сайт. Для начала отделите полезные страницы от технических. В большинстве проектов под запрет индексации попадают:
- страницы поиска вида
/?s=...; - пустые или слабые архивы автора, если на сайте один автор;
- архивы по датам, если они не несут самостоятельной ценности;
- страницы вложений, если они не используются как отдельные посадочные;
- служебные результаты фильтрации, которые создают дубли.
Если у вас контентный сайт с сильной структурой архивов, не закрывайте их автоматически. Сначала проверьте, есть ли у них трафик и входящие ссылки.
Диагностика: где именно появляются дубли
Перед правками откройте Search Console и посмотрите отчёты по страницам, которые исключены или попали в индекс без описания. Дополнительно проверьте сайт вручную:
- введите запрос в поиск сайта и посмотрите URL результата;
- откройте архив автора, дату и вложение;
- проверьте исходный код страницы на наличие
meta robots; - посмотрите, не отдаются ли служебные URL со статусом
200 OKи полноценным контентом.
Если страница поиска отвечает 200 и содержит шаблонный заголовок, поисковик может индексировать её как обычную страницу. Это и есть типичный источник мусора в индексе.
Что выбрать: robots.txt, noindex или canonical
Для разных типов страниц работают разные механики. Ниже — короткое сравнение.
| Подход | Когда использовать | Ограничение |
|---|---|---|
robots.txt | Чтобы не тратить краулинг на заведомо служебные URL | Не гарантирует удаление из индекса, если URL уже известен поисковику |
noindex | Чтобы запретить индексацию конкретной страницы | Страница должна быть доступна для обхода, иначе директива может не быть прочитана |
canonical | Когда есть дубль, но нужна одна основная версия | Не подходит для совсем бесполезных страниц поиска |
Для поисковых страниц обычно лучше сочетать noindex, follow и аккуратную настройку robots.txt. Для архивов автора и дат — зависит от структуры сайта.
Пошаговое решение через код
Если вы не хотите полагаться только на SEO-плагин, можно добавить точечные правила в тему или в небольшой mu-plugin. Это надёжнее, чем пытаться закрыть всё одной строкой в robots.txt.
1. Добавляем noindex для поисковых страниц и архивов автора
<?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;
}
if ( is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот фильтр есть в WordPress и работает через стандартный механизм генерации robots meta. Он не ломает страницу для пользователя, но подсказывает поисковику не индексировать её.
2. Убираем индексирование страниц вложений
Если у вас медиафайлы открываются как отдельные страницы без смысла для поиска, можно перенаправлять их на сам файл или родительскую запись. Самый безопасный вариант — редирект на родительский пост, если он есть.
<?php
add_action('template_redirect', function() {
if ( is_attachment() ) {
$parent = wp_get_post_parent_id( get_queried_object_id() );
if ( $parent ) {
wp_safe_redirect( get_permalink( $parent ), 301 );
exit;
}
wp_safe_redirect( home_url('/'), 301 );
exit;
}
});Так вы не оставляете в индексе пустые страницы вложений, которые часто появляются после загрузки изображений в редакторе.
3. Ограничиваем служебные поисковые URL в robots.txt
robots.txt не заменяет noindex, но помогает снизить лишний обход. Если у вас есть фильтры или параметры, которые создают мусорные URL, добавьте только то, что реально нужно.
User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /author/
Disallow: /date/
Sitemap: https://example.com/sitemap_index.xmlНе закрывайте в robots.txt всё подряд, если потом хотите, чтобы поисковик увидел noindex на этих страницах. Для уже известных URL это особенно важно.
Если используете SEO-плагин
В Yoast SEO, Rank Math и похожих плагинах обычно есть настройки для архивов автора, дат и страниц вложений. Это удобно, если проект ведётся без кода. Но проверяйте, что именно делает плагин: иногда он ставит noindex, иногда только меняет каноникал, а иногда оставляет страницу доступной для индексации.
Если у вас уже стоит плагин для чистки дублей, например Clearfy Pro, проверьте, не дублирует ли он правила темы или другого SEO-модуля. Два источника одинаковых директив — частая причина странного поведения в head.
Как проверить, что решение сработало
После внедрения не ограничивайтесь просмотром кода страницы. Проверьте несколько уровней:
- откройте страницу поиска и убедитесь, что в
<head>естьnoindex; - проверьте, что архив автора и дата тоже получили нужную директиву;
- откройте вложение и убедитесь, что срабатывает редирект;
- посмотрите HTTP-статус через DevTools или
curl -I; - в Search Console отправьте URL на повторную проверку, если он уже был в индексе.
Пример проверки через консоль:
curl -I https://example.com/?s=test
curl -I https://example.com/author/admin/
curl -I https://example.com/sample-attachment/Для страниц с noindex в HTML полезно открыть исходник и найти строку вида <meta name="robots" content="noindex,follow" />. Формат может отличаться в зависимости от темы и плагина, но смысл должен быть тот же.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но она осталась в индексе
Это нормальная ситуация. Если URL уже известен поисковику, одного Disallow недостаточно. Добавьте noindex или редирект, а потом дождитесь переобхода.
Поставили noindex на страницу, но она всё равно ранжируется
Проверьте, не конфликтует ли правило с кэшем, SEO-плагином или кастомным выводом meta robots в теме. Иногда в HTML остаётся старый тег из-за серверного или плагинного кэша.
Закрыли архивы автора, а потом потеряли полезные страницы
Так бывает на блогах с несколькими сильными авторами. Если архивы дают трафик, не закрывайте их целиком. Лучше оставьте индексируемыми только те, где есть уникальное описание, фото автора и нормальная навигация.
Сделали редирект с вложений на главную
Это плохой дефолт. Для медиа лучше вести на родительскую запись, а не на главную страницу. Иначе вы теряете смысловую связь и ухудшаете пользовательский сценарий.
Практические советы по безопасности и производительности
Если вы добавляете код вручную, не вносите его прямо в активную тему без контроля версий. Лучше использовать дочернюю тему или mu-plugin. Так вы не потеряете правки после обновления.
- перед изменениями сделайте резервную копию файлов и базы;
- проверьте, не генерирует ли кэш старые мета-теги после правки;
- не закрывайте полезные страницы только ради «чистого индекса»;
- если сайт большой, меняйте правила поэтапно и отслеживайте переобход;
- не смешивайте в одном месте логику SEO, редиректов и шаблонов без необходимости.
Если задача шире и нужно системно убрать дубли, служебные URL и мусорные мета-данные, имеет смысл смотреть в сторону инструментов вроде Clearfy Pro, но только как в дополнение к понятной логике правил, а не вместо неё.