Старые архивы, страницы тегов, авторов, дат и внутренние поисковые выдачи часто остаются в индексе дольше, чем нужно. На небольшом сайте это просто шум в отчётах, на крупном — лишние дубли, размывание краулингового бюджета и странные URL в поиске. Проблема обычно не в том, что WordPress «плохо индексируется», а в том, что сайт годами накапливает технические страницы без понятной политики индексации.
Ниже — рабочая схема: что именно закрывать, что лучше редиректить, как это сделать через плагин или код и как проверить, что поисковик действительно увидел изменения.
Какие страницы обычно стоит проверить в первую очередь
Не все архивы нужно закрывать. Если у вас блог, часть архивов может приносить трафик и быть полезной для навигации. Но есть типовые кандидаты на noindex или удаление из индекса:
- страницы внутренних поисковых результатов вида
?s=; - архивы по датам, если они не используются как полноценная навигация;
- архивы авторов на сайтах с одним автором;
- страницы тегов, если теги создаются без системы и дублируют категории;
- служебные страницы пагинации, если они не несут самостоятельной ценности;
- страницы вложений медиафайлов, если они индексируются отдельно и дают пустой контент.
Если у вас уже есть статьи в индексe по этим URL, сначала решите: страницу нужно оставить, но закрыть, или удалить/редиректить. Это разные действия. Noindex не заменяет 301-редирект, если URL больше не должен существовать как отдельная сущность.
Диагностика: где именно возникает проблема
Перед правками откройте отчёты в Google Search Console и посмотрите, какие типы страниц попадают в индекс. Для WordPress полезно проверить ещё и сам шаблон страницы: часто noindex уже есть, но только в одном месте, а архивы тегов или поиск остались открытыми.
Что проверить вручную
- исходный код страницы: есть ли
<meta name="robots" content="noindex,follow">; - HTTP-заголовок
X-Robots-Tag, если он используется на уровне сервера; - канонический URL: не указывает ли он на саму служебную страницу;
- robots.txt: не блокирует ли он обход там, где вам нужен noindex через сканирование;
- наличие дублей: одинаковые заголовки, описания и контент на нескольких архивах.
Важно: если вы закрыли страницу в robots.txt, но хотите, чтобы поисковик убрал её из индекса, этого может быть недостаточно. Бот должен увидеть страницу и её директиву noindex либо получить явный редирект/удаление.
Пошаговое решение: плагин или код
Есть два нормальных пути. Первый — использовать SEO-плагин и настроить индексацию через интерфейс. Второй — добавить точечные правила в тему или мини-плагин. Если задача типовая, плагин быстрее и безопаснее для редактора. Если нужна тонкая логика по ролям, типам записей или условиям, удобнее код.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Нужно быстро закрыть архивы, теги, поиск | Меньше риска, есть интерфейс | Не всегда хватает гибкости |
| Код в мини-плагине | Нужны точные условия для конкретного сайта | Полный контроль | Нужно тестировать после обновлений |
| robots.txt | Нужно ограничить обход, но не обязательно индексацию | Просто внедрить | Не решает задачу удаления из индекса |
Вариант 1: закрыть архивы через SEO-плагин
Если у вас уже стоит плагин с настройками для архивов и мета-robots, используйте его. Например, в Clearfy Pro есть инструменты для чистки сайта и удаления дублей; это как раз тот случай, когда удобнее централизованно отключить лишние архивы, чем править шаблоны вручную. Если используете другой SEO-плагин, логика та же: найдите настройки для архивов авторов, дат, тегов и внутренних поисков.
После изменения не ограничивайтесь галочкой в админке. Откройте несколько URL и проверьте исходный код. Иногда шаблон темы или другой плагин переопределяет robots-мета.
Вариант 2: точечное noindex через код
Если нужно закрыть только внутренний поиск и архивы тегов, можно добавить фильтр в мини-плагин или functions.php. Ниже пример для классической темы или дочерней темы:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_tag() || is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант работает на современных версиях WordPress, где используется фильтр wp_robots. Он аккуратнее, чем ручная печать meta-тега в wp_head, потому что не конфликтует с ядром и другими плагинами, если они тоже используют стандартный механизм.
Если нужно закрыть только внутренний поиск, а архивы оставить открытыми, сузьте условие:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Когда нужен редирект, а не noindex
Если страница больше не должна существовать вообще, ставьте 301-редирект на ближайший релевантный URL. Например, старый архив автора на сайте с одним автором можно перенаправить на страницу «О проекте» или на главную, если это логично по структуре. Для удалённых тегов — на категорию или на страницу-замену, если она реально соответствует теме.
Пример через template_redirect для очень узкого сценария: редиректить архивы автора на страницу о сайте, если автор один.
<?php
add_action( 'template_redirect', function() {
if ( is_author() ) {
wp_redirect( home_url( '/o-proekte/' ), 301 );
exit;
}
} );Не используйте такой редирект бездумно на многoавторском блоге: вы сломаете навигацию и потеряете полезные страницы.
Как не перепутать noindex, canonical и robots.txt
Это три разных инструмента, и они решают разные задачи. Если смешать их без понимания, можно получить страницу, которая не индексируется, но продолжает висеть в поиске как «URL без описания», или наоборот — закрыть обход и не дать поисковику увидеть noindex.
- noindex — страница может быть просканирована, но не должна попадать в индекс;
- canonical — указывает предпочтительный URL среди похожих страниц;
- robots.txt — ограничивает обход, но не гарантирует удаление из индекса.
Практически: если у вас тег-архив дублирует категорию, иногда лучше оставить страницу доступной, но поставить canonical на более сильную категорию. Если тег бесполезен сам по себе — noindex. Если URL вообще не нужен — 301-редирект или 410, если вы уверены, что страница удалена окончательно.
Проверка результата после внедрения
После правок не полагайтесь на «вроде всё работает». Проверьте три уровня: HTML, заголовки и индекс.
- Откройте страницу в браузере и посмотрите исходный код.
- Проверьте, что в
<head>появилсяnoindex,followили нужный canonical. - Если используете серверные заголовки, проверьте их через
curl. - Отправьте URL на повторную проверку в Search Console.
Пример проверки заголовков:
curl -I https://example.com/?s=testВ ответе ищите либо X-Robots-Tag: noindex, либо убедитесь, что страница отдаёт HTML с мета-robots. Если у вас редирект, проверьте код ответа 301 и конечный URL.
В Search Console смотрите не только статус «Индексируется/не индексируется», но и причину. Если URL всё ещё в индексе, а вы поставили noindex вчера, это нормально: поисковику нужно время на переобход. Если же страница заблокирована robots.txt, а вы ждёте удаления из индекса, причина может быть именно в этом.
Частые ошибки и как их исправить
Закрыли в robots.txt, но не поставили noindex
Это самая частая ошибка. Страница перестаёт обходиться, но может продолжать отображаться в индексе как URL без содержимого. Исправление: убрать блокировку, дать боту увидеть страницу и отдать noindex, либо сделать 301/410.
Поставили noindex на шаблон, но тема печатает второй robots-тег
Такое бывает при конфликте SEO-плагина и ручного кода в теме. В исходнике появляется два meta-тега robots, и поисковик может интерпретировать их не так, как вы ожидали. Исправление: оставить один источник правды — либо плагин, либо код.
Закрыли архивы, которые реально дают трафик
Если теговая страница ранжируется по узкому запросу и приводит целевых посетителей, не закрывайте её только потому, что она «архив». Сначала посмотрите запросы и поведение в аналитике. Иногда лучше улучшить страницу, чем убирать её из индекса.
Сделали 301 на нерелевантную страницу
Редирект на главную «на всякий случай» — плохая практика. Если замена не соответствует смыслу старого URL, поисковик и пользователь получают мусорный переход. Лучше удалить страницу, оставить noindex или подобрать действительно близкий аналог.
Практические советы по безопасности и производительности
Если вы закрываете много служебных страниц кодом, не вносите правки напрямую в родительскую тему. Используйте дочернюю тему или мини-плагин, чтобы обновление не затёрло изменения. Для крупных сайтов удобнее держать такие правила отдельно: это проще тестировать и откатывать.
Не плодите тяжёлые проверки в каждом запросе. Условия is_search(), is_tag(), is_author() и похожие дешёвые, но если вы добавляете сложную логику по мета-данным или SQL-запросам, это уже повод вынести решение в плагин и кэшировать результат.
Если задача шире, чем одна-две страницы, имеет смысл использовать инструменты для чистки дублей и технических настроек. В экосистеме WPShop для этого подходит Clearfy Pro: он закрывает типовые SEO- и технические настройки без ручного вмешательства в шаблоны. Но даже с плагином проверка исходного кода и Search Console остаётся обязательной.
Мини-чек-лист перед публикацией изменений
- определили, что именно закрываем: noindex, canonical или редирект;
- проверили, не приносит ли страница трафик и запросы;
- убрали конфликтующие правила из темы и плагинов;
- проверили исходный код и HTTP-заголовки;
- отправили изменённые URL на переобход;
- сверили статус в Search Console через несколько дней после индексации.
Если после правок в индексе всё ещё остаются старые URL, это не всегда ошибка. Иногда поисковик просто не успел переобойти страницу. Но если через несколько циклов обхода ничего не меняется, ищите конфликт в шаблоне, редиректах или robots.txt — обычно проблема там, а не в самом noindex.