Пагинация сама по себе не проблема. Проблема начинается, когда в индекс попадают десятки почти одинаковых страниц архивов, рубрик, тегов или поиска: /page/2/, /page/3/ и дальше. В результате поисковик тратит обход на мусорные URL, а в отчётах по индексации появляются дубли и «страницы с одинаковым заголовком и описанием».
Ниже — рабочая схема для WordPress: где именно искать причину, что закрывать, а что оставлять доступным, и как проверить, что после правок сайт не потерял нужные страницы.
Когда пагинация становится дублем
Сам по себе URL второй страницы архива не всегда нужно закрывать. Если на странице есть уникальный набор записей, нормальная навигация и корректный canonical, поисковик может спокойно держать её в индексе. Но на практике дубли появляются в типичных сценариях:
- на страницах рубрик и тегов одинаковые title и description для всех страниц пагинации;
- в шаблоне архива выводится слишком короткий список записей, и страницы 2–5 почти не отличаются друг от друга;
- плагин SEO ставит одинаковый canonical на первую страницу архива и на все последующие;
- внутренний поиск, сортировки и фильтры создают новые URL с пагинацией и параметрами;
- в sitemap попадают страницы, которые вы не хотите продвигать.
Что смотреть в первую очередь
Откройте несколько URL вручную и сравните:
/category/news//category/news/page/2//tag/wordpress/page/2/
Если в исходном коде у них одинаковый <title>, одинаковый meta description и canonical указывает на первую страницу, это уже кандидат на чистку. Если же пагинация нужна для пользователя, но не нужна в поиске, закрывать её надо аккуратно, не ломая обход и переходы.
Диагностика проблемы: где именно создаются дубли
Сначала определите источник. В WordPress дубли от пагинации обычно создаются не в одном месте, а на уровне шаблона, SEO-плагина и настроек индексации.
Проверка шаблона архива
Посмотрите, как формируется список записей. Если в теме используется кастомный запрос через WP_Query, важно, чтобы пагинация строилась через корректный параметр paged. Иначе WordPress может показывать одну и ту же выдачу на разных страницах.
$paged = max( 1, get_query_var( 'paged' ) );
$query = new WP_Query( array(
'post_type' => 'post',
'posts_per_page' => 10,
'paged' => $paged,
) );Если paged не передан, страницы архива будут выглядеть как копии первой страницы. Это не только SEO-проблема, но и баг навигации.
Проверка canonical и robots
Откройте исходный код страницы и найдите:
rel="canonical";meta name="robots";- наличие
noindexна страницах пагинации; - попадает ли URL в sitemap.
Если canonical указывает на первую страницу, а контент второй страницы отличается, это спорная настройка. Если же вы сознательно хотите исключить пагинацию из индекса, canonical на первую страницу допустим, но лучше не делать это без проверки на конкретном шаблоне.
Пошаговое решение: что закрывать и чем
Универсального рецепта нет. Для одних сайтов достаточно убрать пагинацию из sitemap и оставить canonical, для других — добавить noindex,follow на архивы, а для третьих — вообще не трогать пагинацию, а исправить шаблон и мета-данные.
Вариант 1. Закрыть пагинацию от индексации через noindex,follow
Это самый безопасный вариант, если вы не хотите, чтобы страницы /page/2/ и дальше попадали в индекс, но при этом хотите сохранить обход ссылок внутри архива.
Если у вас есть доступ к коду темы, можно добавить условие в functions.php или в мини-плагин:
add_filter( 'wp_robots', function( array $robots ) {
if ( is_paged() && ( is_category() || is_tag() || is_archive() ) ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант не трогает первую страницу архива и не мешает переходам по ссылкам. Но он работает только если тема и SEO-плагин не переопределяют robots позже по приоритету.
Вариант 2. Исправить canonical для пагинированных архивов
Если canonical на страницах пагинации настроен неправильно, поисковик может считать разные страницы дублями первой. Для архивов часто логичнее оставлять canonical на саму страницу пагинации, а не на первую страницу. Это особенно важно, если на второй и третьей страницах реально разные записи.
В Yoast SEO и похожих плагинах canonical обычно лучше настраивать через их фильтры, а не прямой вывод в шаблоне. Если же вы пишете свой код, не подменяйте canonical без проверки логики архива.
Вариант 3. Убрать пагинацию из sitemap
Если страницы пагинации не должны индексироваться, не стоит оставлять их в карте сайта. Иначе вы сами подаёте поисковику сигнал, что эти URL важны.
В большинстве SEO-плагинов это делается настройкой индексации архивов. Если плагин не даёт нужной гибкости, проверьте, не генерирует ли тема или кастомный код отдельный sitemap. Для самописных решений можно исключать пагинированные URL на этапе генерации списка.
Сравнение подходов
| Подход | Когда подходит | Минус |
|---|---|---|
noindex,follow | Нужно убрать пагинацию из индекса, но сохранить обход | Не решает проблему плохого canonical |
| Исправление canonical | Пагинация должна оставаться понятной поисковику | Нужна аккуратная настройка в теме или SEO-плагине |
| Исключение из sitemap | Страницы не нужны в поиске | Не заменяет robots и canonical |
Проверка результата после внедрения
После правок не ограничивайтесь просмотром кода страницы. Проверьте поведение на уровне индексации и обхода.
- Откройте несколько пагинированных URL и убедитесь, что на них стоит нужный
meta robots. - Проверьте canonical: он должен соответствовать выбранной логике, а не случайно указывать на первую страницу.
- Посмотрите, не исчезли ли ссылки на следующие страницы из HTML-вывода архива.
- Проверьте sitemap: пагинированные URL не должны туда попадать, если вы решили их закрыть.
- В Search Console посмотрите, не растёт ли число страниц со статусом «Просканировано, но не проиндексировано» из-за дублей.
Если у вас есть доступ к серверным логам, полезно посмотреть, как часто бот ходит на /page/2/ и дальше. Иногда проблема не в индексации, а в том, что бот тратит обход на бесполезные страницы вместо важных.
Частые ошибки и как их исправить
Ставят noindex на все архивы сразу
Это грубая ошибка. В итоге можно убрать из поиска полезные страницы рубрик, которые реально приводят трафик. Закрывать нужно только пагинированные страницы или конкретные типы архивов, а не весь архивный раздел без разбора.
Меняют canonical, но не меняют sitemap
Такое часто делают после настройки SEO-плагина. В результате canonical говорит одно, а карта сайта — другое. Поисковик получает противоречивые сигналы и дольше переобходит сайт.
Ломают пагинацию в кастомном запросе
Если в теме используется собственный WP_Query, но не передан paged, страницы архива начинают повторять первую. Это уже не SEO-ошибка, а баг шаблона. Исправляется на уровне запроса, а не мета-тегов.
Закрывают URL в robots.txt и думают, что этого достаточно
Disallow не убирает URL из индекса, если на него уже есть ссылки. Для дублей пагинации этого обычно недостаточно. Нужна комбинация: корректный canonical, noindex там, где уместно, и чистая карта сайта.
Мини-чек-лист перед публикацией правок
- Проверен исходный код первой и второй страницы архива.
- На пагинированных URL стоит выбранная директива robots.
- Canonical не конфликтует с логикой архива.
- Пагинация работает в теме и в кастомных запросах.
- Пагинированные страницы исключены из sitemap, если это было нужно.
- В Search Console нет резкого роста дублей после изменения.
Практические советы по безопасности и производительности
Если вы правите это через код, лучше вынести изменения в небольшой mu-plugin или отдельный функциональный плагин, а не в functions.php темы. Тогда настройка не слетит при обновлении темы.
Не ставьте тяжёлые фильтры на каждый запрос без необходимости. Условие is_paged() дешёвое, но если вы добавляете дополнительные проверки по типам архивов и таксономиям, тестируйте на реальном трафике. Для сайтов с большим количеством архивов полезно проверить, не создаёт ли SEO-плагин лишние мета-теги на каждой странице.
Если у вас уже есть плагин для технической чистки сайта, например Clearfy Pro, часть задач по дублям и индексации можно закрыть настройками без самописного кода. Но даже в этом случае логику пагинации всё равно нужно проверять вручную: плагины не угадывают особенности конкретной темы и кастомных архивов.
Самый надёжный подход здесь простой: сначала понять, нужна ли пагинация в индексе именно для вашего типа контента, потом выбрать один способ управления — noindex, canonical или исключение из sitemap — и только после этого проверять результат в поисковой консоли и исходном коде страниц.
