Пагинация и бесконечная прокрутка каталога на 1С-Битрикс: SEO и UX

В каталоге из тридцати позиций способ разбивки списка не важен: всё умещается на один экран. Но в реальном магазине на 1С-Битрикс раздел легко содержит сотни и тысячи товаров, и тут возникает вопрос — как показать их пользователю и как отдать роботу. От ответа зависит сразу две вещи: удобство покупателя, который листает выдачу, и то, доберётся ли поисковик до товаров со второй, десятой и сотой «страницы». Ошибка в разбивке каталога тихо выбрасывает часть ассортимента из индекса, и обнаруживается это обычно спустя месяцы падающего трафика.

Эта статья — практический разбор пагинации, «показать ещё» и бесконечной прокрутки на 1С-Битрикс с точки зрения SEO и UX: чем способы отличаются, как сделать ЧПУ-адреса страниц вместо параметров, какой ставить canonical, что стало с rel=next/prev и как построить подгрузку так, чтобы она не убивала индексацию. Материал из нашей практики проектирования SEO-структуры каталогов — без «секретов продвижения», по делу.

Зачем каталогу продуманная разбивка списка

Разбивка большого списка на части решает три задачи одновременно. Первая — производительность: показать пользователю сразу тысячу карточек с картинками значит заставить браузер тянуть мегабайты и «подвесить» слабое устройство. Вторая — навигация: человек должен понимать, где он находится в списке и как вернуться туда, где остановился. Третья, менее очевидная и самая коварная — индексация: поисковый робот обходит каталог по ссылкам, и если товары со второй страницы никак не связаны с первой настоящими адресами, до них он просто не дойдёт.

Именно третья задача чаще всего проваливается незаметно. Магазин выглядит красиво, покупатели листают ленту, менеджеры радуются плавной прокрутке — а половина ассортимента тем временем отсутствует в поиске, потому что её адреса нигде не прописаны как ссылки. Поэтому продуманная разбивка каталога — это не про «красивую кнопку», а про баланс между тремя интересами: скоростью, удобством и видимостью в поиске.

Что мы называем «страницей пагинации»

Под страницей пагинации мы понимаем адрес, который показывает определённую порцию товаров раздела: первая страница — базовый URL категории, вторая и далее — отдельные адреса (в идеале ЧПУ вида /catalog/obuv/page-2/). Каждая такая страница — самостоятельный документ с точки зрения поисковика: у неё свой URL, свой набор товаров и свои метатеги. От того, как эти документы устроены и связаны, зависит, попадут ли товары в индекс и не появится ли лавина дублей.

Три способа разбивки: краткий обзор

На практике каталог разбивают одним из трёх способов или их комбинацией. У каждого своя механика взаимодействия с пользователем и своя цена для SEO.

• Классическая пагинация. Внизу списка — набор ссылок на страницы: «1 2 3 … Вперёд». Каждая страница — отдельный адрес, переход перезагружает список. Самый прозрачный для поисковика способ.
• «Показать ещё» / подгрузка по кнопке. Показана первая порция, под ней кнопка «Показать ещё». По клику следующая порция догружается на JS и добавляется в конец списка без перезагрузки. Управление остаётся у пользователя.
• Бесконечная прокрутка (infinite scroll). Новая порция подгружается автоматически, когда пользователь долистал до низа. Кнопки нет — лента «бесконечна». Максимально «залипательный» UX и максимально рискованный для SEO, если сделан наивно.

Важно понимать: эти способы не взаимоисключающие. Правильная архитектура — когда в основе лежат настоящие страницы пагинации с ЧПУ-адресами, а «показать ещё» или прокрутка надстраиваются сверху скриптом. Тогда пользователь получает плавный UX, а робот — честные ссылки. Ниже разберём каждый способ по отдельности, а затем покажем, как их правильно совмещать.

Классическая пагинация: плюсы и минусы

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

Сильные стороны

• Прозрачность для робота. Ссылки «1 2 3 …» — это обычные <a href>, по которым поисковик проходит и обходит весь ассортимент.
• Понятная навигация. Пользователь видит, сколько всего страниц, и может прыгнуть на нужную.
• Стабильные адреса. Конкретную страницу можно сохранить и вернуться к ней — состояние не теряется, как при прокрутке.
• Контроль краулинга. Легко управлять тем, какие страницы индексируются, а какие нет.

Слабые стороны

• Разрыв внимания. Каждый переход — перезагрузка списка и «прыжок» вверх, что на длинных сессиях листания утомляет.
• Меньше «залипания». Пользователь чаще останавливается, дойдя до конца страницы, чем при бесшовной ленте.
• Мобильная эргономика. Мелкие номера страниц неудобно нажимать пальцем без аккуратной вёрстки.

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

«Показать ещё» и подгрузка по кнопке

Способ «показать ещё» — золотая середина. Пользователь видит первую порцию товаров, а под ней кнопку. По клику следующая порция подгружается скриптом и добавляется в конец списка без полной перезагрузки страницы. Ключевое отличие от бесконечной прокрутки — управление остаётся у человека: он сам решает, догружать ли ещё, и не теряет контроль над лентой.

Этот способ хорош тем, что легко делается SEO-безопасным. Кнопка «Показать ещё» по своей сути — это ссылка на следующую страницу пагинации. Если реализовать её как настоящий <a href="/catalog/obuv/page-2/">, а JS лишь перехватывает клик и подгружает содержимое, то мы получаем идеальную картину: пользователь видит плавную подгрузку, а робот — обычную ссылку на вторую страницу. Именно так устроен и пейджер блога B2Bsite: «Показать ещё» является ссылкой на следующую страницу, а скрипт лишь надстраивается сверху.

Плюсы «показать ещё»

• Управление у пользователя — нет ощущения «ловушки бесконечной ленты».
• Легко сделать SEO-безопасным через ссылку на следующую страницу.
• Меньше «прыжков» вверх, чем при классической пагинации.
• Есть естественная точка остановки — под подгруженными товарами обычно виден футер.

Бесконечная прокрутка: соблазн и риск

Бесконечная прокрутка автоматически подгружает новую порцию, как только пользователь долистал до низа. Кнопки нет — лента продолжается сама. Такой UX отлично работает в лентах соцсетей и медиа, где цель — удержать внимание как можно дольше и где нет задачи «дойти до конкретного товара». В интернет-магазине у прокрутки есть несколько специфических проблем.

UX-проблемы прокрутки в магазине

• Недостижимый футер. Пока подгружаются товары, футер с важными ссылками (доставка, контакты, гарантии) убегает вниз, и до него не долистать.
• Потеря позиции. Пользователь ушёл в карточку товара и вернулся — лента сбросилась к началу, место просмотра потеряно.
• Нет ощущения объёма. Непонятно, сколько всего товаров и сколько ещё листать — теряется чувство прогресса.
• Тяжесть DOM. Накопленные сотни карточек замедляют устройство, особенно бюджетные смартфоны.

SEO-риск

Главная опасность — не в UX, а в индексации. Если прокрутка сделана «в лоб», подгрузка идёт по AJAX-запросу к API, а в исходной разметке первой страницы нет ссылок на остальные, то для робота каталог заканчивается на первой порции. Все товары, которые появляются только при прокрутке, оказываются недоступны поисковику. Об этом — отдельный раздел ниже, потому что это самая частая и самая дорогая ошибка.

Сравнение способов: UX и SEO

Сведём три способа в таблицу. Оценка условная и отражает поведение «из коробки», без специальных доработок вроде надстройки ссылок под прокрутку.

Вывод из таблицы простой: классическая пагинация и «показать ещё» безопасны по умолчанию, а бесконечная прокрутка требует осознанной работы, чтобы не навредить поиску. При этом лучший UX прокрутки можно получить и без её рисков — если построить её поверх настоящих страниц. Как именно — ниже.

Почему прокрутка без ссылок вредит индексации

Разберём механику проблемы по шагам, потому что понимание этой цепочки экономит месяцы недополученного трафика. Поисковый робот не «прокручивает» страницу как человек. Он загружает HTML, находит в нём ссылки и переходит по ним. Да, современные роботы умеют исполнять JavaScript, но с оговорками: это дороже по ресурсам, откладывается во времени, и полагаться на то, что робот доскроллит вашу ленту и дождётся всех AJAX-подгрузок, нельзя.

Теперь представим «чистую» бесконечную прокрутку без ссылок. В HTML первой страницы лежат, скажем, 24 карточки товара. Больше в разметке ничего нет — остальные подгружаются скриптом при прокрутке через запрос к API. Что видит робот:

1. Загружает первую страницу. Находит 24 карточки товара и ссылки на них.
2. Ищет ссылки дальше. Ссылок на страницу 2, 3, N в разметке нет — есть только скрипт, реагирующий на прокрутку.
3. Не находит продолжения. Каталог для робота заканчивается на 24 товарах, даже если реально их 2400.
4. Не индексирует остальное. 99% ассортимента остаётся вне поиска — не потому, что запрещён, а потому что не найден.

Самое коварное здесь — что визуально всё работает. Владелец сайта листает каталог, видит все товары, тестировщик проходит сценарии, дизайнер доволен плавностью. А поисковик тем временем знает лишь про первый экран каждого раздела. Проблема всплывает только в аналитике: страницы товаров не растут в индексе, органический трафик стагнирует, хотя ассортимент расширяется. И связать это с прокруткой без ссылок удаётся не сразу.

SEO-дружественная подгрузка: ссылки + JS

Хорошая новость: отказываться от плавного UX не нужно. Правильная схема — прогрессивное улучшение. В основе лежат настоящие страницы пагинации с ЧПУ-адресами и обычными ссылками, а подгрузка на JavaScript надстраивается сверху. Если скрипт не сработал (медленный интернет, отключённый JS, робот) — остаётся полностью рабочая навигация по ссылкам.

Как это устроено технически

1. Рендерим полноценный пейджер. Внизу списка сервер отдаёт настоящие ссылки на страницы: /catalog/obuv/page-2/, /page-3/ и так далее — они присутствуют в HTML до всякого JS.
2. Кнопка «Показать ещё» — тоже ссылка. Она указывает на следующую страницу пагинации через href, а не является пустым элементом.
3. JS перехватывает клик/прокрутку. Скрипт отменяет стандартный переход, запрашивает следующую страницу и добавляет карточки в конец списка без перезагрузки.
4. Обновляем адрес в браузере. Через History API меняем URL на текущую подгруженную страницу, чтобы позиция сохранялась и её можно было скопировать.
5. Оставляем деградацию. Без JS ссылки работают как обычная пагинация — робот и пользователь на медленном соединении не теряют доступ к товарам.

Именно так устроен пейджер в блоге на этом сайте: функция blog_render_pager() выводит реальные <a> на страницы /page-N/, первая страница живёт по чистому URL без page-1, а кнопка «Показать ещё» — это ссылка с атрибутом data-next, поверх которой JS может догружать карточки. Тот же принцип переносится на каталог 1С-Битрикс.

ЧПУ-пагинация в 1С-Битрикс: /page-2/

По умолчанию постраничная навигация в компонентах 1С-Битрикс работает через GET-параметр вида ?PAGEN_1=2. Технически это рабочий вариант, но у него есть недостатки: адрес выглядит менее аккуратно, параметр может комбинироваться с другими и порождать дубли, а человекопонятный ЧПУ-адрес /catalog/obuv/page-2/ чище и лучше воспринимается. Поэтому на SEO-ориентированных проектах пагинацию переводят на ЧПУ.

Число «1» в PAGEN_1 — это номер компонента постраничной навигации на странице; если на странице несколько списков, у каждого свой счётчик. При переходе на ЧПУ этот технический нюанс скрывается за чистым адресом /page-N/, что заодно снижает шанс на случайные дубли из-за нескольких параметров.

Настройка пагинации в компонентах каталога

В 1С-Битрикс каталог обычно выводит комплексный компонент bitrix:catalog, который включает в себя списки разделов и товаров (catalog.section) и работает в SEF-режиме — то есть с человекопонятными адресами. Постраничная навигация формируется шаблоном bitrix:system.pagenavigation, а её вид и логика задаются на уровне шаблона компонента. Именно там определяется, как выглядят ссылки на страницы и по какому адресу они ведут.

Что участвует в настройке

• SEF-режим комплексного компонента. Включает ЧПУ-адреса разделов и товаров; в его правилах прописывается и шаблон адреса страницы пагинации с фрагментом page-#PAGE#.
• Шаблон постраничной навигации. Отвечает за вёрстку пейджера: номера страниц, «назад/вперёд», кнопку «показать ещё». Здесь важно выводить настоящие <a href>.
• Параметры компонента списка. Размер страницы (сколько товаров на странице), режим ЧПУ навигации, показ количества страниц.
• Обработка выхода за диапазон. Логика, отдающая 404 или редирект, когда запрошена несуществующая страница.

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

Canonical на страницах пагинации

Это самый спорный и самый важный вопрос пагинации. Атрибут rel="canonical" сообщает поисковику, какой адрес считать основным среди похожих. И здесь легко допустить дорогую ошибку. Рассмотрим два подхода.

Актуальная безопасная практика для каталога магазина — самоканоничность. Каждая страница пагинации канонична сама себе. Логика такая: страница /page-2/ — это не дубль /page-1/, у неё другой набор товаров, а значит она самостоятельный документ, достойный собственного места в индексе. Если же канонизировать все страницы на первую, поисковик получает сигнал «основной контент — на первой странице», и товары, которые есть только на страницах 2, 3, N, рискуют выпасть из индекса. Для магазина это прямая потеря видимости ассортимента.

Исключение — ситуация, когда вторая страница действительно является дублем первой из-за технического параметра (например, добавился незначимый GET, но контент не изменился). Тогда каноничность на основной адрес оправдана. Но это про параметрический дубль, а не про нормальную постраничную навигацию. Различать эти случаи — часть работы; подробнее про параметры и склейку — в статье про редиректы, 404 и склейку URL в Битрикс.

rel=next/prev: история и текущий статус

Несколько лет назад стандартной рекомендацией для пагинации были теги <link rel="next"> и <link rel="prev"> в <head>. Они указывали поисковику на предыдущую и следующую страницы в серии, помогая ему понять, что это единая последовательность. Многие SEO-руководства и модули настраивали эти теги как обязательный элемент пагинации.

Ситуация изменилась: Google публично сообщил, что уже несколько лет не использует rel=next/prev как сигнал для индексирования. Иными словами, эти теги перестали быть инструментом склейки серии страниц в понимании крупнейшего поисковика. Что это значит на практике:

• Не полагайтесь на них как на решение. Если единственное, что «связывает» ваши страницы для поисковика, — это rel=next/prev, то фактически они ничем не связаны. Нужны настоящие ссылки в теле страницы.
• Оставить их не вредно. Теги остаются валидной семантической разметкой; их могут учитывать другие системы, браузеры для предзагрузки, иные поисковики. Убирать их специально не нужно.
• Фокус сместился. Вместо ставки на rel=next/prev опирайтесь на внутреннюю перелинковку, настоящие <a> в пейджере и самоканоничность страниц.

Итог: относитесь к rel=next/prev как к необязательному дополнению, а не к фундаменту. Фундамент пагинации — обычные ссылки, по которым робот доходит до всех товаров, и корректный canonical. Разные поисковые системы могут вести себя по-разному, но принцип «настоящие ссылки важнее спецтегов» универсален.

Метатеги на страницах пагинации

Если товары со второй и последующих страниц должны индексироваться (а в самоканонической схеме — должны), возникает вопрос метатегов. Что писать в title и description для /page-2/? Оставить такими же, как на первой странице, значит создать десятки страниц с одинаковыми метатегами — это дубли метаданных, которые поисковик не любит.

Практика уникализации

• Добавляйте номер страницы в title. Шаблон вида «Обувь — страница 2 | Магазин» отличает страницы друг от друга и честно сообщает, что это продолжение списка.
• То же для description. Либо добавляйте маркер страницы, либо оставляйте description пустым на страницах пагинации, чтобы не плодить дубли описаний.
• H1 обычно не меняют. Заголовок раздела остаётся тем же — это нормально, различие несёт title.
• Не индексируйте бессмысленно. Если контента на страницах пагинации мало и он однотипный, часть проектов помечает глубокие страницы noindex, follow — робот идёт по ссылкам дальше, но саму страницу в индекс не берёт. Это тонкая настройка под конкретный каталог.

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

Дубль page-1 и страницы за диапазоном

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

Дубль первой страницы

Возникает, когда первая страница доступна по двум адресам: чистому /catalog/obuv/ и техническому /catalog/obuv/page-1/ (или ?PAGEN_1=1). Оба отдают идентичный контент — это дубль. Лечение: первая страница живёт только по базовому URL, а любые варианты с page-1 или PAGEN=1 отдают 301-редирект на чистый адрес. В самоканонической схеме именно базовый URL является каноническим для первой страницы.

Пустые страницы за пределами диапазона

Если в разделе 20 страниц, а кто-то (или робот, нашедший битую ссылку) запрашивает /page-999/, страница не должна отдавать пустой список товаров с кодом 200. Пустая страница с кодом «всё хорошо» — это мусор в индексе: поисковик набирает пустышки-дубли, которые тратят краулинговый бюджет. Правильная реакция:

Сортировки и фильтр в пагинации

Пагинация не живёт в вакууме — поверх неё работают сортировки и фильтры, и они умножают число комбинаций адресов. Одна и та же вторая страница может существовать в вариантах «по цене возрастанию», «по популярности», «по новизне». Каждый вариант — технически отдельный URL, и если ими не управлять, каталог зарастает параметрическими дублями.

Сортировки

Сортировка меняет порядок тех же товаров, но не сам их состав в рамках раздела. Для поиска это дубль. Практика: параметры сортировки (?sort=, ?order=) закрывают от обхода в robots и/или канонизируют версию с сортировкой на версию без неё. Пользователю сортировка нужна, роботу — нет, поэтому её держат вне индекса.

Фильтры

С фильтром сложнее, потому что фильтры бывают двух видов. Технические параметрические комбинации фильтра — это дубли, которые закрывают от обхода. А осмысленные комбинации под спрос, превращённые в индексируемые ЧПУ-посадочные, — это самостоятельные страницы, и у каждой такой посадочной своя пагинация. Её строят по тем же правилам: ЧПУ-адреса страниц, самоканоничность, обработка выхода за диапазон. То есть у ЧПУ-страницы фильтра /catalog/obuv/krasnye/ есть свои /page-2/, /page-3/, и они живут по той же логике, что пагинация обычной категории.

Ключевое различие — не путать параметрический дубль с посадочной. Первое закрываем и канонизируем, второе индексируем со всей его пагинацией. Про то, как разделять эти случаи и превращать спрос в посадочные, — в материалах рубрики «SEO и продвижение».

Пагинация и краулинговый бюджет

На большом каталоге пагинация напрямую влияет на краулинговый бюджет — объём внимания, который поисковик выделяет сайту. Здесь есть тонкий баланс. С одной стороны, страницы пагинации нужны, чтобы робот дошёл до всех товаров. С другой — если пагинация плодит дубли (page-1, сортировки, параметры), робот тратит бюджет на мусор вместо товаров.

Как пагинация экономит или транжирит бюджет:

Вывод: пагинация должна быть «худой» — минимум лишних адресов, никаких дублей и пустышек, быстрый ответ. Тогда бюджет тратится на реальные товары и категории. Тема краулингового бюджета для крупного магазина заслуживает отдельного разбора — мы посвятили ей материал про краулинговый бюджет большого магазина на 1С-Битрикс, где пагинация рассматривается в связке с robots, sitemap и скоростью.

Скорость подгрузки и производительность

Способ разбивки каталога влияет не только на индексацию, но и на скорость — а скорость, в свою очередь, важна и для UX, и для SEO. Разные способы нагружают браузер по-разному.

• Классическая пагинация держит DOM небольшим: на странице всегда фиксированное число карточек. Переход перезагружает список, но сам список лёгкий.
• «Показать ещё» накапливает карточки в DOM по мере кликов, но пользователь контролирует объём — обычно останавливается через несколько порций.
• Бесконечная прокрутка наиболее опасна: если не ограничивать, DOM разрастается до тысяч элементов, растёт потребление памяти, страница начинает «лагать», ухудшаются метрики скорости.

Как держать подгрузку быстрой

• Разумный размер порции. Не грузите по 100 карточек за раз — 24–48 обычно достаточно, чтобы и экономить трафик, и не частить запросами.
• Ленивая загрузка изображений. Картинки карточек грузятся при приближении к вьюпорту, а не все сразу.
• Ограничение DOM. Для прокрутки — виртуализация или выгрузка ушедших далеко за экран карточек, чтобы DOM не рос бесконечно.
• Кэширование ответов. Порции каталога хорошо кэшируются; на 1С-Битрикс здесь помогают штатное кэширование компонентов и композитный сайт.

Производительность каталога — большая тема, тесно связанная с Core Web Vitals. Подгрузка и пагинация — лишь один из её факторов, но заметный: тяжёлая бесконечная лента способна испортить метрики даже при в остальном быстром сайте. Смежные вопросы скорости мы разбираем в рубрике «Разработка и архитектура».

Мобильный UX постраничной навигации

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

• Классическая пагинация. Мелкие номера страниц трудно нажимать пальцем. Решение — крупные тапабельные элементы, достаточные отступы, заметные «назад/вперёд».
• «Показать ещё». Обычно самый комфортный мобильный вариант: одна большая кнопка, понятное действие, управление у пользователя.
• Бесконечная прокрутка. Кажется естественной для мобильного жеста, но создаёт проблему недостижимого футера и потери позиции при возврате из карточки — на мобильном это раздражает сильнее.

Практический компромисс для мобильных: «показать ещё» как основной механизм подгрузки плюс доступный полноценный пейджер со ссылками (пусть даже свёрнутый). Так пользователь получает удобную кнопку, а робот и те, кому нужна конкретная страница, — настоящие ссылки. И обязательно оставляйте футер достижимым: важные ссылки на доставку, оплату и контакты не должны «убегать» вниз бесконечно.

Реализация: компоненты, ЧПУ, canonical

Соберём практическую последовательность внедрения правильной пагинации на 1С-Битрикс — от адресов до кодов ответа.

1. Включите ЧПУ-адреса страниц. Настройте комплексный компонент каталога и шаблон постраничной навигации так, чтобы страницы имели адреса /page-N/ вместо ?PAGEN_1=N.
2. Уберите дубль первой страницы. Первая страница — только базовый URL; page-1 и ?PAGEN_1=1 редиректятся 301 на чистый адрес.
3. Выводите настоящие ссылки. В шаблоне пейджера — обычные <a href> на страницы; кнопка «показать ещё» тоже ссылка на следующую страницу.
4. Сделайте страницы самоканоническими. Каждая /page-N/ ссылается каноническим адресом сама на себя, а не на первую страницу.
5. Уникализируйте метатеги. Добавьте номер страницы в title (шаблоном), решите вопрос с description на глубоких страницах.
6. Обработайте выход за диапазон. Несуществующие страницы отдают 404 или 301, а не пустой список с кодом 200.
7. Разберитесь с сортировками. Параметры сортировки закройте от обхода и/или канонизируйте на версию без сортировки.
8. Надстройте подгрузку. Добавьте JS-подгрузку и/или прокрутку поверх ссылок как прогрессивное улучшение, с обновлением URL через History API.
9. Проверьте индексацию. Убедитесь в вебмастере, что товары со страниц 2, 3, N попадают в индекс, а дублей и пустышек нет.

Эта последовательность универсальна: сначала — правильные адреса и коды ответов, потом — canonical и метатеги, и только в конце — красивая подгрузка. Если начать с прокрутки и «забыть» про ссылки, получится тот самый провал индексации, с которого мы начали.

Частые ошибки пагинации

Эти промахи встречаются чаще всего и обходятся дорого — потерянной индексацией или лавиной дублей:

• Бесконечная прокрутка без ссылок. Товары подгружаются только по AJAX, в разметке нет <a> на страницы — робот видит лишь первый экран, остальной ассортимент вне индекса.
• Canonical со всех страниц на первую. Кажется «склейкой дублей», а на деле выбрасывает из индекса товары со 2-й и последующих страниц.
• Дубль page-1. Первая страница доступна и по /catalog/obuv/, и по /page-1/ — два адреса с одинаковым контентом.
• Пустые страницы за диапазоном. /page-999/ отдаёт пустой список с кодом 200 вместо 404/301 — фабрика мусорных дублей.
• Ставка на rel=next/prev. Пагинацию «связывают» только этими тегами, которые Google для индексирования не использует; настоящих ссылок нет.
• Одинаковые метатеги на всех страницах. Десятки страниц с идентичными title и description — дубли метаданных.
• Кнопка вместо ссылки. «Показать ещё» сделана пустым <button> с JS — без скрипта не работает, роботу бесполезна.
• Сортировки без контроля. Параметры сортировки открыты для обхода и множат пагинацию в разы, транжиря краулинговый бюджет.
• Тяжёлая бесконечная лента. DOM растёт до тысяч карточек без выгрузки — страница «лагает» на мобильных, портятся метрики скорости.

Чек-лист приёмки

Практический список для проверки пагинации перед запуском:

1. ЧПУ включены. Страницы имеют адреса /page-N/, а не ?PAGEN.
2. Настоящие ссылки. В пейджере обычные <a href>; «показать ещё» — тоже ссылка.
3. Нет дубля page-1. Первая страница только по базовому URL; page-1 редиректится 301.
4. Самоканоничность. Каждая страница пагинации канонична сама себе, а не на первую.
5. Выход за диапазон. Несуществующие страницы отдают 404 или 301, не пустой список 200.
6. Метатеги уникальны. Номер страницы отражён в title; description не дублируется.
7. Сортировки под контролем. Параметры закрыты от обхода и/или канонизированы.
8. Подгрузка как улучшение. JS-подгрузка/прокрутка надстроены поверх ссылок и деградируют без JS.
9. Производительность в норме. DOM не разрастается, изображения ленивые, порции разумного размера.
10. Индексация проверена. Товары со страниц 2, 3, N попадают в индекс; дублей и пустышек нет.

Вывод

Пагинация каталога — это не выбор «пагинация против бесконечной прокрутки», а вопрос, есть ли в разметке настоящие ссылки на страницы. Классическая пагинация и «показать ещё» безопасны по умолчанию, потому что дают роботу честные адреса; бесконечная прокрутка красива для пользователя, но без ссылок делает большую часть ассортимента невидимой для поиска. Правильная архитектура объединяет и то, и другое: настоящие ЧПУ-страницы /page-N/ как фундамент и плавная подгрузка на JavaScript как надстройка.

Технические детали складываются в дисциплину: ЧПУ вместо параметров, самоканоничность вместо canonical на первую, уникальные метатеги со номером страницы, 301 для дубля page-1 и 404/301 за пределами диапазона, контроль сортировок и внимание к скорости. Настроенная так пагинация одинаково хорошо служит и покупателю, который листает каталог, и поисковику, который обходит весь ассортимент. А устаревшая ставка на rel=next/prev уступает место простому и надёжному принципу: настоящие ссылки важнее спецтегов.