Тег-архивы в WordPress часто создают лишние точки входа в индекс: страницы с несколькими постами, слабым контентом и почти одинаковой структурой. Если теги используются только для внутренней навигации, их имеет смысл закрыть от индексации, но не удалять полностью. Иначе можно сломать переходы по сайту и потерять удобный способ группировать материалы.
Ниже — рабочий сценарий: сначала проверяем, действительно ли теги нужно закрывать, затем настраиваем noindex и canonical, после чего проверяем результат в HTML и в поисковой выдаче.
Когда тег-страницы стоит закрывать
Не каждый тег-архив — проблема. Если у вас на сайте теги используются как полноценные тематические подборки с нормальным текстом, хлебными крошками и ручной редактурой, закрывать их без анализа не стоит. Но в типовой установке WordPress теги создаются хаотично: один пост — один тег, дубли по смыслу, пустые архивы, десятки страниц с 2–3 записями.
Признаки, что теги лучше убрать из индекса
- в
/tag/много страниц с 1–3 записями; - теги дублируют категории или друг друга по смыслу;
- в Search Console есть много низкокачественных архивов;
- тег-страницы не получают трафик, но индексируются;
- на сайте нет редакционного контроля за созданием тегов.
Диагностика проблемы перед изменениями
Сначала посмотрите, как именно WordPress отдаёт тег-архивы сейчас. Откройте несколько страниц тегов и проверьте исходный код: есть ли meta robots, какой canonical указан, не закрыты ли архивы уже плагином SEO.
Если используете Yoast SEO, Rank Math или аналог, часть настроек может уже быть включена в админке. В этом случае не нужно дублировать логику кодом: два разных источника noindex иногда создают путаницу в шаблоне.
Полезно проверить и саму структуру тегов:
- сколько тегов вообще существует;
- есть ли пустые теги;
- есть ли теги с одинаковыми названиями в разных регистрах;
- не используются ли теги как замена рубрик.
Как закрыть tag-архивы в WordPress
Есть три практических варианта: через SEO-плагин, через код темы или через комбинацию настроек и шаблонов. Если нужен быстрый и безопасный путь, лучше начать с плагина. Если хотите контролировать поведение без лишних зависимостей — используйте фильтры WordPress.
| Подход | Что даёт | Минус |
|---|---|---|
| SEO-плагин | Быстрая настройка без кода | Зависимость от интерфейса и логики плагина |
| Код в теме | Полный контроль над noindex и canonical | Нужно следить за обновлениями темы |
| Комбинированный вариант | Гибкость и предсказуемость | Важно не задублировать правила |
Вариант 1: через SEO-плагин
Если у вас уже стоит Yoast SEO или Rank Math, найдите настройку архивов тегов и отключите их индексацию. Это самый простой способ, потому что плагин сам добавит нужный meta robots и обычно корректно обработает canonical.
После изменения не забудьте проверить исходный код страницы тега. Иногда настройка меняется в интерфейсе, но кэш страницы продолжает отдавать старый HTML.
Вариант 2: через код в теме или дочерней теме
Если нужен независимый от плагина способ, можно принудительно поставить noindex,follow для tag-архивов и оставить canonical на саму страницу архива. Это не удаляет страницу, но говорит поисковику не включать её в индекс.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_tag() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
add_filter( 'get_canonical_url', function( $canonical ) {
if ( is_tag() ) {
return get_term_link( get_queried_object() );
}
return $canonical;
} );Первый фильтр работает на уровне robots-мета. Второй нужен не всегда: WordPress обычно и так отдаёт canonical на текущий архив, но если тема или плагин вмешиваются в шаблон, лучше проверить вручную.
Если вы не используете стандартный <head> темы или у вас кастомная логика вывода мета-тегов, не вставляйте код вслепую. Сначала убедитесь, что фильтр wp_robots вообще отрабатывает в вашей сборке.
Вариант 3: закрыть пустые и слабые теги точечно
Иногда закрывать все теги не нужно. Тогда можно оставить индексируемыми только те, где есть нормальный контент, а остальные пометить noindex. Для этого удобнее опираться на количество записей в теге.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_tag() ) {
$term = get_queried_object();
if ( $term instanceof WP_Term && (int) $term->count < 5 ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
}
return $robots;
} );Число 5 здесь условное. Его не стоит считать универсальным порогом: смотрите на качество архива, а не только на количество постов.
Что проверить после внедрения
После настройки откройте несколько страниц тегов и проверьте три вещи:
- в исходном коде есть
meta name="robots" content="noindex,follow"или эквивалент; canonicalуказывает на эту же страницу, а не на главную или рубрику;- страница не закрыта случайно через
robots.txt, если вам всё ещё нужны переходы по ней для пользователей.
Дальше проверьте Search Console: новые директивы не всегда отражаются мгновенно, но при повторном обходе статус страницы должен измениться. Если у вас включён кэш на уровне сервера или плагина, очистите его до проверки.
Быстрая ручная проверка в браузере
- откройте тег-архив;
- посмотрите исходный код страницы;
- найдите
robotsиcanonical; - убедитесь, что нет второго conflicting meta robots от другого плагина;
- проверьте, что ссылки внутри архива работают как обычно.
Частые ошибки и как их исправить
Два источника noindex одновременно
Одна из типичных проблем — когда SEO-плагин уже ставит noindex, а вы дополнительно добавляете его кодом. В результате в HTML может появиться несколько мета-тегов, а поисковик выберет не тот, который вы ожидали. Решение простое: оставьте один источник правды.
Canonical указывает не туда
Иногда тема или кастомный плагин подменяют canonical на главную страницу или на рубрику. Это особенно заметно на архивных шаблонах, где разработчик пытался «склеить» похожие страницы. Проверьте шаблон header.php и SEO-плагин, если canonical выглядит странно.
Закрыли архив в robots.txt вместо noindex
Это не одно и то же. Если вы запретили обход в robots.txt, поисковик может не увидеть noindex на самой странице, потому что не сможет её сканировать. Для уже проиндексированных страниц чаще безопаснее использовать именно noindex, а не блокировку обхода.
Удалили теги, но не почистили внутренние ссылки
Если теги были частью навигации, после их отключения проверьте блоки «похожие записи», облако тегов и хлебные крошки. Иногда там остаются ссылки на архивы, которые уже закрыты или удалены. Это не критично, но создаёт лишние 404 и ухудшает структуру сайта.
Практические советы по безопасности и производительности
Если вы правите код темы, делайте это в дочерней теме или через небольшой mu-plugin. Так вы не потеряете изменения при обновлении. Для точечных фильтров это особенно удобно: код остаётся изолированным и не зависит от визуальной части шаблона.
Ещё один полезный момент — не плодить теги вручную без правил. На контентных сайтах лучше заранее определить, кто и по каким критериям создаёт теги. Иначе через несколько месяцев вы получите архивы, которые невозможно нормально поддерживать.
Если нужен более широкий контроль над дублями, архивами и технической чисткой сайта, можно посмотреть в сторону инструментов вроде Clearfy Pro: у него есть функции для отключения лишних архивов и управления SEO-метками. Но даже с плагином всё равно стоит понимать, что именно он меняет в шаблоне и в индексации.
Мини-чек-лист перед публикацией изменений
- проверили, не закрывает ли теги уже SEO-плагин;
- убедились, что код не дублирует существующие мета-теги;
- очистили кэш страниц и CDN;
- проверили исходный код нескольких tag-архивов;
- посмотрели, не сломались ли внутренние ссылки на теги;
- отправили страницу на повторную проверку в Search Console при необходимости.
Если задача стоит именно в снижении шума в индексе, а не в полном удалении тегов, связка noindex,follow и корректный canonical обычно даёт предсказуемый результат без лишних побочных эффектов. Главное — не смешивать несколько способов управления индексацией одновременно и всегда проверять итоговый HTML, а не только настройки в админке.