Пагинация и SEO: как правильно настроить постраничную навигацию

Пагинация — это разбивка длинного списка товаров или статей на страницы: page/2, page/3, ?page=4. Без неё каталог из тысячи позиций превратился бы в бесконечную ленту, которая никогда не загрузится. Но для SEO постраничная навигация — источник тихих, незаметных проблем: дубли мета-тегов, размывание ссылочного веса, бесполезная трата краулингового бюджета и риск, что товары с глубоких страниц вообще не попадут в индекс. В этом материале разбираем, как настроить пагинацию правильно, чтобы она помогала, а не мешала SEO-продвижению сайта.

Что такое пагинация и зачем она нужна

Пагинация — это механизм постраничного вывода списка, когда позиций слишком много для одной страницы. Категория «Диваны» с восемьюстами товарами разбивается на страницы по сорок штук — получается двадцать URL: первая страница каталога и девятнадцать страниц пагинации. Технически они оформляются либо как ЧПУ-сегмент (/divany/page/2/), либо как GET-параметр (/divany/?page=2). То же самое происходит в блоге, в ленте новостей, в результатах поиска по сайту — везде, где список не помещается на один экран.

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

Проблема не в пагинации как таковой, а в том, как с ней обращаются поисковики и как её настраивают разработчики. Страницы пагинации — особый класс URL: они не дубли друг друга (на каждой свои товары), но и не самостоятельные посадочные (по ним обычно не продвигаются). Эта двойственность и порождает все сложности. Если настроить неправильно, можно либо засорить индекс, либо, наоборот, спрятать половину каталога от поиска.

В чём проблема пагинации для SEO

Первая и самая частая проблема — дубли мета-тегов и текста. По умолчанию движок ставит одинаковые title, description и H1 на первую страницу и на все страницы пагинации: «Диваны — купить в Москве» на каждой из двадцати. Для поисковика это двадцать почти одинаковых страниц с идентичными мета. Хуже того, многие сайты выводят SEO-текст категории на каждой странице пагинации — и тогда дублируется ещё и контент. Механика того, как дубли вредят сайту, разобрана в статье про canonical и дубли.

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

Третья и самая опасная проблема — трата краулингового бюджета и риск непопадания товаров в индекс. Робот тратит обходы на страницы пагинации, и если их сотни (большой каталог, мелкая разбивка), бюджет уходит на них, а не на карточки товаров. Ещё критичнее то, что товары с глубоких страниц — page/15, page/20 — робот может вообще не дойти, особенно если на них ведёт длинная цепочка переходов. В результате значительная часть ассортимента остаётся за пределами индекса и не приносит трафика. О том, как поисковик решает, что индексировать, — в статье про индексацию сайта.

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

Canonical: self или на первую страницу

Главный спорный вопрос настройки пагинации — куда указывать rel=canonical. Есть два подхода, и у каждого свои последствия. Первый — self-canonical: каждая страница пагинации каноническая сама на себя, page/2 указывает на page/2. Второй — canonical на первую: все страницы пагинации указывают на первую страницу категории как на каноническую. На первый взгляд второй вариант кажется чище — мол, собираем весь вес на главную страницу категории. Но он несёт скрытую опасность.

Когда вы ставите canonical на первую страницу, вы говорите поисковику: «страницы 2, 3, 4 — это копии первой, индексируй только первую». Но это неправда — на странице page/5 совсем другие товары, которых нет на первой. Поисковик, поверив canonical, может перестать индексировать товары с глубоких страниц вовсе. В итоге в индекс попадают только первые сорок позиций каталога, а остальные семьсот шестьдесят становятся невидимыми для поиска. Для большого магазина это катастрофа. Именно поэтому canonical на первую — рискованный выбор, особенно когда товары не дублируются на других страницах.

Self-canonical безопаснее: каждая страница пагинации признаётся самостоятельной, робот её обходит, видит товары и доводит до карточек. Минус — страницы пагинации остаются в индексе, и нужно дополнительно решать вопрос с дублями мета. Но этот минус управляем (уникализируем мета и убираем дублирующий текст), а вот спрятанные товары при canonical на первую вернуть в индекс гораздо сложнее. Ниже — сводная таблица подходов.

rel=next/prev и навигация для робота

Раньше стандартом считались теги rel=next и rel=prev — они связывали страницы пагинации в последовательность, говоря поисковику «это серия, страница 2 идёт за первой». В 2019 году Google официально заявил, что не использует эти теги уже несколько лет и определяет пагинацию иначе. Яндекс их тоже не выделяет как ключевой сигнал. То есть полагаться на rel=next/prev как на решение проблемы пагинации нельзя — они не управляют индексацией.

Значит ли это, что их нужно убрать? Не обязательно. Вреда от них нет, а как семантическая разметка навигации они остаются корректными и могут помогать роботу понять структуру. Но важнее не теги, а реальные HTML-ссылки между страницами. Робот должен видеть в коде обычные ссылки <a href> на следующую и предыдущую страницы, а ещё лучше — на несколько ближайших и на последнюю. Тогда он гарантированно обойдёт всю последовательность и доберётся до товаров.

Практический вывод: не тратьте силы на rel=next/prev как на панацею, но обязательно убедитесь, что навигация по страницам реализована настоящими ссылками в HTML, а не только JavaScript-кнопками. Это куда важнее любых служебных тегов. Робот ходит по ссылкам — дайте ему ссылки. О том, как поисковик обрабатывает JavaScript, поговорим отдельно ниже.

Уникализация мета на страницах пагинации

Если вы выбрали self-canonical и страницы пагинации остаются в индексе, обязательно уникализируйте их мета-теги. Самый простой и надёжный приём — добавлять в title и description обозначение номера страницы: «Диваны — купить в Москве — страница 2». Так вы убираете полную идентичность мета, и поисковик перестаёт считать страницы дублями. Это копеечная по трудозатратам правка с заметным эффектом — настраивается один раз шаблоном на весь сайт.

Параллельно нужно убрать дублирующийся SEO-текст со страниц пагинации. Большой описательный текст категории должен выводиться только на первой странице — там, где он работает на продвижение по основному запросу. На страницах page/2 и глубже его быть не должно: он лишь дублирует контент и засоряет индекс. Принципы того, как мета-теги влияют на сниппет и клики, разбирает материал про Title и Description.

Стоит ли вообще держать листинги в индексе — зависит от ситуации. Если страницы пагинации с уникализированными мета не вредят и иногда даже ловят НЧ-трафик, их можно оставлять (self-canonical). Если каталог огромный и страниц пагинации тысячи, разумнее закрыть их в noindex, follow — тогда их нет в индексе, но робот всё равно ходит по ссылкам к товарам. Выбор зависит от размера каталога и того, как робот справляется с обходом.

Бесконечная прокрутка и кнопка «показать ещё»

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

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

Решение — гибридный подход. Визуально оставляем кнопку «показать ещё» или подгрузку для пользователя, но под капотом обеспечиваем настоящую пагинацию: у каждой порции товаров есть свой URL (page/2, page/3), эти адреса доступны по обычным HTML-ссылкам, и робот может обойти их напрямую, минуя JavaScript. Так пользователь получает удобство, а поисковик — полный доступ ко всему каталогу. Это обязательное требование для любого магазина с бесконечной прокруткой.

Почему ссылки на товары должны быть в HTML

Главный принцип, который объединяет всё сказанное: ссылки на товары должны присутствовать в исходном HTML-коде страницы, а не появляться только после выполнения JavaScript. Поисковый робот в первую очередь работает с HTML — именно из него он извлекает ссылки и ставит страницы в очередь на обход. Если ссылка на товар существует только в виде JS-обработчика на кнопке, велик риск, что робот её не найдёт и товар не попадёт в индекс.

Это касается не только пагинации, но и фильтров, табов, аккордеонов, всплывающих блоков. Любой контент, который важен для поиска, должен отдаваться сервером в HTML. Проверить просто: откройте исходный код страницы (не инструменты разработчика, а именно «view-source») и поищите ссылки на товары. Если их там нет, а в браузере они есть, — у вас проблема с доступностью контента для робота, которую нужно решать на уровне разработки.

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

Пагинация в блоге и типичные ошибки

В блоге пагинация работает по тем же принципам, но с нюансами. Страницы блога /blog/page/2 — это списки анонсов статей, и относиться к ним стоит как к навигации: self-canonical или noindex, follow, чтобы робот доходил до всех статей, но не индексировал десятки однотипных листингов. Большой текст и ключевая семантика должны быть на первой странице блога; страницы пагинации остаются служебными. Так весь архив статей остаётся доступен для обхода, а индекс не засоряется.

Соберём типичные ошибки в одном месте. Первая — одинаковые мета на всех страницах пагинации: лечится добавкой «— страница N». Вторая — canonical на первую страницу при уникальных товарах на каждой: прячет половину каталога из индекса. Третья — дублирующийся SEO-текст на каждой странице: оставляем только на первой. Четвёртая — навигация только через JavaScript без HTML-ссылок: товары не доходят до индекса. Пятая — слишком мелкая разбивка (по 10 товаров), плодящая лишние страницы и пожирающая краулинговый бюджет.

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

Пошаговая настройка пагинации

Сведём всё в практическую последовательность. Эти шаги подходят и для интернет-магазина, и для крупного блога или новостного раздела. Начните с диагностики — часто оказывается, что проблема не там, где её ищут.

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