Если в индексе всплывают страницы поиска, архивы с параметрами, служебные URL плагинов или пустые таксономии, проблема обычно не в «плохом SEO», а в том, что WordPress по умолчанию не знает, какие страницы для вас технические, а какие — контентные. Закрывать всё подряд нельзя: можно случайно убрать из поиска полезные посадочные страницы. Поэтому здесь нужен не общий совет, а точная схема: найти тип URL, выбрать способ закрытия и проверить, что поисковик видит именно то, что вы задумали.
Какие страницы обычно нужно закрывать
На практике чаще всего мешают не отдельные записи, а служебные и дублирующие URL. У них нет самостоятельной ценности для пользователя, но они расходуют краулинговый бюджет и создают шум в индексе.
- страницы внутреннего поиска вида
?s=; - архивы автора и даты, если на сайте один автор или архивы не несут пользы;
- страницы с параметрами фильтров и сортировки;
- служебные страницы плагинов, если они доступны публично;
- пустые рубрики, метки и другие таксономии без контента;
- страницы пагинации, если они создают дубли и не нужны в поиске.
Важно различать robots.txt и noindex. Первый управляет обходом, второй — индексацией. Если страница уже в индексе, одного запрета в robots.txt часто недостаточно: поисковик может оставить URL в выдаче без сниппета. Для удаления из индекса обычно нужен noindex или заголовок X-Robots-Tag.
Диагностика: как понять, что именно попало в индекс
Сначала не правьте файлы наугад. Проверьте, какие URL реально индексируются и откуда они берутся. Для этого удобно смотреть отчёты в Google Search Console, а на самом сайте — список URL с параметрами и архивами.
Что проверить вручную
- введите в поиск по сайту
site:example.comи посмотрите типы страниц; - откройте исходный код подозрительной страницы и найдите
meta name="robots"; - проверьте, не генерирует ли тема или плагин отдельные архивы;
- посмотрите, не добавляет ли sitemap URL, которые вы хотите скрыть.
Если у вас уже стоит SEO-плагин, сначала проверьте его настройки. Часто проблема решается без кода: плагин уже умеет закрывать архивы, таксономии и страницы поиска. Но если нужно точечно закрыть только часть URL, код даёт больше контроля.
Пошаговое решение через robots.txt и noindex
Ниже рабочая схема для типичного сайта на WordPress. Сначала ограничиваем обход в robots.txt, затем добавляем noindex для страниц, которые не должны попадать в индекс, но могут быть уже известны поисковику.
1. Закрываем служебные разделы в robots.txt
Если у вас есть доступ к редактированию robots.txt, добавьте только те правила, которые действительно нужны. Не блокируйте CSS и JS, если это не служебные файлы. Поисковик должен видеть страницу так же, как пользователь.
User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Этот вариант подходит для внутреннего поиска и административной части. Если поиск у вас работает по другому шаблону URL, подставьте свой путь. Но не пытайтесь закрыть всё через robots.txt, если страница уже в индексе: для удаления нужен следующий шаг.
2. Добавляем noindex для конкретных типов страниц
Для точечного управления удобнее использовать фильтр wp_robots. Он есть в современных версиях WordPress и позволяет добавить директиву без правки шаблонов темы.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
return $robots;
} );
Этот пример закрывает поиск, архивы автора и даты. Если архивы автора вам нужны, уберите is_author(). Если даты полезны для новостного проекта, тоже не закрывайте их автоматически. Логика должна соответствовать структуре сайта, а не шаблону из статьи.
3. Для отдельных URL используем X-Robots-Tag
Когда нужно закрыть не шаблон страницы, а конкретный тип ответа, удобен заголовок X-Robots-Tag. Он полезен для файлов, служебных endpoint’ов и нестандартных страниц, где нет нормального HTML-шаблона.
<?php
add_action( 'send_headers', function() {
if ( isset( $_SERVER['REQUEST_URI'] ) && str_contains( $_SERVER['REQUEST_URI'], '/search/' ) ) {
header( 'X-Robots-Tag: noindex, nofollow', true );
}
} );
Здесь важно не переусердствовать: проверяйте условие максимально точно. Если вы начнёте ловить слишком широкий набор URL, можно случайно закрыть обычные страницы. Для сложных правил лучше писать отдельную функцию и тестировать её на staging-сайте.
Сравнение подходов: что выбрать в реальной задаче
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| robots.txt | Нужно ограничить обход служебных URL | Просто и быстро | Не удаляет уже проиндексированные страницы |
| noindex через wp_robots | Нужно убрать страницу из индекса | Работает на уровне HTML | Нужно дождаться переобхода |
| X-Robots-Tag | Нестандартные ответы, файлы, endpoint’ы | Подходит для не-HTML ресурсов | Требует аккуратной логики в коде |
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковик видит правильные сигналы, а не только что страница «как будто закрыта».
- Откройте страницу и посмотрите исходный код: должен быть
noindex, если вы его добавляли. - Проверьте заголовки ответа через
curl -I https://example.com/...и убедитесь, чтоX-Robots-Tagотдаётся там, где нужно. - В Google Search Console отправьте URL на проверку и посмотрите, как робот видит страницу.
- Через несколько переобходов проверьте, исчез ли URL из отчёта по индексированию.
Если страница всё ещё в индексе, это не всегда ошибка. Поисковику нужно время, чтобы пересобрать данные. Но если прошло достаточно времени, а URL не меняет статус, ищите конфликт: другой плагин может переопределять robots-мета, а кэш — отдавать старую версию страницы.
Частые ошибки и как их исправить
Закрыли в robots.txt, но URL остался в выдаче
Это типичная ситуация. Robots.txt запрещает обход, но не гарантирует удаление из индекса. Добавьте noindex или заголовок X-Robots-Tag и дождитесь переобхода.
Случайно закрыли полезные страницы
Часто это происходит из-за слишком широкого условия, например, когда в коде закрывают все архивы, а потом выясняется, что часть из них приносит трафик. Решение простое: сначала отключите правило, затем перепишите его точнее, с учётом конкретных шаблонов и типов контента.
Плагин SEO и код дают разные директивы
Если один плагин ставит index,follow, а другой — noindex, поисковик может получить конфликтующие сигналы. В такой ситуации оставьте один источник правды: либо настройки SEO-плагина, либо собственный код. Два слоя управления почти всегда создают путаницу.
Кэш отдаёт старую версию страницы
После изменения robots-мета или заголовков очистите кэш страницы, серверный кэш и CDN, если он есть. Иначе вы будете проверять уже не тот ответ, который видит бот.
Практические советы по безопасности и производительности
Не храните логику закрытия в случайных сниппетах без контроля версий. Лучше вынести код в маленький mu-plugin или в отдельный плагин сайта. Так правило не исчезнет после смены темы и не потеряется при обновлении.
Если сайт большой, не добавляйте тяжёлые проверки в каждый запрос. Условие должно быть дешёвым: проверка типа страницы, пути запроса или конкретного query var. Для сложных сценариев лучше использовать настройки плагина или отдельный слой маршрутизации.
Если вам нужно одновременно убрать дубли, закрыть технические страницы и почистить sitemap, имеет смысл смотреть в сторону инструментов, которые умеют управлять индексируемостью централизованно. Например, Clearfy Pro полезен именно там, где нужно быстро отключить архивы, дубли и служебные элементы без ручной правки каждого шаблона.
Когда лучше не закрывать страницу
Не закрывайте URL только потому, что он «не основной». Если страница получает трафик, отвечает на отдельный запрос или помогает навигации, её закрытие может ухудшить видимость сайта. Сначала оцените, есть ли у страницы самостоятельная ценность. Если да — возможно, ей нужен не noindex, а доработка контента, canonical или нормализация параметров.
Хорошее правило простое: закрываем то, что не должно участвовать в поиске, но не ломаем структуру сайта ради формального «чистого индекса». На WordPress это особенно важно, потому что технические страницы часто появляются не из-за ошибки, а из-за стандартного поведения темы, плагинов и фильтров.