На WordPress дубли часто появляются не из-за ошибки в теме, а из-за того, как сайт одновременно отдаёт архивы тегов, рубрик, авторов, дат и отдельные страницы пагинации. В итоге поисковик видит несколько почти одинаковых URL, а владелец сайта получает размытый индекс и лишние страницы в sitemap.
Ниже разберём практический сценарий: как найти такие дубли, что можно закрыть от индексации, а что лучше оставить, и как проверить, что после правок сайт не потерял нужные страницы.
Когда проблема действительно в дублях
Сначала стоит убедиться, что речь не о нормальной пагинации или о разных страницах с осмысленным содержимым. Дубли в WordPress обычно выглядят так:
- один и тот же пост доступен через несколько архивов тегов;
- в sitemap попадают архивы, которые не несут ценности для поиска;
- страницы тегов повторяют рубрики почти без отличий;
- архивы с пагинацией индексируются как отдельные посадочные страницы без уникального контента;
- дубли появляются из-за параметров URL, например
?amp,?replytocomили трекинговых меток, если их не отсекать на уровне каноникализации.
Быстрая диагностика
Откройте в поиске Google запрос site:example.com tag или site:example.com inurl:tag и посмотрите, сколько теговых архивов реально попало в индекс. Затем проверьте sitemap и сравните список URL с тем, что вы хотите видеть в поиске. Если в sitemap есть страницы, которые вы не продвигаете и не поддерживаете контентом, это уже кандидат на исключение.
Полезно также посмотреть исходный код проблемной страницы и найти тег rel="canonical". Если canonical указывает не туда, поисковик может считать дублем даже нормальную страницу.
Что лучше закрывать, а что оставить
Не все архивы нужно отключать. Если теговая страница у вас собрана вручную, содержит вводный текст, подборку материалов и реально ранжируется, её можно оставить. Если это просто список постов без описания и с пересечением с рубрикой, пользы от индексации обычно мало.
| Вариант | Когда подходит | Минус |
|---|---|---|
| Оставить в индексе | Есть уникальный текст, трафик и понятный интент | Нужно поддерживать качество страницы |
| Закрыть noindex | Архив технический, дублирует рубрику или не нужен в поиске | Страница останется доступной, но не должна ранжироваться |
| Удалить из sitemap | URL не нужен для обхода и не должен подсказываться поисковику | Нужно следить, чтобы он не был важной посадочной |
Пошаговое решение без лишнего риска
1. Уберите из sitemap то, что не должно индексироваться
Если вы используете SEO-плагин, сначала проверьте его настройки. Во многих случаях проще отключить архивы тегов или дат, чем потом бороться с последствиями в индексе. Если нужен кодовый вариант, можно исключить таксономию из sitemap через фильтр плагина, но только если вы точно знаете, какой плагин стоит на сайте. Универсальнее — отключить сам архив от индексации и не добавлять его в карту сайта на уровне SEO-плагина.
Если у вас Yoast SEO, можно убрать таксономию из sitemap через фильтр:
add_filter( 'wpseo_sitemap_exclude_taxonomy', function( $exclude, $taxonomy ) {
if ( 'post_tag' === $taxonomy ) {
return true;
}
return $exclude;
}, 10, 2 );Этот вариант уместен, если теговые архивы вам не нужны вообще. Если теги используются как навигация и часть из них полезна, не отключайте всё подряд.
2. Поставьте noindex на слабые архивы
Для архивов, которые должны оставаться доступными пользователю, но не участвовать в поиске, лучше использовать noindex, follow. Это особенно полезно для авторских архивов, дат и нерелевантных тегов. В WordPress это можно сделать через SEO-плагин или через код, если нужен точечный контроль.
add_filter( 'wp_robots', function( $robots ) {
if ( is_tag() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Такой подход не ломает навигацию по сайту, но сигнализирует поисковику не индексировать теговые архивы. Если у вас уже есть SEO-плагин, проверьте, не конфликтует ли он с этим фильтром: два разных источника robots-правил могут дать неожиданный результат.
3. Настройте canonical на основную страницу
Если дубль возникает из-за параметров URL или пагинации, canonical должен указывать на основную версию страницы. Для архивов это обычно делает SEO-плагин автоматически. Но если тема или кастомный код подменяют canonical, проверьте шаблон и фильтры.
Для собственных страниц можно задать canonical вручную:
add_action( 'wp_head', function() {
if ( is_tag() ) {
$term = get_queried_object();
if ( $term && ! is_wp_error( $term ) ) {
printf(
'<link rel="canonical" href="%s" />' . "\n",
esc_url( get_term_link( $term ) )
);
}
}
}, 1 );Этот пример нужен только если вы понимаете, что делаете и у вас нет SEO-плагина, который уже выводит canonical. Иначе легко получить дублирующий тег в <head>.
4. Сократите количество тегов и пересечений
Часто проблема не в индексации как таковой, а в том, что на сайте слишком много мелких тегов. Если тегов десятки или сотни, а записей под ними мало, архивы превращаются в пустые страницы. В таком случае лучше:
- оставить только те теги, которые реально используются как навигация;
- объединить синонимы и близкие по смыслу теги;
- удалить теги без записей;
- не дублировать одну и ту же смысловую группу в рубрике и в тегах.
Если нужно быстро найти пустые теги, можно использовать WP-CLI или сделать выборку через админку. Но удалять их стоит только после проверки, что они не участвуют в меню, фильтрах и внутренних ссылках.
Как проверить, что решение сработало
После изменений не ограничивайтесь просмотром страницы в браузере. Проверьте несколько уровней:
- в исходном коде страницы должен быть корректный
canonical; - в
<meta name="robots">или в заголовках должен быть нужный режимnoindexдля закрытых архивов; - в sitemap не должно быть URL, которые вы исключили;
- в Search Console нужно отправить на переобход изменённые страницы и посмотреть, как они переиндексируются;
- через несколько дней проверьте, уменьшилось ли количество дублей в отчётах по индексированию.
Если страница всё ещё попадает в индекс, проверьте, не ведут ли на неё внутренние ссылки из меню, хлебных крошек или блока похожих записей. Поисковик может продолжать считать её важной, даже если вы поставили noindex.
Частые ошибки и как их исправить
Закрыли архив в robots.txt вместо noindex
Это распространённая ошибка. Если URL запрещён в robots.txt, поисковик может не увидеть на нём noindex и продолжит держать адрес в индексе как известный, но недоступный. Для удаления из поиска обычно нужен именно noindex, а не только запрет обхода.
Удалили тег, но не убрали ссылки на него
Если тег удалён, а в контенте или меню остались ссылки, вы получите 404 или цепочку редиректов. После чистки тегов проверьте внутренние ссылки и при необходимости настройте 301-редирект на ближайшую релевантную рубрику или на главную архивную страницу.
Поставили noindex на всё подряд
Иногда под фильтр попадают и полезные архивы, и главные рубрики. В результате сайт теряет нормальные посадочные страницы. Перед массовым закрытием проверьте, какие таксономии реально приносят трафик и какие нужны для навигации.
Сломали canonical кастомным кодом
Если в теме уже есть SEO-плагин, ручной вывод canonical почти всегда лишний. Два canonical в <head> — плохая идея. Оставьте один источник правды: либо плагин, либо собственный код.
Безопасность и производительность
Чистка дублей полезна не только для SEO. Меньше лишних архивов — меньше страниц, которые нужно обходить, рендерить и хранить в кеше. Но массово удалять таксономии и менять правила индексации лучше после бэкапа и на тестовой копии сайта.
Если вам нужен более управляемый набор SEO-настроек и очистка дублей без ручного кода, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, какие именно архивы вы закрываете и зачем.
Короткий чек-лист перед публикацией изменений
- Проверил, какие архивы реально нужны для индексации.
- Убрал лишние таксономии из sitemap или закрыл их noindex.
- Убедился, что canonical указывает на основную версию URL.
- Проверил внутренние ссылки на удалённые теги и архивы.
- Отправил страницы на переобход в Search Console.
- Сравнил индексируемые URL до и после правок.
Если после этого дубли всё ещё остаются, проблема обычно не в тегах как таковых, а в шаблоне темы, плагине SEO или в том, как сайт генерирует архивные страницы. Тогда уже имеет смысл смотреть конкретный URL и разбирать его по исходному коду и ответам сервера.