Дубли страниц пагинации в WordPress обычно всплывают не там, где их ждут: в категориях, архивах, метках, на странице блога и в результатах фильтрации. На сайте это выглядит как десятки почти одинаковых URL с одинаковыми заголовками и контентом, а в Search Console — как лишние страницы, которые поисковик то индексирует, то исключает. Проблема не в самой пагинации, а в том, что WordPress и тема могут по-разному строить ссылки, canonical и мета-теги.
Ниже — рабочий сценарий: как найти источник дублей, что править в теме или плагине, как проверить результат и где чаще всего ломают индексацию.
Как понять, что у вас именно дубли пагинации
Сначала стоит отделить нормальную пагинацию от проблемной. Страница /category/news/page/2/ сама по себе не ошибка. Ошибка начинается, когда одна и та же сущность доступна по нескольким адресам: с /page/2/ и без него, через параметры ?paged=2, с разными слешами, через архив автора и через категорию одновременно.
Типичные признаки
- в индексе есть URL вида
/page/2/,/page/3/, но canonical указывает на первую страницу; - в отчёте «Страницы с дублирующимся, отправленным пользователем canonical» появляются архивы и пагинация;
- в HTML у разных страниц одинаковый
<title>и почти одинаковый<meta name="description">; - в теме есть кастомные ссылки на архивы, которые не учитывают текущую пагинацию;
- страницы блога открываются и как
/blog/, и как/blog/page/2/, а иногда ещё и как/index.php/blog/page/2/.
Что проверить в первую очередь
- Откройте несколько архивов: категорию, метку, автора, страницу блога.
- Посмотрите исходный код и найдите
rel="canonical". - Сравните URL в адресной строке и canonical.
- Проверьте, не генерирует ли тема дополнительные ссылки на ту же страницу через меню, хлебные крошки или блоки «похожие записи».
Диагностика: где именно рождается дубль
У WordPress есть несколько источников пагинации, и каждый может вести себя по-своему. Самая частая ошибка — чинить только SEO-плагин, когда проблема на самом деле в шаблоне архива или в неправильном запросе.
Проверка canonical и robots
Если canonical на второй странице архива указывает на первую, это не всегда ошибка. Для пагинации это часто нормальное поведение. Но если при этом в индексе оказываются и параметры фильтрации, и дубли с ?paged=2, и чистые URL /page/2/, значит, нужно смотреть на маршрутизацию и генерацию ссылок.
Быстрая проверка через консоль:
curl -sL https://example.com/category/news/page/2/ | grep -iE 'canonical|robots|title'Если у вас есть доступ к серверу, полезно сравнить ответы для нескольких вариантов URL:
curl -I https://example.com/category/news/page/2/
curl -I https://example.com/category/news/?paged=2
curl -I https://example.com/category/news/page/2Смысл не в том, чтобы все варианты отдавали одинаковый код ответа, а в том, чтобы понять: какой адрес считается основным, а какой — лишним.
Проверка шаблона архива
Если тема выводит пагинацию вручную, часто в коде встречаются ссылки, которые не учитывают текущую страницу или строятся через get_pagenum_link() без нормализации. Это особенно заметно на кастомных архивах и в шаблонах, где разработчик собрал пагинацию сам, а не через стандартный paginate_links().
Проверьте, не используется ли где-то в теме что-то вроде:
<a href="?paged=2">2</a>Такой вариант часто создаёт дубли, потому что поисковик видит несколько равнозначных путей к одной и той же странице.
Пошаговое решение без поломки индексации
Ниже — безопасный порядок действий. Он подходит, если у вас обычный WordPress-сайт с архивами записей, категориями и метками.
Шаг 1. Привести пагинацию к одному формату
В шаблонах используйте стандартную генерацию ссылок. Для архивов записей и таксономий лучше опираться на paginate_links() и текущий запрос, а не собирать URL вручную.
<?php
global $wp_query;
$big = 999999999;
echo paginate_links([
'base' => str_replace($big, '%#%', esc_url(get_pagenum_link($big))),
'format' => '?paged=%#%',
'current' => max(1, get_query_var('paged')),
'total' => $wp_query->max_num_pages,
'prev_text' => '←',
'next_text' => '→',
]);Если у вас статическая страница блога, проверьте, что шаблон использует корректный запрос и не подменяет paged на произвольный параметр.
Шаг 2. Убрать лишние варианты URL через редирект
Если сайт уже накопил дубли с параметром ?paged=2 или без слеша в конце, можно привести их к одному каноническому виду редиректом. Делать это нужно аккуратно: не трогать реальные служебные параметры и не ломать поиск по сайту.
<?php
add_action('template_redirect', function () {
if (is_admin() || wp_doing_ajax()) {
return;
}
if (isset($_GET['paged']) && !isset($_GET['s'])) {
$paged = absint($_GET['paged']);
if ($paged > 1) {
$url = get_pagenum_link($paged);
wp_safe_redirect($url, 301);
exit;
}
}
});Этот пример не универсален для всех сайтов, но показывает принцип: редиректить только очевидные дубли, а не всё подряд.
Шаг 3. Проверить canonical в SEO-плагине
Если у вас установлен SEO-плагин, убедитесь, что он не переписывает canonical для пагинации неправильно. В некоторых конфигурациях canonical на второй странице архива должен указывать на саму страницу пагинации, а не на первую страницу раздела. Это зависит от выбранной SEO-логики и структуры сайта.
Если вы используете плагины для чистки дублей и технической оптимизации, вроде Clearfy Pro, проверьте, не включена ли там опция, которая конфликтует с вашим SEO-плагином. Два инструмента, которые одновременно правят canonical и robots, часто создают больше проблем, чем решают.
Шаг 4. Убрать дубли из шаблонов и хлебных крошек
Иногда дубль создаёт не пагинация как таковая, а элементы интерфейса. Например, хлебные крошки ведут на архив категории, а рядом есть ссылка на ту же категорию с параметром страницы. Или блок «ещё записи» строит URL через home_url() без учёта текущего контекста.
Проверьте:
- меню и подменю;
- хлебные крошки;
- виджеты и блоки в сайдбаре;
- кастомные блоки в редакторе;
- шаблоны
archive.php,category.php,tag.php,home.php.
Сравнение подходов: плагин, код или правка темы
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Если проблема только в canonical, robots и мета-тегах | Быстро, без правки шаблонов | Не чинит кривые ссылки в теме |
| Код в теме или дочерней теме | Если дубли рождаются в шаблонах и URL-генерации | Точный контроль | Нужна проверка после обновлений темы |
| Редиректы на сервере или в WordPress | Если уже есть накопленные дубли | Убирает старые адреса из обхода | Можно случайно задеть нужные параметры |
Как проверить, что решение сработало
После правок не ограничивайтесь открытием одной страницы в браузере. Нужно проверить и HTML, и поведение URL, и то, как сайт отвечает на старые адреса.
- Откройте первую, вторую и третью страницы архива.
- Проверьте, что canonical соответствует выбранной логике.
- Убедитесь, что
?paged=2либо редиректит, либо не индексируется, если это ваш сценарий. - Проверьте, что в sitemap не появились лишние URL пагинации, если вы их не планировали.
- Прогоните несколько URL через
curl -Iи убедитесь, что нет цепочек редиректов.
Если используете Google Search Console, смотрите не только на статус страниц, но и на то, как меняется список обнаруженных URL. Иногда проблема не исчезает сразу, потому что поисковик ещё держит старые адреса в обходе.
Частые ошибки и как их исправить
Редиректят все страницы с параметром paged
Это ломает нормальную пагинацию в архивах. Нужно отличать служебный параметр для навигации от мусорных параметров. Если редиректить без условий, можно случайно закрыть рабочие страницы разделов.
Ставят noindex на все архивы подряд
Такой подход иногда используют как быстрый способ убрать дубли, но он не решает проблему источника. В итоге поисковик перестаёт понимать структуру сайта, а полезные разделы теряют внутренний вес.
Меняют canonical вручную и забывают про шаблоны
Если canonical правится только на уровне SEO-плагина, а тема продолжает генерировать неправильные ссылки, дубли остаются в обходе и в логике сайта. Нужно чинить причину, а не только мета-тег.
Смешивают несколько SEO- и кеш-плагинов
Когда один плагин переписывает canonical, второй чистит head, а третий кэширует старую версию страницы, отладка превращается в угадывание. Сначала отключите конфликтующие функции и проверьте базовую страницу без кэша.
Практические советы по безопасности и производительности
Любая правка URL-логики должна проходить через staging-копию. Это не формальность: один неверный редирект на архиве может создать петлю или закрыть важные страницы от обхода.
- сохраняйте резервную копию перед изменениями в
functions.phpили в mu-plugin; - не редактируйте ядро WordPress;
- если правите тему, лучше вынести логику в дочернюю тему или отдельный мини-плагин;
- после внедрения очистите кэш страниц и объектный кэш, если он есть;
- проверяйте изменения на мобильной и десктопной версии, если тема по-разному строит архивы.
Если задача шире, чем один дубль, и на сайте много технического мусора, иногда проще собрать это в один набор настроек через Clearfy Pro: убрать лишние дубли, почистить head и не держать часть логики в теме. Но даже в этом случае сначала стоит понять, что именно создаёт лишние URL, а уже потом включать автоматические опции.
Главный критерий успеха здесь простой: у страницы должен быть один понятный основной адрес, а все остальные варианты либо должны вести к нему, либо не должны появляться в индексе. Если после правок вы видите, что пагинация работает, canonical стабилен, а старые URL не плодятся дальше, значит, проблема закрыта правильно.