Как закрыть дубли страниц от индексации в WordPress без поломки SEO

В WordPress дубли чаще всего появляются не из-за «плохого SEO», а из-за штатной логики CMS: архивы, теги, страницы автора, пагинация, поиск, служебные URL и параметры в адресе. Если это не контролировать, поисковик начинает тратить краулинговый бюджет на мусорные страницы, а в индексе остаются не те URL, которые вы хотите продвигать.

Ниже — рабочая схема, как найти такие дубли, что закрывать через noindex, где лучше ставить canonical, а где вообще не трогать индексацию, чтобы не сломать внутреннюю перелинковку и поведенческие сигналы.

Какие дубли в WordPress встречаются чаще всего

Сначала полезно понять, что именно у вас дублируется. На практике проблема обычно не в одной странице, а в наборе однотипных URL:

• архивы рубрик и тегов, которые повторяют контент записей;
• страницы автора на небольших сайтах, где автор один и тот же;
• страницы поиска вида / ?s=...;
• пагинация архивов, если она индексируется без необходимости;
• URL с параметрами сортировки, фильтрации, UTM и прочими хвостами;
• страницы вложений медиафайлов, которые часто пустые или почти пустые;
• служебные страницы вроде результатов поиска по сайту, если они попали в индекс.

Если сайт настраивался давно, отдельно проверьте, не открыты ли для индексации архивы тегов с дублирующимся смыслом. На контентных проектах это одна из самых частых причин разрастания мусорных страниц.

Диагностика: где искать проблему

Начинать лучше не с правок, а с проверки фактического состояния. Иначе можно закрыть от индексации то, что уже приносит трафик.

Проверка в Google Search Console

Откройте отчёт по индексированию страниц и посмотрите, какие типы URL чаще всего попадают в статус «Просканировано, но не проиндексировано» или «Дубликат, Google выбрал другой канонический URL». Если там много архивов, тегов или параметров, это уже сигнал.

Дальше вручную проверьте несколько URL через инструмент проверки страницы. Важно смотреть не только на статус индексации, но и на выбранный canonical. Иногда WordPress отдаёт один canonical, а поисковик всё равно считает страницу дублем из-за структуры сайта.

Быстрая проверка на самом сайте

Откройте исходный код проблемной страницы и найдите:

• <meta name="robots";
• <link rel="canonical";
• наличие пагинации и параметров в URL;
• одинаковый ли заголовок и H1 у архивов и записей.

Если canonical отсутствует или указывает не туда, сначала исправляйте это. Закрытие страницы через noindex без canonical часто даёт слабый и нестабильный результат.

Что закрывать, а что лучше оставить

Не все дубли нужно одинаково обрабатывать. Для части страниц достаточно canonical, для части — noindex, follow, а некоторые URL лучше вообще не генерировать или отдавать 404/410, если они больше не нужны.

Тип URL	Что делать	Комментарий
Архивы тегов без ценности	noindex, follow	Если теговые страницы не несут самостоятельной пользы
Страницы поиска	noindex, follow	Поисковые результаты почти всегда мусор для индекса
Параметры сортировки/фильтра	canonical на чистый URL	Если параметры не меняют сущность страницы
Медиа-вложения	Редирект на файл или noindex	Зависит от темы и структуры медиа
Удалённые страницы	404 или 410	Если контент больше не должен существовать

Пошаговое решение через код

Если у вас нет SEO-плагина или нужно точечно обработать отдельные типы страниц, можно сделать это через wp_head. Ниже пример для закрытия архивов тегов, страниц поиска и вложений от индексации.

<?php
add_action( 'wp_head', function () {
    if ( is_tag() || is_search() || is_attachment() ) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1 );

Этот вариант рабочий, но его лучше использовать только если вы понимаете, что именно закрываете. Для больших сайтов удобнее делать настройку через SEO-плагин, чтобы не держать логику в теме.

Если нужно убрать из индекса только архивы тегов, но оставить рубрики, можно сузить условие:

<?php
add_action( 'wp_head', function () {
    if ( is_tag() ) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1 );

Canonical для страниц с параметрами

Если у вас есть фильтры или сортировка, которые не меняют смысл страницы, canonical должен указывать на чистую версию URL. В WordPress это часто проще делать на уровне шаблона или SEO-плагина, чем отдельным хаком. Но если параметр один и логика простая, можно отдать canonical вручную:

<?php
add_filter( 'get_canonical_url', function( $canonical, $post ) {
    if ( is_singular() ) {
        return get_permalink( $post );
    }

    return $canonical;
}, 10, 2 );

Здесь важно не переусердствовать: не переписывайте canonical для всех страниц подряд, если не понимаете, как это повлияет на архивы и пагинацию.

Если используете SEO-плагин

В большинстве случаев проще и безопаснее управлять индексацией через настройки плагина, а не через самописный код. Это особенно актуально, если редакторы сами создают теги, рубрики и архивы.

Проверьте, есть ли у вас отдельные настройки для:

• архивов тегов;
• архивов авторов;
• страниц поиска;
• медиа-вложений;
• пагинации архивов;
• canonical для параметров URL.

Если на сайте уже есть лишние дубли и служебные страницы, иногда удобнее сначала почистить структуру, а потом закрывать индексацию. В этом сценарии полезны инструменты вроде Clearfy Pro: они помогают убрать часть дублей и служебного шума без ручного переписывания шаблонов. Ссылка для ориентира: Clearfy Pro.

Чек-лист перед публикацией изменений

• Проверить, какие URL реально попадают в индекс и какие только сканируются.
• Сравнить canonical на записи, архиве и странице с параметрами.
• Убедиться, что закрываемые страницы не дают важный трафик.
• Проверить, не закрыты ли случайно рубрики или посадочные страницы.
• Очистить кэш сайта и CDN после правок.
• Повторно отправить на проверку несколько URL в Search Console.

Как проверить, что решение сработало

Проверка должна быть не «на глаз», а по нескольким признакам. Сразу после внедрения откройте проблемные URL и убедитесь, что:

• в исходном коде появился noindex,follow там, где он нужен;
• canonical указывает на правильную страницу;
• страница доступна для обхода, если вы не ставили жёсткий запрет в robots.txt;
• в Search Console статус URL меняется после повторного обхода;
• в отчёте по индексированию уменьшается число мусорных страниц.

Если страница закрыта через robots.txt, поисковик может не увидеть мета-тег noindex. Это частая ошибка: сначала запрещают обход, а потом удивляются, что URL остаётся в индексе как «известный, но не просканированный». Для удаления из индекса чаще нужен именно доступный для обхода URL с корректным robots-мета.

Частые ошибки и как их исправить

Закрыли не те страницы

Такое бывает, когда правило написано слишком широко, например для всех архивов сразу. В результате исчезают из индекса рубрики, которые реально приводили трафик. Исправление простое: сузить условие и проверить конкретные шаблоны страниц.

Поставили noindex, но оставили мусорный canonical

Если canonical указывает на саму дубль-страницу или на нерелевантный URL, поисковик может продолжать путаться. Canonical должен вести на основную версию страницы, а не на соседний архив «для галочки».

Заблокировали URL в robots.txt раньше, чем закрыли мета-тегом

Это мешает поисковику увидеть инструкцию на странице. Если цель — убрать URL из индекса, сначала дайте ему просканировать страницу с noindex, а уже потом при необходимости ограничивайте обход.

Не очистили кэш

После изменения шаблона или фильтра кэш может ещё долго отдавать старую версию head-секции. Если используете page cache, object cache или CDN, сбросьте их все, иначе проверка даст ложный результат.

Безопасность и производительность

Чем меньше лишних архивов и служебных страниц генерируется, тем проще сайт обходится ботами и тем меньше риск технического мусора в индексе. Но не стоит превращать SEO-настройки в набор случайных запретов.

Практически полезные правила:

• не закрывайте в индексации страницы, которые нужны для навигации и внутренней перелинковки без проверки;
• не меняйте canonical массово через хук, если не тестировали несколько типов контента;
• не используйте robots.txt как замену noindex для уже проиндексированных URL;
• после правок проверяйте не только главную, но и архивы, пагинацию и страницы с параметрами.

Если сайт большой, лучше сначала составить список типов URL, которые реально должны индексироваться, и уже от него отталкиваться. Это проще, чем потом вылавливать последствия случайного noindex на десятках шаблонов.

В итоге рабочая схема всегда одна и та же: сначала диагностика, потом точечное закрытие дублей, затем проверка в Search Console и по исходному коду. Если делать в обратном порядке, почти всегда появляется новый слой проблем вместо решения старой.