Пагинация и SEO: как не засорить индекс страницами 2, 3, 4

Страницы 2, 3, 4 становятся проблемой, когда у них одинаковые заголовок и описание: в индекс попадают сотни почти одинаковых страниц. Атрибуты next и prev поисковики больше не используют, поэтому работают три схемы: уникализация мета-данных, канонический адрес или запрет индексации.

Пагинация выглядит как мелкая техническая деталь, пока не открываешь отчёт об индексации и не видишь там три сотни страниц каталога с одинаковым тайтлом и одинаковым дескрипшеном. Эта статья для владельцев блогов и интернет-магазинов на WordPress, OpenCart и Битрикс, у которых листинг товаров или записей растянут на десятки страниц вида /catalog/page/2/. Разберу, что реально работает в 2026 году, три рабочие схемы разметки, готовый код для WordPress и чек-лист, по которому проверить результат в Вебмастере и Search Console.

Почему страницы 2, 3, 4 вообще становятся проблемой

Возьмём типичный магазин на OpenCart: категория «Смесители» на 180 товаров, по 20 карточек на страницу, итого 9 страниц пагинации. Если ничего не настроено, у всех девяти одинаковый title «Смесители — Название магазина», одинаковый h1, почти одинаковый meta description. Робот заходит на страницу 1, видит по ссылкам страницы 2-9, обходит их, тратит на это время и лимит запросов к сайту за один визит (краулинговый бюджет), а на выходе получает девять почти неотличимых документов.

Для сайта с парой сотен URL это не страшно. Для каталога на 5000 товаров с категориями по 15-20 страниц пагинации каждая счёт идёт на десятки тысяч лишних URL, часть из которых робот вообще не успевает дойти до товарных карточек в глубине списка. Я видел магазин на Битрикс, где новые товары в популярной категории попадали в индекс через три-четыре недели после публикации именно по этой причине: робот увязал в дублях пагинации раньше, чем добирался до последних страниц списка.

Вторая проблема более прямая: страницы 2, 3, 4 конкурируют за одни и те же запросы с главной страницей категории. Поисковик видит десяток похожих документов и сам решает, какой показывать в выдаче, а это редко тот, что нужен вам. Отсюда скачущие позиции у категорийных страниц без видимой причины.

Rel next и prev: мёртвый стандарт, о котором до сих пор спрашивают

Долгое время рекомендацией было ставить в head тегов rel=»next» и rel=»prev», чтобы дать поисковику понять последовательность страниц. Google официально отказался учитывать этот сигнал ещё в 2019 году, представитель компании подтверждал это несколько раз с тех пор. Яндекс полноценно этот тег никогда не поддерживал как самостоятельную инструкцию, для него страницы пагинации это обычные документы, которые он обходит по обычным ссылкам.

Практический вывод: если у вас на сайте эти теги уже стоят, можно не убирать, вреда от них нет. Но закладывать в план работ их добавление ради SEO-эффекта в 2026 году смысла нет. Реальный контроль над индексацией пагинации сейчас идёт через canonical, noindex и структуру ссылок, а не через устаревший сигнал.

Три рабочие схемы и что выбрать

Схема 1: индексируем все страницы с уникальным заголовком

Каждая страница пагинации получает canonical на саму себя (self-referencing canonical) и остаётся в индексе. Чтобы страницы не дублировали друг друга дословно, в title и description добавляется номер страницы, а если получится, что-то более содержательное: диапазон цен, часть ассортимента, актуальную дату для блога.

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

Схема 2: canonical всех страниц пагинации на первую

Второй, третьей и последующим страницам ставится canonical, указывающий на страницу 1 той же категории. Это сигнал поисковику: считай весь этот диапазон одним документом, в индекс клади только первую страницу.

Просто в реализации, снимает проблему дублей за один плагин или один фильтр в шаблоне. Минус ощутимый: товары, которые физически доступны только со страницы 5 или 8 (а такие всегда есть, если сортировка не «по популярности»), рискуют вообще не попасть в индекс, если на них нет прямых ссылок откуда-то ещё. Для интернет-магазина, где каждая товарная карточка потенциально продающая страница, это плохой размен.

Схема 3: noindex, follow на второй и последующих страницах

Компромиссный и на практике самый частый вариант в 2026 году. Первая страница индексируется как обычно. Вторая и далее получают мета-тег robots со значением noindex, follow: страница исключается из индекса, но робот продолжает переходить по ссылкам на ней, находя товарные карточки в глубине списка.

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

Схема	В индексе	Товары с последних страниц	Сложность настройки
Индексируем всё	Все страницы пагинации	Доступны напрямую	Высокая, нужна уникализация
Canonical на первую	Только страница 1	Риск потерять из индекса	Низкая
Noindex, follow	Только страница 1	Доступны через переход робота	Средняя

Для большинства сайтов, с которыми я работаю (визитки с блогом, магазины до 2000 SKU), рекомендую третью схему как отправную точку. Первую оставляю только там, где на страницах 2-3 реально лежит SEO-ценный товар и есть ресурс писать под них отдельные мета-теги.

Уникализация title и description на страницах пагинации

Если выбрали первую схему или просто хотите снизить долю дублей даже при noindex (страница временно теряет noindex из-за бага в плагине, а title уже уникальный, подушка безопасности), title и description нужно генерировать программно, а не руками на каждую категорию.

В WordPress это делается фильтром на составные части тайтла:

add_filter('document_title_parts', function ($parts) {
    if (is_paged()) {
        $page = get_query_var('paged');
        $parts['title'] .= ' - Страница ' . $page;
    }
    return $parts;
});

add_action('wp_head', function () {
    if (is_paged()) {
        $page = get_query_var('paged');
        echo '<meta name="robots" content="noindex, follow">' . "n";
    }
}, 1);

Второй блок как раз реализует схему 3 без плагинов: если запрошена не первая страница пагинации, в head добавляется noindex, follow. Если на сайте уже стоит Rank Math или Yoast, свой вывод меты может конфликтовать с их, тогда лучше настроить через фильтр самого SEO-плагина, а не добавлять параллельный тег.

Для OpenCart и Битрикс логика та же, но живёт в шаблоне категории или в компоненте: проверяется GET-параметр номера страницы ($_GET[‘page’] в OpenCart, дефолтный SEF-параметр PAGEN_1 в Битрикс) и в зависимости от значения формируется свой title и своя мета robots.

Показать все и бесконечная прокрутка: где теряются ссылки

Кнопка «Показать все» и бесконечная прокрутка удобны для человека и почти всегда вредны для обхода, если сделаны неправильно. Частая ошибка: подгрузка следующих товаров происходит через JavaScript без изменения URL и без реальных ссылок с href. Робот не кликает кнопки и не скроллит бесконечно, для него товары дальше первого экрана просто не существуют.

Рабочий подход: у каждой «страницы» бесконечной ленты должен быть реальный URL с обычной ссылкой (даже если визуально всё склеено в одну прокручиваемую ленту через JS, это называется прогрессивным улучшением). Отдельно можно сделать страницу «показать все» как самостоятельный индексируемый URL для не слишком длинных категорий (до 60-80 товаров), она снимает часть проблемы пагинации целиком, потому что дублей просто не возникает.

Для длинных категорий на тысячи товаров «показать всё» одной страницей не вариант: страница станет тяжёлой, начнёт проваливаться по Core Web Vitals, что отдельная головная боль, если у вас и так плавает LCP.

Как это выглядит в WordPress и Битрикс на практике

В WordPress структура пагинации стандартная: /category/santehnika/page/2/. Частая ошибка, которую вижу у клиентов, пришедших с другого подрядчика: /page/ закрыт в robots.txt директивой Disallow. Это не решает проблему дублей, а усугубляет её: страница остаётся в индексе (если уже туда попала), потому что noindex в закрытом для обхода документе робот прочитать не может, но новый контроль через мета-теги на неё уже не доходит. Правильный порядок: сначала настраиваем canonical или noindex в шаблоне, потом уже думаем про robots.txt, и в большинстве случаев закрывать /page/ не нужно вообще.

В Битрикс пагинация чаще всего идёт через компонент catalog.section с параметром PAGEN_1, и логику noindex приходится дописывать в шаблон компонента вручную, штатной настройки под это нет. В обоих случаях стоит держать в голове разницу между «закрыть от индексации» и «закрыть от обхода»: первое делается мета-тегом на странице, второе директивой в robots.txt, и путать их значит либо не решить проблему, либо создать новую.

Проверка: как убедиться, что сделали правильно

После настройки любой из трёх схем нужно подтвердить результат, а не полагаться на то, что код написан верно. Чек-лист, по которому проверяю после каждой такой настройки:

• В Яндекс Вебмастере, раздел «Страницы в поиске», ищем предупреждения о дублирующихся title и description по URL с /page/ в адресе.
• В Google Search Console, отчёт Coverage, ищем статус «Duplicate, Google chose different canonical than user» (значит canonical не срабатывает так, как задумано).
• Открываем исходный код второй-третьей страницы категории через «Просмотр кода страницы» и проверяем реальное значение meta robots и rel canonical, а не то, что должно быть по задумке.
• Проверяем, что sitemap.xml не включает страницы, которым назначен noindex: если включает, это создаёт противоречивый сигнал поисковику.
• Через месяц после изменений сверяем число страниц категории в индексе (оператор site: сайт intitle:»название категории») с ожидаемым.

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

Что делать прямо сейчас

Если у вас каталог или блог с активной пагинацией и вы ни разу не проверяли, как поисковик видит эти страницы, начните с отчёта об индексации в Вебмастере: за пять минут станет видно, есть ли там массовые дубли title. Заодно стоит прогнать сайт на предмет дублей другого рода: обзор инструментов и типичных источников дублирующего контента есть в статье как найти дубли страниц. Если пагинация не единственная проблема с индексацией, проверьте заодно актуальность самого файла sitemap.xml: как его настроить под WordPress и Битрикс, разбирал в статье про карту сайта.

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

Частые вопросы

Как правильно настроить пагинацию для SEO

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

Работают ли атрибуты next и prev

Нет. Google перестал их использовать, Яндекс на них и не опирался. Оставлять их не вредно, но пользы от них никакой.

Ставить ли canonical на первую страницу

Обычно нет. Товары и записи на второй странице отличаются от первой, и канонический адрес выбросит их из индекса вместе со ссылками на карточки.

Что делать с бесконечной прокруткой

Дублировать её обычной пагинацией со ссылками. Робот не прокручивает страницу, и без ссылок он просто не увидит ничего дальше первой порции.