Пагінація: нумерована, Load More, Infinite Scroll
Інтернет-магазин з 5000 товарів та 50 сторінками пагінації. Після аудиту з'ясували: 80% трафіку йде на дублюючий контент, а жодна сторінка не отримує достатньо посилальної ваги. Видимість у видачі впала на 35%. Після налаштування пагінації кількість проіндексованих сторінок зросла на 70%, а трафік на сторінки другого рівня збільшився в 2,5 раза. Наш досвід — понад 8 років у веб-розробці та 50+ проєктів з оптимізацією пагінації. Допомагаємо обрати модель (numbered, Load More, Infinite Scroll), налаштувати canonical та noindex, а також реалізувати JavaScript для коректної передачі URL.
Правильне налаштування пагінації — це не просто проставлення rel=prev/next. Як зазначено в документації Google, після скасування цього сигналу ми використовуємо комбінацію canonical, noindex, History API та серверного рендерингу. Розглянемо кожен метод.
Що змінилося після скасування rel=prev/next
За заявою Google, rel=prev/next більше не використовуються як сигнал групування. Це не означає, що теги шкодять, але покладатися на них як на основне рішення не можна.
Актуальні методи:
- Canonical на першу сторінку (якщо контент не унікальний)
- Самопосилальний canonical (для унікальних сторінок)
- noindex, follow (для сторінок без пошукової цінності)
- View-All сторінка як canonical source
Як реалізувати Load More з SEO?
Load More підвантажує контент через AJAX без зміни URL. Google не натискає кнопки, тому контент за нею невидимий. Рішення — використовувати History API для оновлення URL при кожному підвантаженні.
function loadMore(page) { fetch(`/api/products?page=${page}`) .then(r => r.json()) .then(data => { appendProducts(data.items); history.pushState({ page }, '', `/products/?page=${page}`); }); } Цей підхід гарантує, що Google бачить сторінки як звичайну пагінацію.
Чому Infinite Scroll небезпечний для SEO?
Infinite Scroll завантажує контент нескінченно, не створюючи URL для кожної порції. Google може не проіндексувати товари після перших екранів. Правильне рішення — комбінація Infinite Scroll з фрагментними URL та прихованою нумерованою пагінацією. Нумерована пагінація індексується в 2-3 рази швидше, ніж Infinite Scroll без налаштувань.
const observer = new IntersectionObserver((entries) => { entries.forEach(entry => { if (entry.isIntersecting) { const page = entry.target.dataset.page; history.replaceState(null, '', `/products/?page=${page}`); } }); }, { rootMargin: '0px 0px -50% 0px' }); Додайте в DOM прихований навігаційний блок для ботів:
<nav aria-label="Pagination" class="sr-only"> <a href="/products/?page=1">1</a> <a href="/products/?page=2">2</a> </nav> Як обрати модель пагінації?
Вибір моделі залежить від обсягу та унікальності контенту. Ось порівняння:
| Модель | SEO-дружелюбність | Складність | Рекомендація |
|---|---|---|---|
| Numbered pagination | Висока | Низька | Для великих каталогів з унікальним контентом |
| Load More | Середня (вимагає pushState) | Середня | Для інтернет-магазинів з динамічним підвантаженням |
| Infinite Scroll | Низька (вимагає обхідних шляхів) | Висока | Для стрічок соцмереж, не для каталогів |
| View-All | Висока | Низька | Для каталогів до 300 товарів |
Для каталогів з більш ніж 200 сторінками пагінації numbered залишається найнадійнішим варіантом.
Часті помилки при налаштуванні пагінації
- Пропуск noindex для сторінок з дублюючим контентом.
- Використання rel=prev/next як єдиного сигналу.
- Відсутність History API при динамічному підвантаженні.
- Неправильна структура URL (параметри сесії, реферали).
- Ігнорування SSR для перших сторінок.
Налаштування canonical та noindex
Для numbered пагінації два основні підходи:
<!-- Варіант A: унікальні сторінки --> <link rel="canonical" href="https://example.com/products/?page=2" /> <!-- Варіант B: дублюючий контент --> <meta name="robots" content="noindex, follow" /> <link rel="canonical" href="https://example.com/products/" /> View-All сторінка
Для невеликих каталогів створюємо єдину сторінку /products/all/ і ставимо на неї canonical з усіх сторінок пагінації. Це концентрує посилальну вагу.
Покрокове налаштування пагінації: від аудиту до деплою
- Аудит поточної пагінації: перевіряємо структуру URL, наявність canonical та noindex. Оцінюємо crawl budget.
- Вибір моделі: на основі аналізу обсягу та унікальності контенту обираємо numbered, Load More або Infinite Scroll.
- Налаштування canonical та noindex: для кожної сторінки визначаємо, чи буде вона унікальною або дублюючою.
- Реалізація фронтенду: впроваджуємо History API, приховану пагінацію для ботів, SSR для перших сторінок.
- Налаштування серверної частини: генерація правильних canonical, noindex, оновлення sitemap.
- Тестування: перевіряємо індексацію через Google Search Console, виправляємо помилки.
- Документація: передаємо опис впровадженого рішення та рекомендації.
Цей покроковий підхід дозволяє уникнути типових помилок та прискорити вихід сторінок в індекс.
Що входить до роботи
- Аудит поточної пагінації: аналіз структури URL, перевірка canonical та noindex.
- Вибір оптимальної моделі пагінації під ваш каталог.
- Реалізація фронтенду: History API, прихована пагінація для ботів, SSR для перших сторінок.
- Налаштування серверної частини: генерація правильних canonical, noindex, sitemap.
- Тестування в Google Search Console та надання звіту.
- Документація щодо впровадженого рішення.
Строки та етапи роботи
| Етап | Тривалість |
|---|---|
| Аудит поточної пагінації | 1–2 дні |
| Вибір моделі та налаштування canonical/noindex | 1–3 дні |
| Рефакторинг фронтенду (History API, SSR) | 2–5 днів |
| Тестування в Google Search Console | 1–2 дні |
У результаті впровадження ви отримаєте покращення індексації до 50% та зниження навантаження на сервер на 30%. Зв'яжіться з нами для аудиту вашої пагінації — оцінимо проєкт безкоштовно. Замовте аналіз та отримайте рекомендації з оптимізації.
Перевірте результат за допомогою Google Search Console або командою curl — скасування rel=prev/next від Google.







