Пагінація в 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 на другій — опис категорії виводиться тільки на першій, і це правильно.

Епіцентр обрав протилежне — і зробив це послідовно. 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 закриває простір редиректом — правильно. Епіцентр віддає 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

Варіант Епіцентру виглядає грубо, але в нього є своя логіка, і у двох випадках він виправданий.

Випадок перший: каталог із сотнями сторінок в одній категорії. Якщо в категорії 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 на другій — різниця якраз опис категорії, який виводиться тільки на першій. В Епіцентру різниця менша (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= просто висять в індексі й не заважають карткам індексуватися — це косметика, і вона може зачекати.