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

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

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

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

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

• в Google Search Console откройте отчёт по страницам и посмотрите, есть ли URL с /page/2/, /page/3/ и похожими хвостами;
• проверьте исходный код архивов: есть ли rel="canonical" и куда он указывает;
• посмотрите, не закрывает ли тема или плагин пагинацию через noindex или, наоборот, не оставляет ли её полностью открытой;
• сравните заголовки и мета-описания первой и последующих страниц архива — если они одинаковые, это уже повод навести порядок.

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

Что делать: выбрать одну из трёх моделей

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

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

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

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

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

Этот вариант подходит, если у вас нет уже настроенного SEO-плагина, который генерирует robots meta. Если плагин есть, сначала проверьте его настройки, чтобы не получить два разных robots в одной странице.

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

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_paged() && (is_category() || is_tag() || is_author() || is_post_type_archive())) {
        return $canonical;
    }

    return $canonical;
}, 10, 2);

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

Когда лучше использовать плагин

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

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

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

1. Откройте страницу архива и её пагинированную версию, например /category/news/page/2/.
2. Посмотрите исходный код и убедитесь, что на второй и последующих страницах есть noindex,follow или нужный вам canonical.
3. Проверьте, что первая страница архива не получила случайно тот же robots-тег.
4. В Search Console отправьте URL на повторную проверку и посмотрите, как меняется статус через несколько дней или недель.
5. Убедитесь, что внутренние ссылки на пагинацию остались рабочими и не ведут на 404.

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

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

Закрыли все архивы целиком

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

В теме и в плагине стоят разные правила

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

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

Это частая ошибка при ручной проверке. Первая страница архива может выглядеть идеально, но проблема сидит на /page/2/ и глубже. Проверяйте именно пагинированные URL.

Ставят canonical на главную

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

Чек-лист перед публикацией правок

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

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

С точки зрения производительности сама мета-разметка почти ничего не стоит, но проблема обычно в другом: админ начинает массово править шаблоны, не понимая, где именно генерируется HTML. Поэтому лучше вносить изменения в дочернюю тему или отдельный мини-плагин, а не в файлы родительской темы. Тогда обновление темы не сотрёт правки.

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

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

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