Внутренний поиск, архивы по датам, автору, тегам и служебные страницы часто создают лишние URL, которые не дают трафик, но забирают краулинговый бюджет и размывают качество индекса. Если сайт небольшой, это не всегда критично. Но на проектах с большим количеством записей такие страницы быстро превращаются в источник дублей и мусорных страниц в поиске.
Задача здесь не в том, чтобы закрыть всё подряд. Нужен точечный контроль: что оставить в индексе, что пометить как noindex, follow, а что вообще не должно попадать в выдачу. Ниже — рабочий сценарий для WordPress без выдуманных хуков и без опасных правок ядра.
Когда noindex действительно нужен
Сначала стоит понять, какие страницы у вас создаются автоматически. В WordPress это обычно:
- страницы внутреннего поиска вида
/?s=...; - архивы по датам, если они не несут самостоятельной ценности;
- архивы авторов на сайтах с одним автором;
- архивы тегов, если теги используются хаотично и дублируют рубрики;
- страницы пагинации, если они не нужны для поиска.
Не стоит ставить noindex на всё подряд. Например, рубрики с нормальной структурой и трафиком лучше оставить открытыми. Иначе можно потерять полезные посадочные страницы.
Диагностика проблемы: что именно попадает в индекс
Перед настройкой проверьте, какие URL уже индексируются. Самый простой путь — поиск по сайту в Google с оператором site: и просмотр отчёта «Страницы» в Google Search Console. Если там много адресов с ?s=, /author/, /tag/ или /date/, это уже повод для настройки.
Полезно также открыть исходный код проблемной страницы и посмотреть, есть ли там уже мета-тег robots. Иногда тема или SEO-плагин добавляют его частично, а на некоторых шаблонах он отсутствует совсем.
Что проверить до изменений
- есть ли SEO-плагин, который уже управляет robots meta;
- не закрыты ли нужные архивы случайно через
robots.txt; - не используется ли кэш, который показывает старую версию head;
- не конфликтуют ли настройки темы и плагина.
Пошаговое решение: добавляем noindex через код
Если у вас нет SEO-плагина или вы хотите точечно управлять мета-роботами, можно добавить фильтр в functions.php дочерней темы или в собственный мини-плагин. Для WordPress это самый предсказуемый способ, потому что он не зависит от генерации шаблона.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if ( is_author() && count_users()['total_users'] <= 1 ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if ( is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if ( is_tag() && ! has_term( '', 'category' ) ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот код использует стандартный фильтр wp_robots, который есть в современных версиях WordPress. Он безопаснее, чем ручная вставка meta-тега в шаблон, потому что не ломает разметку и не требует правки header.php.
Если нужно закрыть только поиск, оставьте в коде один блок is_search(). Не добавляйте лишние условия, если не понимаете, как они повлияют на индексацию.
Когда лучше использовать SEO-плагин
Если на сайте уже стоит SEO-плагин, логичнее управлять robots meta через него, а не через код. Это снижает риск конфликта и упрощает поддержку. Но важно проверить, не дублирует ли плагин ваш собственный фильтр.
| Подход | Плюсы | Минусы |
|---|---|---|
Код через wp_robots | Точный контроль, не зависит от шаблона | Нужно следить за обновлениями и условиями |
| SEO-плагин | Удобно для редакторов, меньше ручной работы | Возможны конфликты настроек и лишняя нагрузка |
| Правка шаблона | Быстро для теста | Хрупко, легко сломать при обновлении темы |
Если нужен noindex только для внутреннего поиска
Частый сценарий — закрыть именно страницы поиска, но оставить архивы открытыми. Тогда не трогайте остальные условия и используйте более узкую проверку. Это особенно полезно, если у вас есть нормальные рубрики и теги, которые реально приводят трафик.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Такой вариант проще сопровождать: если позже понадобится убрать noindex с поиска, вы удалите один блок, а не будете разбирать сложную логику.
Проверка результата после внедрения
После сохранения изменений не ограничивайтесь просмотром страницы в браузере. Проверка должна быть технической:
- Откройте проблемную страницу в режиме инкогнито.
- Посмотрите исходный код и найдите
meta name="robots"или заголовок robots, если он отдается через плагин/сервер. - Убедитесь, что для поиска, архива или даты указан
noindex. - Проверьте несколько типов страниц отдельно: поиск, автор, тег, дата.
- Если используется кэш, очистите его и повторите проверку.
В Google Search Console изменения не отображаются мгновенно. Но если страница была переобходена, в отчете по индексации вы увидите, что робот получил новую инструкцию. Для массовой проверки удобно использовать просмотр исходного HTML и поиск по строке noindex.
Частые ошибки и как их исправить
Закрыли нужные страницы вместо мусорных
Это происходит, когда noindex ставят на все архивы без анализа. Если рубрики дают трафик, их лучше не трогать. Исправление простое: уберите лишние условия и оставьте только проблемные типы страниц.
Используют одновременно несколько источников robots meta
Например, код в теме, SEO-плагин и ручная вставка в шаблон. В итоге на странице может появиться конфликтующая разметка. Решение: оставьте один источник управления robots meta.
Путают noindex и disallow
noindex говорит поисковику не индексировать страницу, а Disallow в robots.txt запрещает обход. Это не одно и то же. Если закрыть URL в robots.txt, поисковик может не увидеть мета-тег noindex. Для служебных страниц обычно безопаснее сначала ставить noindex, а не блокировать обход.
Не чистят кэш после правки
На сайтах с кэшем старый meta-тег может показываться еще некоторое время. Если проверяете изменения и не видите результата, сначала очистите серверный и плагинный кэш, потом повторите тест.
Практические советы по безопасности и производительности
Не вносите такие правки напрямую в родительскую тему: после обновления они пропадут. Лучше использовать дочернюю тему или небольшой кастомный плагин. Если проект обслуживает несколько человек, храните код в репозитории, чтобы изменения были отслеживаемыми.
Если у вас большой сайт, не пытайтесь решать проблему только через noindex. Параллельно проверьте внутреннюю перелинковку, структуру рубрик и дубли в тегах. Иногда проще убрать источник мусорных URL, чем постоянно закрывать его от индексации.
Для сайтов с большим количеством архивов полезно также проверить, не создают ли лишние страницы фильтры, параметры URL и поиск по сайту. Если такие страницы уже есть, noindex — это только часть решения, а не замена нормальной структуры контента.
Если нужен более широкий контроль над дублями, мета-тегами и системными страницами, можно посмотреть в сторону Clearfy Pro, но даже в этом случае полезно понимать, какие именно URL вы закрываете и зачем.
