В WordPress чаще всего индексируются не те страницы, которые реально нужны: внутренний поиск с пустыми или странными запросами, архивы с параметрами сортировки, страницы пагинации, фильтры по меткам и таксономиям. На небольшом сайте это выглядит как мелочь, но в Search Console такие URL быстро превращаются в шум: дубли, страницы с низкой ценностью и лишняя нагрузка на краулинг.
Если задача не в том, чтобы «просто поставить noindex на всё подряд», а в том, чтобы аккуратно убрать мусор и не сломать полезные разделы, лучше идти от диагностики к точечным правилам. Ниже — рабочий сценарий для типичного WordPress-сайта без выдуманных хуков и без магии.
Что именно нужно закрывать от индексации
Не все архивы одинаково бесполезны. Например, архив рубрики может быть важной посадочной страницей, а вот результаты внутреннего поиска почти всегда не должны попадать в индекс. То же касается URL с параметрами фильтрации, если они не несут самостоятельной ценности.
Типичные кандидаты на noindex
- страницы внутреннего поиска вида
?s=запрос; - архивы с параметрами сортировки и фильтрации;
- страницы пагинации, если они создают много слабых дублей;
- служебные архивы автора, даты, меток — если они не используются как контентные разделы;
- страницы с пустыми результатами поиска.
Перед изменениями важно понять, какие URL уже попали в индекс и как именно они выглядят. Иначе легко закрыть не то, что нужно, и потом долго разбираться, почему трафик просел.
Диагностика: где искать проблему
Сначала проверьте Search Console и серверные логи, если они доступны. В Search Console смотрите отчеты по страницам, исключенным из индекса, и по страницам с дублирующимся контентом. Важно не просто увидеть «много URL», а понять шаблон: это поиск, архивы, пагинация или параметры.
Полезно открыть несколько проблемных URL вручную и посмотреть исходный код страницы. Если там уже есть noindex, а Google все равно показывает URL в отчете, значит проблема не в отсутствии мета-тега, а в том, что страница уже была обнаружена и еще не переобработана.
Для быстрой проверки можно использовать такой чек-лист:
- есть ли у URL параметр
?s=или другие query string; - возвращает ли страница осмысленный контент или пустую выдачу;
- есть ли canonical на саму страницу или на более чистый URL;
- не закрыт ли раздел robots.txt слишком грубо;
- не дублируется ли контент через архивы, теги и поиск одновременно.
Пошаговое решение: ставим noindex точечно
Если у вас установлен SEO-плагин, сначала проверьте, умеет ли он управлять индексированием архивов и поисковых страниц. Это удобнее, чем писать все вручную, но не всегда достаточно для параметров и нестандартных шаблонов.
Если нужен код, самый безопасный путь — добавить noindex, follow только на нужные типы страниц. Для этого можно использовать фильтр wp_robots, который доступен в современных версиях WordPress.
<?php
add_filter( 'wp_robots', function( $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if ( is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант подходит, если вы хотите закрыть именно шаблонные страницы WordPress. Но он не решает вопрос с URL, которые создаются параметрами фильтрации или сторонними плагинами.
Как закрыть страницы с параметрами
Если на сайте есть фильтры, которые генерируют URL с параметрами вроде ?sort=, ?filter= или ?page=, лучше не закрывать весь сайт, а отсеивать только конкретные комбинации. Ниже пример для простого сценария: если в URL есть параметр сортировки или фильтра, добавляем noindex.
<?php
add_filter( 'wp_robots', function( $robots ) {
$blocked_params = array( 'sort', 'filter', 'orderby' );
foreach ( $blocked_params as $param ) {
if ( isset( $_GET[ $param ] ) && $_GET[ $param ] !== '' ) {
$robots['noindex'] = true;
$robots['follow'] = true;
break;
}
}
return $robots;
} );Здесь важный момент: не стоит использовать этот подход бездумно для всех GET-параметров. На некоторых сайтах параметры нужны для нормальной работы интерфейса, и закрывать их целиком нельзя.
Сравнение подходов: плагин, код или robots.txt
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Нужно быстро закрыть стандартные архивы | Удобно, без кода | Не всегда покрывает параметры и нестандартные шаблоны |
Код через wp_robots | Нужна точечная логика | Гибко, прозрачно | Требует аккуратности и тестов |
robots.txt | Нужно снизить обход мусорных URL | Просто ограничить краулинг | Не гарантирует исключение из индекса, если URL уже известен |
Если задача именно в индексации, robots.txt не должен быть единственным инструментом. Он помогает уменьшить обход, но не заменяет noindex на самой странице.
Когда стоит использовать canonical, а не noindex
Если у вас есть несколько URL с почти одинаковым содержимым, но один из них должен остаться основным, лучше использовать canonical. Например, для страниц с сортировкой можно оставить основную категорию как каноническую, а параметры не индексировать.
Но canonical не спасает, если страница вообще не должна участвовать в поиске. Для внутреннего поиска и пустых результатов canonical обычно не решает задачу — там нужен именно noindex.
Проверка результата после внедрения
После изменений не ждите мгновенного эффекта. Сначала проверьте HTML конкретной страницы: в исходном коде должен появиться мета-робот с noindex или соответствующий HTTP/HTML-атрибут, если его добавляет плагин.
Дальше сделайте три проверки:
- откройте проблемный URL в браузере и посмотрите исходный код;
- проверьте URL через инструмент проверки страницы в Search Console;
- через несколько дней сравните количество таких URL в отчетах по индексированию.
Если страница все еще индексируется, но уже содержит noindex, это обычно вопрос переобхода и переобработки, а не ошибки в коде. Если же noindex отсутствует, ищите конфликт плагинов или тему, которая переопределяет robots-мета.
Частые ошибки и как их исправить
Закрыли слишком много страниц
Самая частая ошибка — поставить noindex на все архивы подряд. В итоге исчезают полезные страницы рубрик, которые могли приносить трафик. Решение простое: сначала отключайте только поиск, даты и авторов, а рубрики и теги трогайте только после анализа.
Используют только robots.txt
Если URL уже попал в индекс, запрет в robots.txt не удалит его автоматически. Google может продолжать показывать адрес без контента. Для удаления нужен noindex или корректный редирект на релевантную страницу.
Конфликт SEO-плагина и кода
Если плагин уже добавляет свои robots-мета, а вы сверху навесили фильтр, может получиться противоречивый набор директив. Проверяйте исходный код страницы и оставляйте только один источник правды.
Параметры фильтрации не учтены
На сайтах с фильтрами часто забывают про URL вида ?orderby=, ?filter_* и другие параметры, которые создают бесконечные комбинации. Их нужно перечислять явно, а не пытаться ловить все подряд.
Безопасность и производительность
Если вы добавляете код в functions.php, лучше делать это в дочерней теме или через небольшой mu-plugin. Так меньше риск потерять изменения после обновления темы. Для сайта с активной разработкой это еще и удобнее для контроля версий.
Не стоит закрывать страницы через редиректы без причины. Массовые редиректы с параметров на главную часто ухудшают качество сигналов для поисковика и мешают диагностике. Если URL должен просто не индексироваться, обычно достаточно noindex, follow и нормального canonical там, где он уместен.
Если нужен более широкий аудит дублей, технической чистки и индексации, имеет смысл смотреть в сторону инструментов, которые помогают управлять дублями и техническими настройками сайта, например Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Что проверить сразу после правки
- в исходном коде проблемных страниц есть
noindex; - полезные рубрики и статьи не получили лишний запрет;
- страницы поиска больше не выглядят как полноценные посадочные;
- в Search Console нет новых всплесков дублей по параметрам;
- canonical на основных страницах не сломан и указывает на правильный URL.
Если после внедрения вы видите, что поисковик все еще держит старые URL в индексе, не спешите менять схему. Сначала убедитесь, что новые правила реально отдаются сервером, а потом дайте поисковым системам время переобойти сайт.