Как закрыть дубли страниц пагинации в WordPress через robots.txt, canonical и noindex

Проблема с дублями пагинации в WordPress обычно всплывает не в теории, а в Search Console: в индексе оказываются страницы архивов с параметрами, страницы категорий с /page/2/, иногда еще и версии с сортировкой или UTM. В итоге поисковик тратит обход на мусорные URL, а каноническая страница теряет часть сигнала. Самая частая ошибка — пытаться решить все одним Disallow в robots.txt. Это не закрывает уже известные URL от индексации и часто мешает поисковику увидеть каноникал.

Как понять, что у вас именно проблема дублей пагинации

Сначала проверьте, какие URL реально попали в индекс. В Search Console откройте отчет по страницам и посмотрите, есть ли там варианты вроде /page/2/, /page/3/, URL с параметрами ?orderby=, ?sort=, ?amp или внутренние поисковые страницы. Если сайт на большом каталоге или блоге, дубли часто появляются не только в категориях, но и в тегах, архивах автора и дат.

Что считать нормой, а что — проблемой

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

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

Сначала диагностика: где именно рождаются дубли

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

Посмотрите исходный код страницы архива и найдите:

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

Если canonical на странице /category/news/page/2/ указывает на /category/news/, это не всегда ошибка. Для архивов это зависит от вашей стратегии: иногда так и нужно, иногда пагинацию лучше оставить самоканоничной, чтобы поисковик понимал структуру списка. Но если в индексе появляются параметры, которые не несут отдельной ценности, их нужно закрывать точечно.

Рабочая схема: что закрывать, а что оставить

Не стоит закрывать все подряд. Для WordPress лучше разделить URL на три группы:

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

Если нужен предсказуемый результат, лучше не полагаться только на настройки плагина. Ниже рабочий вариант для темы или небольшого mu-plugin. Он ставит noindex, follow на страницы с параметрами и на внутренний поиск, но не трогает обычные архивы и пагинацию без параметров.

<?php
add_filter('wp_robots', function( $robots ) {
    if ( is_search() ) {
        $robots['noindex'] = true;
        $robots['follow']   = true;
        return $robots;
    }

    if ( ! empty($_GET) ) {
        $allowed = array('paged');
        $keys = array_keys($_GET);
        $has_unwanted_params = count(array_diff($keys, $allowed)) > 0;

        if ( $has_unwanted_params ) {
            $robots['noindex'] = true;
            $robots['follow']   = true;
        }
    }

    return $robots;
});

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

Как точечно поправить canonical

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

<?php
add_action('wp_head', function() {
    if ( is_search() || ! empty($_GET) ) {
        $url = home_url( add_query_arg( array(), $GLOBALS['wp']->request ) );
        $url = remove_query_arg( array_keys($_GET), $url );
        echo '<link rel="canonical" href="' . esc_url( trailingslashit( $url ) ) . '" />' . "\n";
    }
}, 1);

С этим кодом нужно быть аккуратнее: если тема или SEO-плагин уже выводит canonical, вы получите дубли в <head>. Перед внедрением проверьте исходник страницы и убедитесь, что второй canonical не появляется.

Когда robots.txt помогает, а когда нет

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

Поэтому практический порядок такой:

1. сначала ставите корректный canonical и noindex там, где это уместно;
2. потом ограничиваете обход только для явного мусора;
3. после этого проверяете sitemap и внутренние ссылки;
4. и только затем при необходимости правите robots.txt.

Проверка результата после внедрения

После правок не ограничивайтесь визуальной проверкой. Откройте несколько URL вручную и проверьте исходный код:

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

Если используете серверный кеш, очистите его после изменений. Иначе вы будете проверять старый HTML и решите, что код не сработал.

Что смотреть в Search Console

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

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

Самая типичная ошибка — закрыть /page/2/ в robots.txt вместе с параметрами. В результате поисковик перестает нормально обходить архив, а внутренние ссылки на следующую страницу теряют смысл. Если пагинация нужна пользователю, не блокируйте ее без необходимости.

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

Третья ошибка — оставлять в sitemap URL с параметрами. Даже если canonical правильный, sitemap будет подсказывать поисковику лишние адреса. Проверьте генератор карты сайта в SEO-плагине и исключите технические страницы.

Четвертая ошибка — забыть про дубли в теме. Иногда шаблон выводит одинаковый title для первой и второй страницы архива. Для этого лучше добавить номер страницы в title через фильтр document_title_parts или через настройки SEO-плагина, если он это умеет.

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

Не ставьте тяжелые проверки на каждый запрос, если сайт с высокой посещаемостью. Код должен быть коротким и предсказуемым. Если вы добавляете логику в тему, лучше вынести ее в mu-plugin, чтобы она не исчезла при смене шаблона. И не редактируйте ядро WordPress или плагины напрямую: после обновления правки пропадут.

Если у вас большой сайт, сначала протестируйте изменения на staging-копии. Особенно это важно, когда в проекте есть несколько SEO-плагинов, кеш на уровне сервера и отдельные правила в nginx или Apache. Конфликт между ними встречается чаще, чем ошибка в самом коде.

Когда лучше решить задачу плагином, а когда кодом

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

Главное здесь не пытаться «запретить все лишнее» одним правилом. В WordPress техническая индексация почти всегда зависит от конкретной структуры сайта, и правильное решение — то, которое можно проверить на реальных URL, а не только в настройках.