На WordPress дубли чаще всего появляются не из-за “плохого SEO”, а из-за штатной логики: архивы рубрик, тегов, авторов, дат, пагинация, страницы вложений и служебные URL могут индексироваться одновременно. В итоге поисковик видит несколько почти одинаковых страниц и начинает выбирать не ту, которую вы хотите продвигать.
Задача здесь не в том, чтобы закрыть всё подряд, а в том, чтобы оставить полезные страницы доступными для обхода и убрать из индекса то, что не несёт самостоятельной ценности. Ниже — рабочий сценарий: как диагностировать дубли, какие варианты решения реально применяют на WordPress и как проверить, что после правок сайт не потерял важные страницы.
Какие дубли чаще всего появляются в WordPress
Если сайт на стандартной теме или на теме с активными архивами, обычно всплывают одни и те же типы дублей:
- архивы тегов, которые повторяют рубрики или отдельные записи;
- архивы автора на небольших сайтах, где у автора одна-две публикации;
- архивы по датам, если они не используются как отдельный контентный раздел;
- страницы пагинации архивов с очень похожими заголовками и описаниями;
- страницы вложений медиафайлов, которые дублируют саму картинку без полезного контента;
- страницы поиска по сайту, если они доступны для индексации;
- служебные архивы таксономий, которые не дают трафик и не имеют уникального текста.
Не все эти страницы нужно закрывать. Например, если у вас сильная рубрика с собственным текстом, хлебными крошками и нормальной перелинковкой, она может быть полезной посадочной. Но если архив существует только технически и повторяет список постов, это кандидат на исключение из индекса.
Диагностика: как понять, что проблема именно в дублях архивов
Начинать лучше не с правок, а с проверки того, что уже попало в индекс и как это выглядит для поисковика. Самый простой путь — посмотреть отчёты в Google Search Console и сопоставить их с реальными URL на сайте.
Что проверить вручную
- в поиске по сайту запрос
site:example.comи типичные URL архивов; - наличие в индексе страниц вида
/tag/,/author/,/date/,/page/2/; - одинаковые title и description у разных архивных страниц;
- страницы вложений, которые открываются отдельно и не содержат полезного текста;
- наличие канонических URL на архивных страницах.
Если вы используете SEO-плагин, проверьте, не включены ли у архивов мета-теги index по умолчанию. Иногда проблема не в теме, а в том, что архивы просто не настроены.
Быстрая проверка через код
Для технической диагностики удобно временно вывести заголовок и canonical на нужных типах страниц. Это помогает понять, что именно видит браузер и поисковый робот.
<?php
add_action('wp_head', function () {
if (is_tag() || is_author() || is_date() || is_search()) {
echo "<!-- archive type: " . esc_html(get_query_var('taxonomy') ?: 'archive') . " -->\n";
}
}, 1);
Это не решение, а способ быстро убедиться, что вы работаете с нужным типом страниц. После проверки такой код лучше убрать.
Какой подход выбрать: плагин, настройки темы или код
В реальной работе обычно есть три варианта. Выбор зависит от того, насколько тонко нужно управлять индексированием и есть ли у вас доступ к шаблонам.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Нужно быстро закрыть архивы и задать noindex без кода | Понятный интерфейс, меньше риска сломать шаблон | Не всегда удобно для точечной логики |
| Код в теме или mu-plugin | Нужны точные правила для конкретного сайта | Гибкость, контроль над canonical и robots | Нужна аккуратность и тестирование |
| Настройки темы | Тема уже умеет управлять архивами | Быстро и без доработок | Обычно слишком грубо, мало контроля |
Если задача типовая, чаще достаточно SEO-плагина. Если же у вас сложная структура рубрик, авторов и таксономий, лучше вынести логику в код, чтобы не зависеть от интерфейса плагина.
Пошаговое решение: закрываем служебные архивы и оставляем полезные
Шаг 1. Определите, какие архивы должны остаться в индексе
Сначала составьте короткий список:
- какие рубрики реально приводят трафик;
- нужны ли страницы автора как отдельные посадочные;
- используются ли архивы по датам как навигация;
- есть ли смысл индексировать теги;
- нужны ли страницы вложений отдельно от медиафайлов.
Если ответ “нет” или “не уверен”, архив лучше закрывать или переводить в noindex. Но не удаляйте URL физически, если на них уже есть ссылки и они могут отдавать 404 без необходимости.
Шаг 2. Настройте noindex для архивов, которые не нужны в поиске
Если вы работаете через код, можно добавить правила в functions.php дочерней темы или в отдельный mu-plugin. Ниже пример для типового сайта: закрываем теги, авторов, даты и поиск, но оставляем рубрики.
<?php
add_action('wp_head', function () {
if (is_tag() || is_author() || is_date() || is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
Это базовый вариант. На практике лучше использовать SEO-плагин, если он уже управляет robots meta, чтобы не получить конфликт двух разных тегов robots на одной странице.
Шаг 3. Уберите страницы вложений из индекса
Страницы attachment часто создают чистый дубль медиафайла или почти пустую страницу. Если они не нужны как отдельный контент, безопаснее перенаправлять их на сам файл или на родительскую запись.
<?php
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = wp_get_post_parent_id(get_the_ID());
if ($parent) {
wp_safe_redirect(get_permalink($parent), 301);
exit;
}
$file = wp_get_attachment_url(get_the_ID());
if ($file) {
wp_safe_redirect($file, 301);
exit;
}
}
});
Такой подход уменьшает число бесполезных URL и убирает отдельный слой дублей, который часто забывают проверить.
Шаг 4. Проверьте пагинацию архивов
Пагинация сама по себе не ошибка. Проблема возникает, когда страницы /page/2/, /page/3/ и дальше выглядят как почти одинаковые копии первой страницы архива. Если у вас слабый архив без уникального текста, такие страницы часто не нужны в индексе.
Здесь важно не делать грубую ошибку: не закрывайте пагинацию через disallow в robots.txt без понимания последствий. Поисковик может перестать нормально обходить список записей, а это уже влияет на обнаружение новых материалов. Если нужно убрать именно из индекса, используйте noindex там, где это поддерживается вашим SEO-стеком, или настройте каноникал корректно.
Проверка результата после внедрения
После правок не ограничивайтесь визуальным просмотром страницы. Нужно проверить, что поисковик видит именно то, что вы задумали.
- откройте архив и убедитесь, что в исходном коде есть один корректный
meta robots; - проверьте canonical: он должен указывать на саму страницу или на целевую каноническую версию;
- посмотрите, не появились ли редиректы на лишних типах страниц;
- пройдитесь по нескольким URL с пагинацией и убедитесь, что они не ломают навигацию;
- в Search Console отправьте проверку URL и посмотрите, как страница определяется после переобхода;
- через несколько дней проверьте, не выросло ли число страниц с дублирующимся title.
Если вы закрывали архивы через код, полезно открыть исходный HTML и убедиться, что тег noindex,follow не конфликтует с настройками SEO-плагина. Два разных robots-тега на одной странице — частая причина непредсказуемого поведения.
Частые ошибки и как их исправить
Закрыли не те страницы
Самая частая ошибка — закрыть все архивы подряд, включая рубрики, которые реально дают трафик. Исправление простое: сначала оцените каждую таксономию отдельно. Если рубрика имеет уникальный текст, хлебные крошки и внутренние ссылки, она может остаться в индексе.
Поставили noindex, но оставили конфликтующий canonical
Если canonical указывает на другую страницу, а robots говорит noindex, поисковик может интерпретировать страницу не так, как вы ожидаете. Проверьте, что канонический адрес логичен и не ведёт на нерелевантную запись.
Закрыли архивы в robots.txt
Это не лучший способ для большинства SEO-задач. robots.txt ограничивает обход, но не решает вопрос индексации уже известных URL. Для дублей архивов обычно нужен именно noindex или редирект, а не просто запрет обхода.
Удалили страницы вложений без редиректа
Если у медиа-страниц уже есть внешние ссылки, массовое удаление без 301 приведёт к 404. Лучше сначала настроить редирект на родительскую запись или сам файл, а уже потом чистить старые URL.
Сломали пагинацию
Иногда после правок архивы перестают листаться или ссылки ведут на 404. Обычно причина в фильтре темы, который вмешался в paginate_links(), или в неправильной настройке пермалинков. Проверяйте не только первую страницу архива, но и вторую, третью и последнюю.
Практические советы по безопасности и производительности
Если вы вносите изменения кодом, не редактируйте напрямую основной файл темы. Лучше использовать дочернюю тему или отдельный mu-plugin. Так правки не потеряются после обновления.
Для сайтов с большим количеством архивов полезно:
- не генерировать лишние архивы, если они не нужны контентно;
- убрать страницы вложений из индекса и из внутренней навигации;
- не плодить теги ради “SEO-охвата”, если они не имеют самостоятельной ценности;
- проверить, не создаёт ли плагин фильтрации или сортировки новые индексируемые URL;
- следить за количеством дублей после обновления темы или SEO-плагина.
Если нужен более широкий контроль над дублями, технической чисткой и SEO-настройками, на практике часто используют Clearfy Pro: он закрывает часть типовых проблем без ручного вмешательства в шаблоны. Но даже с плагином всё равно стоит понимать, какие URL вы оставляете в индексе, а какие нет: автоматическая настройка не заменяет диагностику структуры сайта.
Что проверить сразу после обновления темы или плагина
После любого обновления темы, SEO-плагина или плагина для кэша повторите короткий контрольный список. Это особенно важно, если архивы и canonical формируются не ядром WordPress, а шаблонами темы.
- robots meta на архивных страницах;
- canonical на рубриках, тегах и авторах;
- редиректы на attachment pages;
- заголовки H1 на архивных шаблонах;
- отсутствие новых дублей в sitemap;
- корректная работа пагинации;
- отсутствие 404 на старых URL после перенастройки.
Если после правок в индексе всё ещё остаются лишние архивы, не спешите добавлять новые запреты. Сначала проверьте, не генерирует ли их плагин, тема или старая карта сайта. В WordPress дубли часто появляются не в одном месте, а сразу в нескольких слоях.