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

Дубли страниц пагинации в WordPress обычно всплывают не сразу: сайт уже проиндексирован, а в поиске начинают жить отдельной жизнью страницы вида /page/2/, /page/3/, архивы рубрик с одинаковыми заголовками или страницы с параметрами сортировки. Проблема не в самой пагинации, а в том, что поисковик видит несколько очень похожих URL и тратит обход на мусорные варианты вместо важных страниц.

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

Когда пагинация становится SEO-проблемой

Пагинация сама по себе нормальна. Проблема начинается, если:

• страницы рубрик и архивов имеют одинаковые title и description на всех страницах пагинации;
• в индексе появляются URL с параметрами ?sort=, ?filter=, ?orderby= или похожими;
• внутренние ссылки ведут на несколько версий одной и той же выдачи;
• страницы /page/2/ и дальше не несут самостоятельной ценности, но индексируются как отдельные посадочные;
• в sitemap попадают URL, которые не нужны для поиска.

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

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

Сначала не трогайте код. Посмотрите, какие URL уже попали в индекс и как они выглядят в обходе. Это экономит время: часто проблема не в WordPress как таковом, а в теме, плагине фильтров или шаблоне архива.

Что проверить в первую очередь

• Google Search Console: отчёт по страницам и исключённым URL;
• исходный код страниц пагинации: одинаковые ли <title>, meta description, canonical;
• robots.txt: нет ли там случайного запрета на важные архивы;
• XML sitemap: не попадают ли туда страницы с параметрами и служебные URL;
• шаблон архива в теме: не выводит ли он один и тот же H1 на всех страницах пагинации.

Если используете краулер вроде Screaming Frog, удобно сравнить title и canonical на страницах /page/2/, /page/3/. Когда canonical указывает на саму страницу пагинации, это не ошибка. Ошибка — когда все страницы серии канонизируются на первую страницу без понимания последствий.

Мини-чек-лист диагностики

• Есть ли в индексе URL с параметрами сортировки и фильтров?
• Одинаковы ли title у страниц пагинации?
• Не дублируется ли H1 на всех страницах архива?
• Не закрыт ли случайно весь архив в robots.txt?
• Не ломает ли плагин SEO canonical на страницах /page/2/ и дальше?

Что делать: три рабочих подхода

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

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

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

1. Уникализировать title для страниц пагинации

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

<?php
add_filter('document_title_parts', function ($parts) {
    if (is_paged()) {
        $paged = max(2, (int) get_query_var('paged'));
        $parts['title'] = $parts['title'] . ' — страница ' . $paged;
    }
    return $parts;
});

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

2. Настроить canonical для архивов

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

<?php
add_filter('wpseo_canonical', function ($canonical) {
    if (is_paged()) {
        return get_pagenum_link(max(2, (int) get_query_var('paged')));
    }
    return $canonical;
});

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

3. Закрыть параметры сортировки и фильтров от индексации

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

<?php
add_action('wp_head', function () {
    if (!empty($_GET['sort']) || !empty($_GET['orderby']) || !empty($_GET['filter'])) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1);

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

Если дубли создаёт плагин фильтров или сортировки

Частая ситуация: WordPress тут ни при чём, а дубли генерирует плагин фильтров, AJAX-сортировки или тема с собственным каталогом. Тогда нужно смотреть, как именно формируются URL.

Проверьте:

• создаёт ли плагин отдельные URL для каждого фильтра;
• меняется ли canonical при выборе фильтра;
• не попадают ли фильтрованные страницы в sitemap;
• не индексируются ли страницы с пустой выдачей.

Если плагин не даёт управлять canonical и robots, иногда проще отключить индексацию фильтрованных URL на уровне шаблона и оставить только базовые архивы. Это не идеал, но в реальном проекте часто лучше, чем индексировать сотни почти одинаковых страниц.

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

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

Что проверить вручную

• откройте несколько страниц пагинации и посмотрите исходный код;
• сравните title, canonical и robots meta;
• проверьте, что страницы с параметрами получили noindex,follow, если это было задумано;
• убедитесь, что базовые архивы и записи доступны без ошибок 404;
• посмотрите, не исчезли ли важные страницы из sitemap.

Что проверить в Search Console

После переобхода страниц не ждите мгновенного эффекта. Смотрите на динамику: уменьшается ли число мусорных URL, не растёт ли количество исключённых страниц по причине noindex там, где вы этого не хотели, и не появились ли ошибки сканирования.

Если canonical и robots настроены правильно, обычно видно, что поисковик перестаёт считать параметры и служебные страницы отдельными ценными документами. Но если в индексе уже накопились старые URL, их вывод может занять время.

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

Закрывают всю пагинацию через robots.txt

Это одна из самых грубых ошибок. Если запретить обход /page/ в robots.txt, поисковик может потерять доступ к важным страницам архива и не увидеть связи между материалами. Обычно лучше управлять индексацией через canonical и meta robots, а не рубить обход целиком.

Ставят canonical на первую страницу для всех страниц серии

Так делают по привычке, но это не всегда правильно. Если вторая и последующие страницы содержат уникальные записи, canonical на первую страницу может мешать их нормальной обработке. Для архивов с реальной ценностью безопаснее оставлять self-canonical.

Дублируют title на всех страницах

Если title одинаковый, поисковику сложнее различать страницы серии. Добавьте номер страницы или уточнение типа архива. Главное — не делать это механически для всех шаблонов, а проверить, где это действительно нужно.

Закрывают параметры, но забывают про внутренние ссылки

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

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

Любая правка SEO-логики на живом сайте должна идти через staging или хотя бы через резервную копию. Особенно если вы меняете шаблоны темы или подключаете фильтры в functions.php.

• не редактируйте ядро WordPress;
• используйте дочернюю тему или небольшой mu-plugin для точечных правок;
• перед деплоем проверьте страницу архива, пагинацию и URL с параметрами;
• если сайт большой, не добавляйте тяжёлую логику в wp_head без необходимости;
• после изменений очистите кэш страницы и объектный кэш, если он есть.

Если нужен более широкий набор инструментов для чистки дублей, управления мета-тегами и отключения лишнего мусора в WordPress, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином базовую логику canonical и индексации всё равно стоит проверять руками.

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

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

• тема генерирует некорректные canonical;
• SEO-плагин не умеет различать ваши архивы;
• фильтры создают URL, которые нельзя отключить в интерфейсе;
• нужно точечно настроить поведение только для определённых шаблонов.

В остальных случаях лишний код только усложняет поддержку. Лучше убрать источник дублей в одном месте, чем потом искать, почему canonical конфликтует с плагином или почему часть архивов стала noindex по ошибке.