В WordPress дубли чаще всего появляются не из-за «плохого SEO», а из-за стандартной логики CMS: архивы категорий и тегов, страницы автора, пагинация, вложения, результаты поиска, параметры сортировки и UTM-метки. Если это не контролировать, поисковик тратит обход на мусорные URL, а в индексе начинают жить страницы, которые вы не планировали продвигать.
Ниже — рабочая схема: сначала находим, какие дубли реально есть, потом выбираем способ закрытия, а после внедрения проверяем, что ничего важного не выпало из индекса.
Какие дубли в WordPress встречаются чаще всего
Проблема обычно не одна. На одном сайте одновременно могут индексироваться:
- архивы тегов, которые дублируют материалы из рубрик;
- страницы автора на блоге с одним редактором;
- страницы пагинации вида
/page/2/; - вложения медиафайлов, если они открыты как отдельные страницы;
- внутренний поиск
?s=; - URL с параметрами
?utm_,?replytocom=,?ampи похожими; - архивы дат, если они не нужны для навигации.
Не все из этого надо закрывать одинаково. Одни страницы лучше убрать из индекса через noindex, другие — вовсе отключить, а третьи оставить, но настроить канонический URL.
Диагностика: что именно уже попало в индекс
Начните не с настроек, а с проверки факта. Иначе легко закрыть полезные страницы или оставить открытыми те, что уже размножились.
Проверка через поисковую выдачу и Search Console
В Google Search Console откройте отчёт по индексированию страниц и посмотрите группы с причинами вроде «Просканировано, но не проиндексировано», «Дубликат, выбранный пользователем canonical», «Исключено тегом noindex». Это даст список типов URL, а не догадки.
Дальше проверьте вручную несколько шаблонов URL:
site:example.com inurl:tag;site:example.com inurl:author;site:example.com inurl:page/2;site:example.com inurl:?s=;site:example.com inurl:?replytocom=.
Если в выдаче есть то, что не должно индексироваться, значит проблема не теоретическая, а уже рабочая.
Быстрая проверка на сайте
Если у вас есть доступ к серверу или консоли, можно быстро собрать список URL с параметрами из логов или карты сайта. Но для большинства проектов достаточно двух источников: Search Console и обхода сайта краулером вроде Screaming Frog. Важно не количество найденных URL, а повторяемость шаблона.
Что закрывать, а что оставлять
Здесь часто ошибаются: пытаются поставить noindex на всё подряд. Это не всегда правильно. Для части страниц лучше оставить индексирование, но убрать их из карты сайта и поставить каноникал на основную страницу.
| Сценарий | Что делать | Компромисс |
|---|---|---|
| Теги дублируют рубрики | noindex, follow или отключение архивов тегов | Теги перестают собирать трафик, но снижается мусор |
| Автор один и тот же | Закрыть архив автора или настроить редирект | Потеря отдельной страницы автора, если она не нужна |
| Пагинация рубрик | Оставить открытой, но с корректным canonical | Не ломать навигацию по архивам |
| Вложения изображений | Редирект на файл или на родительскую запись | Убирается лишняя индексируемая страница |
| Поиск и параметры | Закрыть от индексации и не включать в sitemap | Не участвуют в поиске, что обычно и нужно |
Пошаговое решение через код и настройки
Если нужен контроль без лишних плагинов, часть задач можно закрыть кодом в теме или мини-плагине. Для рабочих проектов я бы делал именно так: меньше магии, проще отлаживать.
1. Закрыть архивы автора, если автор один
Когда на сайте один автор, архив автора почти всегда дублирует главную ленту или рубрики. Проще всего отключить его через noindex и убрать из sitemap, если он генерируется отдельно.
add_action('wp_head', function () {
if (is_author()) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});Если используете SEO-плагин, лучше не дублировать мета-тег вручную, а настроить это в плагине или через его фильтры. Иначе получите два одинаковых robots-тега и лишнюю путаницу при отладке.
2. Убрать страницы вложений с отдельного URL
Страницы attachment почти никогда не нужны как самостоятельные посадочные. Обычно их лучше редиректить на родительскую запись, а если родителя нет — на сам файл или на главную медиабиблиотеки, в зависимости от логики сайта.
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = wp_get_post_parent_id(get_the_ID());
if ($parent) {
wp_redirect(get_permalink($parent), 301);
exit;
}
wp_redirect(home_url('/'), 301);
exit;
}
});Этот вариант простой, но рабочий. Если у вас уже есть SEO-плагин, проверьте, не делает ли он такой редирект сам, чтобы не получить цикл или двойную обработку.
3. Закрыть внутренний поиск и параметры
Страницы поиска и URL с параметрами лучше не индексировать. Для поиска можно добавить noindex, а для параметров — следить, чтобы они не попадали в sitemap и не создавали отдельные канонические URL.
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});Для параметров вроде ?replytocom= обычно достаточно серверного редиректа или настройки плагина кэширования/SEO. Если параметр технический и не нужен пользователю, лучше убрать его на уровне генерации ссылок, а не лечить последствия.
4. Настроить архивы тегов и дат
Если теги на сайте используются формально и не дают самостоятельного трафика, их можно закрыть от индексации. Архивы дат на большинстве контентных сайтов тоже редко нужны в поиске.
Вариант через SEO-плагин удобнее, но если вы работаете без него, логика та же: noindex для архивов, которые не несут отдельной ценности, и нормальные canonical для тех, что оставляете открытыми.
Если используете плагин: где удобнее делать это без кода
На небольших сайтах проще управлять дублями через SEO-плагин или через набор функций в одном месте. Если нужен именно технический «комбайн» для чистки дублей, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Его обычно берут не ради одной галочки, а чтобы централизованно отключать лишние архивы, служебные страницы и часть мусорной разметки.
Но плагин не отменяет диагностику. Если не понять, какие URL реально индексируются, можно закрыть не тот шаблон и потерять полезные страницы.
Проверка результата после внедрения
После изменений не ограничивайтесь просмотром исходника страницы. Нужно убедиться, что поисковик видит именно то, что вы задумали.
- Откройте несколько проблемных URL в браузере и проверьте
meta robotsиcanonical. - Проверьте HTTP-ответ для редиректов через
curl -I https://example.com/attachment-page/. - В Search Console отправьте на повторную проверку ключевые страницы.
- Сравните количество исключённых URL в отчёте индексирования через 1–2 обхода, а не на следующий день.
- Проверьте sitemap: там не должно быть страниц, которые вы закрыли от индексации.
Если страница закрыта через noindex, но продолжает попадать в sitemap, это плохой сигнал. Поисковик получает противоречивые указания и дольше переобходит сайт.
Частые ошибки и как их исправить
Ставят noindex на всё подряд
Так часто делают после первой паники из-за дублей. В итоге закрывают и полезные архивы, которые собирали переходы. Исправление простое: сначала отделите служебные страницы от контентных, потом закрывайте только то, что не несёт самостоятельной ценности.
Оставляют страницы в sitemap после noindex
Это частая техническая ошибка. Карта сайта должна отражать только те URL, которые вы хотите видеть в индексе. Если страница закрыта, уберите её из sitemap на уровне SEO-плагина или генератора карты.
Делают редирект без проверки каноникала
Если attachment или дубль уже имеет canonical на себя или на другой URL, а вы сверху добавляете редирект, можно получить нестабильное поведение при обходе. Сначала проверьте, как страница отдаётся сейчас, потом меняйте только один слой логики.
Закрывают пагинацию рубрик
Пагинация сама по себе не всегда дубль. Если у вас длинные архивы, страницы /page/2/ и дальше нужны для обхода контента и внутренней перелинковки. Закрывать их без анализа не стоит.
Практические советы по безопасности и производительности
Чем меньше служебных URL индексируется, тем проще и поисковику, и серверу. Но есть и техническая сторона:
- не плодите отдельные шаблоны для дублей в теме, если это можно решить фильтром или настройкой;
- не вешайте тяжелую логику на
wp_headбез необходимости; - не создавайте цепочки редиректов для вложений и параметров;
- проверяйте, не ломает ли кэширование страницы с разными query string;
- если используете CDN или page cache, убедитесь, что служебные URL не отдаются из кэша как обычные страницы.
На практике самая частая проблема — не сам дубль, а конфликт между темой, SEO-плагином и кэшем. Поэтому после каждого изменения смотрите не только HTML, но и заголовки ответа, canonical и карту сайта.
Если нужна более тонкая работа с дублями, чисткой служебных страниц и SEO-настройками на одном сайте, имеет смысл держать это в одном инструменте или одном мини-плагине, а не размазывать по functions.php и трем разным плагинам. Тогда отладка занимает минуты, а не вечер.