Дубли в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелочей: архивы тегов, страницы пагинации, параметры в URL, версии для печати, результаты поиска по сайту, UTM-метки, технические страницы плагинов. Если их не контролировать, поисковик начинает тратить обход на мусорные URL и иногда выбирает не ту страницу как основную.
Ниже разберём рабочую схему: как найти дубли, чем закрывать их в WordPress, где достаточно canonical, а где нужен noindex, и как проверить, что после правок поисковый робот видит именно то, что нужно.
Как понять, что у вас действительно проблема с дублями
Не каждый похожий URL — это проблема. Сначала нужно отделить нормальные архивы от технических дублей. Типичный сигнал — в Google Search Console растёт число страниц со статусами вроде «Просканировано, но не проиндексировано» или «Дублированная страница, выбранная каноническая страница отличается от пользовательской». Ещё один признак — в индексе оказываются URL с параметрами, которые не должны ранжироваться.
Что проверить в первую очередь
- страницы с параметрами
?replytocom=,?utm_,?sort=и похожими; - архивы тегов и авторов, если они не несут самостоятельной ценности;
- страницы пагинации архивов;
- страницы внутреннего поиска вида
/search/или?s=; - дубли главной страницы с разными вариантами слэша, протокола или www;
- версии страниц, которые создаёт тема или плагин для предпросмотра, печати, фильтров.
Если вы не уверены, откройте исходный код страницы и найдите тег rel="canonical". Он должен указывать на единственный основной URL. Если canonical отсутствует или ведёт не туда, поисковик может выбрать свой вариант.
Что закрывать через canonical, а что через noindex
Canonical и noindex решают разные задачи. Canonical говорит поисковику: «вот основная версия страницы, остальные похожи». Noindex говорит: «эту страницу не показывай в поиске». Подменять одно другим нельзя.
| Сценарий | Что использовать | Комментарий |
|---|---|---|
| Параметры сортировки, UTM, фильтры | canonical | Если контент тот же, но URL отличается |
| Внутренний поиск, служебные страницы | noindex | Такие страницы обычно не нужны в индексе |
| Архивы тегов без ценности | noindex | Часто лучше закрыть, чем плодить тонкие страницы |
| Пагинация полезного архива | обычно canonical на саму страницу | Не стоит массово указывать все страницы на первую |
Если у вас SEO-плагин уже генерирует canonical и robots meta, не дублируйте это кодом без проверки. Две разные инструкции в одном документе часто дают обратный эффект.
Пошаговое решение без лишней магии
1. Настройте базовый canonical для шаблонов темы
Если тема или плагин не выводят canonical корректно, можно добавить его вручную. Делать это лучше только после проверки, что в <head> нет второго canonical.
<?php
add_action( 'wp_head', function () {
if ( is_singular() ) {
echo '<link rel="canonical" href="' . esc_url( get_permalink() ) . '" />' . "\n";
}
}, 1 );Этот пример подходит только как страховка для одиночных записей и страниц. Для архивов и специальных шаблонов canonical нужно рассчитывать отдельно, иначе можно случайно отправить все страницы архива на одну и ту же URL.
2. Закройте внутренний поиск и служебные страницы от индексации
Страницы поиска по сайту почти никогда не должны попадать в индекс. Для них логичнее ставить noindex,follow, чтобы робот не индексировал страницу, но мог пройти по ссылкам.
<?php
add_action( 'wp_head', function () {
if ( is_search() || is_404() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1 );Если у вас уже стоит SEO-плагин, проверьте, не добавляет ли он такой же тег сам. Дублировать meta robots не нужно.
3. Уберите из индекса архивы, которые не дают трафик
На небольших сайтах архивы тегов, авторов и дат часто создают больше шума, чем пользы. Их можно закрыть через SEO-плагин или кодом. Если нужен быстрый и управляемый вариант, удобнее делать это в настройках плагина, а не в теме.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_tag() || is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Такой подход работает на уровне стандартного API WordPress и не требует выдуманных хуков. Но если плагин SEO уже управляет robots meta, сначала отключите конфликтующую настройку там.
4. Настройте robots.txt только для обхода, а не для индексации
robots.txt не заменяет noindex. Он ограничивает обход, но не гарантирует удаление URL из индекса, если на него уже есть ссылки. Поэтому закрывать через robots.txt нужно только то, что действительно не должно сканироваться, например служебные каталоги или некоторые параметры, если они создают нагрузку.
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Sitemap: https://example.com/sitemap_index.xmlНе пытайтесь через robots.txt «спрятать» страницы, которые уже попали в поиск. Для этого нужен noindex или корректный canonical, а иногда и удаление страницы с сайта.
Как проверить результат после внедрения
После правок не ограничивайтесь просмотром кода страницы. Нужна проверка на трёх уровнях: HTML, ответ сервера и индекс.
- Откройте страницу в браузере и проверьте, что canonical один и ведёт на нужный URL.
- Посмотрите исходный код и убедитесь, что нет двух тегов
meta name="robots"с разными значениями. - Проверьте заголовки ответа, если используете серверные правила или кэш.
- В Search Console отправьте URL на повторную проверку через инструмент проверки страницы.
- Сравните отчёт по индексированию через несколько дней, а не сразу после изменения.
Если вы закрыли страницу через noindex, она не исчезнет из поиска мгновенно. Роботу нужно заново обойти URL и увидеть обновлённые инструкции. Это нормальный процесс, а не ошибка.
Частые ошибки и как их исправить
Canonical указывает на главную страницу для всех архивов
Это частая ошибка при ручной настройке шаблонов. В результате поисковик теряет различие между страницами архива и может игнорировать полезные URL. Исправление простое: canonical должен вести на саму страницу архива, а не на первую запись или главную.
Noindex ставят вместе с запретом в robots.txt
Если робот не может зайти на страницу из-за robots.txt, он не увидит noindex в HTML. Тогда URL может оставаться в индексе дольше, чем ожидается. Сначала дайте роботу возможность увидеть noindex, а уже потом при необходимости ограничивайте обход.
Дублируют правила SEO-плагина своим кодом
Если плагин уже выводит canonical и robots meta, дополнительный код может создать конфликт. Симптомы простые: в исходнике два canonical, разные значения robots или странное поведение в Search Console. В такой ситуации оставьте один источник правды.
Закрывают полезные страницы тегов без анализа
Не все архивы тегов бесполезны. Если теговые страницы дают трафик и содержат действительно полезную подборку материалов, их можно оставить в индексе, но привести к нормальному виду: уникальный заголовок, описание, чистая структура, без пустых страниц.
Когда лучше использовать плагин, а когда код
Если задача сводится к массовому управлению мета-тегами, удобнее использовать SEO-плагин. Если нужно точечно закрыть конкретный тип страниц или исправить поведение темы, код даёт больше контроля. На практике часто работает смешанная схема: плагин отвечает за базовые правила, код — за исключения.
Для сайтов, где нужно ещё и чистить дубли, служебные архивы и лишние элементы разметки, иногда проще собрать это в одном инструменте вроде Clearfy Pro, чем держать набор разрозненных правок. Но и в этом случае стоит проверять итоговый HTML, а не полагаться на название настройки.
Чек-лист перед публикацией изменений
- Проверен один canonical на странице.
- Для закрываемых страниц задано
noindex,follow. - robots.txt не блокирует страницу раньше, чем робот увидит noindex.
- Нет дублей meta robots и canonical от разных источников.
- В Search Console отправлены на проверку основные URL.
- Проверены архивы тегов, авторов, дат и внутренний поиск.
Если после правок в индексе всё ещё остаются старые URL, это не всегда означает, что настройка не сработала. Иногда поисковику нужно время на переобход. Но если в исходнике страницы по-прежнему видны неверные canonical или robots meta, значит проблема в шаблоне или в конфликте плагинов, и это уже нужно исправлять на уровне кода или настроек.