Пагинация в SEO: как индексировать страницы-списки и не наплодить дублей

Короткий ответ: страницы пагинации не нужно оптимизировать под запросы — они почти никогда не ранжируются. Их задача другая: провести робота к товарам и статьям, до которых иначе не дойти. Поэтому у каждой страницы должен быть свой адрес, свой canonical на саму себя, обычные ссылки <a href> в разметке и разное содержимое. Три ошибки, которые встречаются чаще всего: canonical со всех страниц на первую, пагинация только на JavaScript и одинаковый контент на всех страницах списка. Последнюю мы нашли у себя.

Тема выглядит скучной ровно до того момента, пока не откроешь Search Console и не увидишь, что половина проиндексированных адресов сайта — это ?page=2, ?page=3 и так далее до сотни. Дальше начинаются вопросы: закрывать или не закрывать, ставить canonical или не ставить, что вообще Google сейчас про это думает, если rel=next он отменил ещё в 2019-м.

Отвечать на эти вопросы по учебникам не хотелось: половина статей в русскоязычном интернете до сих пор советует rel=next/prev, который не работает седьмой год. Поэтому я сделал два замера — по выдаче и по живым сайтам — и разобрал, кто как решает эту задачу на самом деле. Заодно нашёл проблему у себя, о ней будет отдельный раздел.

Сколько трафика на самом деле приносят страницы пагинации

Начну с цифры, ради которой всё это затевалось. Через Serpstat я выгрузил по 3000 самых трафиковых адресов из топ-20 у двенадцати украинских магазинов — итого 36 000 адресов — и посчитал, сколько среди них страниц пагинации. Искал по маркерам ?page=, ?p=, PAGEN_1=, /page/, ?offset=, ?start=.

Пятнадцать адресов из тридцати шести тысяч. Причём если посмотреть на эти пятнадцать вблизи, картина становится ещё скучнее: единственный адрес Eva — это catalog.eva.ua/flipbook/?Page=2, то есть листалка бумажного каталога, а не категория. Два адреса Hotline — страницы отзывов /yp/4005/reviews/?p=2. Реальная каталожная пагинация в топе есть только у Kasta, и то в виде ?offset=72.

Отдельно отмечу методическую деталь, на которой легко обмануться. Первый прогон я делал более широким шаблоном, куда попадал и /p\d+/ — и он «нашёл» 145 страниц пагинации у Rozetka. На самом деле это карточки товаров: у Rozetka товар живёт по адресу /hammer-tel000844/p458511719/, где p означает product, а не page. Пришлось переписать выражение строже. Если будете повторять замер — проверьте свои маркеры глазами на десятке адресов, иначе получите красивую, но неверную цифру.

Западные данные говорят то же самое. Гленн Гейб в разборе клиентского сайта, где пагинация составляла 67% всех проиндексированных адресов, посчитал её вклад в клики: 5 000 из 1 620 000 за три месяца. Это 0,3%.

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

Что Google требует от пагинации сегодня

Требований немного, они собраны в разделе документации по e-commerce, и почти все сформулированы как запреты. Выпишу дословно, потому что пересказы обычно теряют половину смысла.

У каждой страницы — свой адрес. «Give each page a unique URL. For example, include a ?page=n query parameter, as URLs in a paginated sequence are treated as separate pages by Google». Ключевое здесь — вторая половина: адреса последовательности Google считает отдельными страницами. Не вариантами одной, а отдельными.

Не канонизировать всё на первую страницу. «Don't use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL». Это прямой запрет, и нарушают его чаще всего.

Не использовать якорь для номера страницы. «Don't use URL fragment identifiers (the text after a # in a URL) for page numbers in a collection. Google ignores fragment identifiers». Адрес вида /catalog/#page=3 для поисковика не существует — это та же первая страница.

Ссылки должны быть ссылками. Google просит связывать страницы обычными тегами <a href> и отдельно советует давать со всех страниц ссылку обратно на первую — так понятнее, какая из них главная посадочная.

Фильтры и сортировки — не пагинация. «To avoid indexing variations of the same list of results, block unwanted URLs from being indexed with the noindex robots meta tag or discourage crawling of particular URL patterns with a robots.txt file». То есть комбинации «страница + фильтр + сортировка» из индекса надо убирать.

Что стало с rel=next и rel=prev

Эти теги до сих пор советуют в статьях, и это самая живучая ошибка в теме. Разберёмся с датами.

21 марта 2019 года Google объявил, что перестал их поддерживать. Формулировка была такая: «As we evaluated our indexing signals, we decided to retire rel=prev/next. Studies show that users love single-page content, aim for that when possible». Джон Мюллер тогда же сказал короче: «We don't use link-rel-next/prev at all».

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

Сегодня в документации это зафиксировано так: «In the past, Google used <link rel="next" href="..."> and <link rel="prev" href="..."> to identify next page and previous page relationships. Google no longer uses these tags, although these links may still be used by other search engines».

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

Три стратегии на живых сайтах: что показала проверка

Теория теорией, но интереснее посмотреть, как задачу решают те, кто в этой выдаче живёт. Я взял по одной категории у сайтов, которые отдаются без капчи, и прогнал первую и вторую страницу через curl: коды ответа, canonical, мета-robots, тайтл, объём текста.

Три сайта — три разные стратегии, и каждая внутренне логична.

Foxtrot делает всё по документации. Свой canonical, index, follow, тайтл и описание с префиксом номера страницы. Это ровно то, что просит Google. Замечу разницу в объёме текста: 4235 слов на первой странице против 2953 на второй — описание категории выводится только на первой, и это правильно.

Epicentr выбрал противоположное — и сделал это последовательно. Canonical со второй страницы ведёт на первую, плюс noindex, follow. Формально canonical здесь избыточен и Google его проигнорирует (об этом ниже), но noindex, follow работает: страницы обходятся, ссылочный вес по ним течёт к товарам, а в индекс они не попадают. И это согласовано с их robots.txt, где стоит Allow: /*?PAGEN_1=* при том, что почти все остальные параметры у них закрыты. То есть решение принято осознанно: обходить — да, индексировать — нет.

Наш блог в этой таблице выглядит прилично ровно до последней строки с объёмом текста. 49 516 слов против 49 512. Разница в четыре слова. Этому посвящён отдельный раздел ниже, и он неприятный.

Кто вообще закрыл пагинацию

Заодно я прочитал robots.txt восьми магазинов и выписал всё, что касается страниц списка:

epicentrk.ua   Allow: /*?PAGEN_1=*          — пагинация открыта явно
               Disallow: */server/page/*    — служебная закрыта
hotline.ua     Disallow: */page/            — пагинация закрыта целиком
prom.ua        Allow: *?p=*
               Allow: *reviews?page=*
eva.ua         Allow: /*?p=
foxtrot.com.ua — правил по пагинации нет
comfy.ua       — правил по пагинации нет
allo.ua        — правил по пагинации нет
makeup.com.ua  — правил по пагинации нет

Обратите внимание на Hotline: Disallow: */page/ закрывает пагинацию от обхода полностью. Это самое жёсткое решение из встреченных, и у него есть цена — если товары доступны только через пагинацию, робот до них не дойдёт. Работает это только тогда, когда есть другой путь: sitemap, перелинковка, фиды.

Тест на бесконечность: что отдаёт страница №9999

Есть быстрая проверка, которая занимает тридцать секунд и сразу показывает, ограничена ли пагинация или сайт готов генерировать адреса бесконечно. Запрашиваем заведомо несуществующую страницу списка и смотрим, что придёт.

curl -s -o /dev/null -w "%{http_code}\n" "https://site.ua/catalog/?page=9999"

Результаты по нашим трём подопытным:

Foxtrot закрывает пространство редиректом — правильно. Epicentr отдаёт 200 на любой номер, то есть теоретически может породить сколько угодно адресов; спасает их только noindex. У нас граница на месте: страницы существуют со второй по пятьдесят вторую, пятьдесят третья отдаёт 404. Проблема у нас, как выяснилось, совсем в другом.

Николай в разборе зомби-страниц описывал этот сценарий ещё в 2021-м:

«Есть странички пагинации, которые являются бесконечными, могут быть просто бесконечными, и на них может быть тратится кравлинговый бюджет».

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

Canonical со всех страниц на первую: почему так не работает

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

Джон Мюллер объяснил это одной фразой: «Page 2 isn't equivalent to page 1, so the rel=canonical like that would be incorrect». Canonical означает «эта страница — дубликат вон той». Вторая страница списка не дубликат первой: на ней другие товары. Google видит это несоответствие и canonical игнорирует.

Дальше начинается интересное. Раз canonical проигнорирован, страница индексируется как обычная. Только вы об этом не знаете, потому что были уверены, что закрыли вопрос. В Search Console это выглядит как «Копия: Google выбрал другую каноническую страницу» или как проиндексированные ?page= в отчёте «Страницы».

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

Правильная схема простая: canonical каждой страницы указывает на саму себя. Со всеми параметрами страницы и без параметров фильтров и сортировок.

<!-- на /catalog/?page=3 -->
<link rel="canonical" href="https://site.ua/catalog/?page=3">

<!-- на /catalog/?page=3&sort=price -->
<link rel="canonical" href="https://site.ua/catalog/?page=3">

Вторая строка — тот самый случай, когда canonical действительно уместен: сортировка не меняет набор товаров, только их порядок, поэтому версия с сортировкой честно является дубликатом.

Когда допустим noindex, follow

Вариант Epicentr выглядит грубо, но у него есть своя логика, и в двух случаях он оправдан.

Случай первый: каталог с сотнями страниц в одной категории. Если в категории 200 страниц пагинации, а в индексе они дают ноль трафика (см. первый раздел), их присутствие в индексе — чистый шум в отчётах. noindex, follow убирает шум, оставляя обход.

Случай второй: пагинация комбинируется с фильтрами. Когда адрес выглядит как ?page=7&sort=price&color=red, количество вариантов растёт как произведение, и открывать это в индекс нельзя ни при каком раскладе.

Важная оговорка про механику noindex, follow. Google неоднократно предупреждал, что в долгую он ведёт себя как noindex, nofollow: страницу, которую долго не индексируют, начинают реже обходить, и ссылки с неё теряют вес. Для пагинации это скорее теоретический риск, чем практический, — страницы списка обходятся часто из-за смены содержимого. Но если товары доступны только через пагинацию, лучше выбрать вариант Foxtrot и оставить страницы индексируемыми.

Чего делать точно не надо — сочетать noindex с закрытием в robots.txt. Робот, которому запрещён обход, не увидит мета-тег, и страница может попасть в индекс по внешним ссылкам без содержимого. Либо обход и noindex, либо запрет обхода — но не оба сразу.

Пагинация только на JavaScript: где обрывается дорога робота

Самая дорогая из технических ошибок, потому что она не видна ни в одном отчёте.

Из проверенных сайтов у двух — allo.ua и hotline.ua — в HTML первой страницы категории нет ни одной ссылки, похожей на пагинацию. Страницы отдают 200, весят два мегабайта и 320 килобайт соответственно, но переключателя страниц в разметке нет: он рисуется скриптом после загрузки.

Google в документации формулирует это без обиняков: «Google's crawlers don't "click" buttons and generally don't trigger JavaScript functions». Кнопка «Показать ещё», бесконечная прокрутка, переключатель на обработчике событий — всё это для робота не существует. Он видит первые двадцать товаров и уходит.

Проверяется одной командой — смотрим сырой HTML, без выполнения скриптов:

curl -s "https://site.ua/catalog/" | grep -oE 'href="[^"]*page[^"]*"' | head

Если пусто — переключатель нарисован скриптом. Это не приговор: Google рендерит JavaScript, и ссылки, которые появляются после рендера, он часто находит. Но рендеринг стоит ресурсов и происходит с задержкой, а на большом каталоге задержка означает, что часть товаров попадёт в индекс через недели, а часть не попадёт вовсе.

Рабочее решение — гибрид: подгрузка контента скриптом для человека и настоящие <a href> для робота, спрятанные стилями или вынесенные в блок «Все страницы» внизу. Google это прямо разрешает и даже советует.

Наш случай: 51 страница блога с одинаковым содержимым

Теперь про то, что я нашёл у себя, пока готовил этот материал. История поучительная, потому что показывает, как проблема появляется без единого неверного решения.

В 2021 году, разбирая зомби-страницы, я говорил следующее:

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

▶ Зомби страницы: какие бывают и как с ними бороться

С тех пор блог переехал на другой движок, пагинация появилась. И вот что она сейчас представляет собой на самом деле.

Страницы /blog/page/2/ … /blog/page/52/ отдают 200, пятьдесят третья — 404. Все пятьдесят одна лежат в карте сайта — то есть мы сами предлагаем Google их проиндексировать. У каждой свой canonical на себя, у каждой свой тайтл вида «SEO Блог: страница 7». По формальным признакам всё правильно.

А теперь замер:

# сравниваем первую страницу со второй и с сороковой
curl -s https://seoquick.com.ua/blog/          -o b1.html
curl -s https://seoquick.com.ua/blog/page/2/   -o b2.html
curl -s https://seoquick.com.ua/blog/page/40/  -o b40.html

размер:            3 064 292 / 3 063 733 / 3 064 795 байт
ссылок на статьи:  203 / 203 / 203
пересечение:       203 из 203
элементов ItemList: 1186 / 1186 / 1186

Все пятьдесят две страницы — первая и пятьдесят одна пагинационная — содержат одни и те же 203 ссылки на статьи и одну и ту же разметку ItemList на 1186 элементов. Отличается только тайтл.

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

Что здесь сделано неправильно, по пунктам:

• Содержимое не пагинируется на сервере. Страница /blog/page/7/ должна содержать статьи с 61-й по 70-ю, а содержит все 203.
• Разметка ItemList не пагинируется. 1186 элементов на каждой странице — это ещё и 130 килобайт JSON-LD, умноженные на 52.
• Всё это в sitemap. 51 адрес, которые мы сами предлагаем обойти и проиндексировать.
• Украинская и английская версии пагинации не имеют вовсе — /ua/blog/page/2/ отдаёт 404. То есть на двух языках из трёх старые статьи доступны только через перелинковку.

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

Что мы с этим делаем — задача уже в работе, и она в трёх пунктах: пагинировать содержимое и ItemList на сервере, отдавать 404 за пределами списка, убрать страницы пагинации из sitemap (первая страница в нём остаётся, а до остальных робот дойдёт по ссылкам). Про третий пункт ниже отдельно, потому что он спорный.

Контраргумент: а точно ли это вредит

Честности ради — есть данные, которые говорят, что пагинация в индексе не так страшна, как принято считать.

Гленн Гейб разбирал сайт, где пагинация составляла 67% всех проиндексированных адресов: 18 600 проиндексированных страниц при краул-футпринте в 200 тысяч. Сайт делал всё «по учебнику 2012 года» — self-canonical, rel=next/prev, текстовая навигация. Наблюдение шло шестнадцать месяцев. Результат: видимость стабильная, рост есть, признаков перерасхода краул-бюджета нет, свежий контент индексируется вовремя.

Вывод Гейба: «Google has a long history of handling pagination and it typically will not cause many problems» — при условии, что реализация корректная.

Как это сочетается с тем, что написано выше? Довольно просто, если разделить два разных вопроса.

То есть паниковать из-за самого факта «в индексе есть ?page=» не нужно. Разбираться надо, когда эти страницы дублируют друг друга, множатся бесконтрольно или закрывают путь к товарам.

Когда пагинация действительно ест краул-бюджет

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

• «Large sites (1 million+ unique pages) with content that changes moderately often (once a week)»;
• «Medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)».

Google тут же оговаривается, что это «rough estimate», а не точные границы. Но порядок понятен: сайт услуг на двести страниц может про краул-бюджет не думать вообще, а магазин на сто тысяч товаров — должен.

Что конкретно съедает обход, по той же документации: дубли и почти-дубли («this wastes a lot of Google crawling time on your site»), длинные цепочки редиректов («Avoid long redirect chains, which have a negative effect on crawling») и «infinite scrolling pages that duplicate information on linked pages» — прямое указание на нашу ситуацию с блогом.

Практический ориентир для магазина: если в отчёте статистики сканирования большая доля запросов приходится на адреса с ?page=, а карточки товаров индексируются неделями — вот тогда пагинация действительно мешает. Если карточки индексируются за сутки, а ?page= просто висят в индексе — это косметика.

Пагинация плюс фильтры: где рождается комбинаторика

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

Считается элементарно. Категория с двадцатью страницами пагинации, четырьмя сортировками и десятью брендами даёт 20 × 4 × 10 = 800 адресов. Добавьте размер и цвет — и счёт пойдёт на десятки тысяч. Все они отдают 200, все содержат почти одинаковые списки товаров.

Порядок решений здесь такой, от безопасного к рискованному:

Один нюанс из строки про открытый фильтр. Здесь canonical со второй страницы фильтра на первую страницу того же фильтра — исключение из правила «не канонизировать на первую». Оно оправдано тем, что посадочной страницей вы считаете именно фильтр, а его пагинация — техническое продолжение. Google этот canonical, скорее всего, тоже проигнорирует по той же причине («страница 2 не равна странице 1»), поэтому надёжнее noindex, follow.

Страница «показать все»: когда она имеет смысл

Раньше это была отдельная рекомендация Google — делать версию списка целиком и канонизировать пагинацию на неё. Сейчас отдельной поддержки нет, но идея не умерла, потому что в объявлении 2019 года прозвучало: «Studies show that users love single-page content, aim for that when possible».

Когда это работает: список умещается в разумный объём (условно до 200–300 позиций), страница грузится быстро, а разбиение на страницы существует только по привычке.

Когда не работает: каталог на тысячи товаров. Страница на пять мегабайт с двумя тысячами карточек убьёт LCP и мобильный опыт, и никакой выигрыш в индексации этого не окупит.

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

Класть ли страницы пагинации в sitemap

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

Аргумент за: sitemap — самый прямой способ показать роботу, что эти адреса существуют. Если пагинация реализована на JavaScript и ссылок в HTML нет, sitemap остаётся единственной дорогой. Google в разделе про бесконечную прокрутку именно это и советует как обходной путь.

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

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

У нас на блоге сейчас худший из вариантов: ссылки в HTML есть, и при этом 51 адрес лежит в карте сайта. Дублирование без пользы.

Текст категории на страницах пагинации

Мелочь, которая портит статистику дублей на ровном месте.

Описание категории на 1500–2500 знаков, выведенное на всех тридцати страницах пагинации, даёт тридцать документов с одинаковым текстовым блоком. У Foxtrot это видно в цифрах: 4235 слов на первой странице против 2953 на второй — разница как раз описание категории, которое выводится только на первой. У Epicentr разница меньше (4286 против 3680), но она тоже есть.

Правило простое: SEO-текст категории выводится только на первой странице. То же касается блока с ответами на вопросы, если он есть, и подборок «популярные бренды» — всего, что не является списком товаров.

Что должно отличаться на каждой странице:

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

Как проверить пагинацию на своём сайте

Набор проверок, который занимает минут пятнадцать и закрывает почти все сценарии.

Есть ли ссылки пагинации в сыром HTML

curl -s "https://site.ua/catalog/" \
  | grep -oE 'href="[^"]*(page|PAGEN|offset)[^"]*"' | sort -u | head -20

Пусто — переключатель рисуется скриптом, см. раздел про JavaScript.

Что с canonical и robots на второй странице

curl -s "https://site.ua/catalog/?page=2" \
  | grep -oE ']*canonical[^>]*>|]*robots[^>]*>'

Ожидаем canonical на ?page=2. Если видим адрес первой страницы — это ошибка из раздела выше.

Ограничено ли пространство адресов

for n in 2 50 500 9999; do
  printf "page=%-5s " "$n"
  curl -s -o /dev/null -w "%{http_code}\n" "https://site.ua/catalog/?page=$n"
done

За пределами реального списка ждём 404 или 301. Если везде 200 — пространство бесконечно.

Отличается ли содержимое страниц

for n in 1 2 3; do
  curl -s "https://site.ua/catalog/?page=$n" \
    | grep -oE 'href="/product/[^"]+"' | sort -u > p$n.txt
done
comm -12 p1.txt p2.txt | wc -l   # пересечение должно быть около нуля

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

Что смотреть в Search Console

• Отчёт «Страницы» → «Не проиндексированы». Категории «Копия: Google выбрал другую каноническую страницу» и «Обнаружена, не проиндексирована» — первые кандидаты на разбор.
• Статистика сканирования. Смотрим долю запросов к адресам с номером страницы. Если она сопоставима с долей запросов к карточкам — обход уходит не туда.
• Инструмент проверки URL на конкретной ?page=2: какой адрес Google считает каноническим для неё.

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

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

Способ находит именно те страницы, о существовании которых никто в команде не помнит.

Симптом → причина → как чинить

ТЗ программисту: что писать в задаче

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

1. Адреса. Каждая страница списка доступна по собственному адресу вида /catalog/?page=N или /catalog/page/N/ — формат на выбор, но единый по всему сайту. Первая страница доступна только по адресу без номера: ?page=1 отдаёт 301 на /catalog/.

2. Границы. Номер страницы больше числа реальных страниц отдаёт 404. Нечисловой или отрицательный номер отдаёт 404. Проверяется запросами ?page=9999, ?page=abc, ?page=-1.

3. Canonical. На каждой странице — canonical на саму себя с номером страницы. Параметры сортировки и отображения в canonical не попадают.

4. Мета-теги. Тайтл содержит номер страницы начиная со второй. Описание либо содержит номер, либо не выводится начиная со второй. H1 остаётся неизменным.

5. Содержимое. На странице N выводятся только товары этой страницы. Описание категории, блок вопросов-ответов и любые текстовые блоки выводятся только на первой странице.

6. Ссылки. Переключатель страниц выводится в HTML тегами <a href> до выполнения JavaScript. Проверяется просмотром исходного кода без выполнения скриптов.

7. Структурированные данные. Если на странице выводится ItemList, он содержит элементы только этой страницы, а не всего каталога.

8. Sitemap. В карту сайта попадает только первая страница каждого списка.

9. Комбинации. Адреса с номером страницы и параметрами сортировки или фильтров, не входящих в белый список, отдают noindex, follow.

10. Приёмка. Прикладывается вывод команд из раздела «Как проверить» по трём произвольным категориям.

Чек-лист

• У каждой страницы списка свой адрес, первая доступна без номера.
• Canonical каждой страницы указывает на саму себя.
• Номер за пределами списка отдаёт 404 или 301, а не 200.
• Ссылки пагинации присутствуют в HTML до выполнения скриптов.
• Содержимое страниц действительно разное — проверено сравнением списков товаров.
• Текст категории выводится только на первой странице.
• Тайтлы страниц со второй содержат номер.
• Разметка ItemList, если есть, пагинируется вместе со списком.
• В sitemap только первые страницы списков.
• Комбинации пагинации с сортировками и закрытыми фильтрами не индексируются.
• Пагинация не закрыта в robots.txt, если товары доступны только через неё.
• rel=next/prev не добавляется в новые шаблоны — Google их не использует с 2019 года.

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

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

Нужно ли закрывать страницы пагинации от индексации?

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

Ставить ли rel=next и rel=prev в 2026 году?

В новые шаблоны — нет. Google объявил об отказе от них 21 марта 2019 года и, как выяснилось тогда же, не использовал их ещё несколько лет до объявления. Если разметка уже стоит в старом шаблоне — снимать ради снятия не нужно, другие поисковики её читают.

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

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

Сколько товаров выводить на странице?

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

Стоит ли писать уникальные тексты для страниц пагинации?

Нет. Эти страницы не ранжируются — по нашим замерам они дают 0,04% трафиковых адресов, по замерам Гленна Гейба 0,3% кликов. Уникальный текст на тридцати страницах списка — это работа, которая не окупится ни при каком раскладе. Текст нужен первой странице категории, остальным — нет.

Как быть, если пагинация нужна и в фильтрах тоже?

Первая страница открытого фильтра — самостоятельная посадочная, её индексируем. Вторая и дальше — noindex, follow. Комбинации пагинации с сортировками не индексируем никогда: спроса на «страница 7, сортировка по цене» не существует.

Что важнее — починить пагинацию или заняться контентом?

Зависит от того, что именно сломано. Если товары со второй страницы не попадают в индекс — это блокер, и он важнее любого контента, потому что вы теряете ассортимент в выдаче. Если ?page= просто висят в индексе и не мешают карточкам индексироваться — это косметика, и она может подождать.