Как убрать дубли страниц пагинации в WordPress-блоге

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

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

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

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

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

• в Google Search Console разделы «Страницы» и «Проверка URL» для URL вида /page/2/;
• наличие в индексе страниц пагинации рубрик и главной ленты;
• canonical на страницах /page/2/ и дальше;
• нет ли у темы отдельной пагинации для главной, рубрик и архивов с разной логикой.

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

Быстрая диагностика в браузере

Откройте страницу /page/2/ любой рубрики и посмотрите исходный код. Ищите:

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

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

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

Пошаговое решение через код темы или мини-плагин

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

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

add_action('wp_head', function () {
    if (is_paged() && (is_home() || is_category() || is_tag() || is_author() || is_archive())) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1);

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

Когда лучше править canonical

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

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

Если используете SEO-плагин: что проверить в настройках

Не пытайтесь одновременно лечить одну и ту же проблему кодом темы, настройками плагина и ручными мета-тегами. Сначала выясните, кто именно управляет robots и canonical. Для блогов на WordPress чаще всего это SEO-плагин и тема.

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

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

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

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

Мини-чек-лист проверки

• откройте /page/2/ и убедитесь, что в исходнике есть только один meta robots;
• проверьте canonical на нескольких типах страниц: главная, рубрика, тег, автор;
• посмотрите HTTP-ответ через DevTools или curl -I;
• очистите кеш плагина и серверный кеш;
• в Search Console отправьте URL на повторную проверку.

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

curl -I https://example.com/category/news/page/2/

Если страница отдаёт 200 OK, а в HTML появился noindex,follow, значит логика сработала. Если после очистки кеша в коде всё ещё старый canonical или старый robots, значит правка сидит не там, где вы думаете: возможно, её перезаписывает SEO-плагин или кэшированная версия шаблона.

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

Добавили noindex на все архивы без разбора

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

Оставили два источника robots

Один тег пришёл из темы, второй — из SEO-плагина. Поисковик может интерпретировать это по-разному, а вы получите нестабильное поведение в индексе. Решение: оставить один источник управления мета-тегами и убрать ручной вывод из шаблона.

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

После правки код уже изменён, но в браузере и у поисковика ещё висит старая версия. Особенно часто это случается при использовании page cache и CDN. Проверяйте не только страницу в админке, но и реальный HTML по URL.

Пытались закрыть пагинацию в robots.txt

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

Что учесть для безопасности и производительности

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

С точки зрения производительности сам вывод meta robots почти ничего не стоит. Но если вы начинаете городить сложную логику с запросами к базе на каждом хите, это уже лишнее. Для такой задачи нужен простой условный вывод без дополнительных запросов.

Если блог активно растёт и вы регулярно чистите технический мусор, имеет смысл держать под рукой инструменты, которые помогают не только с дублями, но и с общим SEO-гигиеническим набором. Главное — не перекладывать на плагин то, что проще и надёжнее контролировать в коде.

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

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

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