Оптимизация Pagination SEO (rel=prev/next, Load More, Infinite Scroll)
Пагинация — один из самых недооценённых источников SEO-проблем. На каталоге с 50 страницами пагинации поисковик тратит crawl budget на сотни страниц с дублирующимся контентом, при этом ни одна из них не получает достаточно ссылочного веса для попадания в топ. Правильная настройка пагинации — это выбор модели (numbered pagination, Load More, Infinite Scroll), корректная сигнализация поисковику, и сохранение UX для пользователя.
Что изменилось после отмены rel=prev/next
В 2019 году Google официально объявил, что перестал использовать rel="prev" и rel="next" как сигнал для группировки страниц. Это не значит, что эти теги стали вредить — просто полагаться на них как на решение проблемы пагинации больше нельзя.
Актуальные методы:
- Canonical на первую страницу (если страницы пагинации не несут уникального контента)
- Самоссылочный canonical на каждой странице пагинации (если контент уникален и нужна индексация)
- Параметр в robots.txt / GSC для исключения страниц пагинации из индекса
- View-all страница как canonical source
Numbered Pagination: базовая настройка
Самый распространённый случай. Каталог /products/?page=2, /products/?page=3 и так далее.
Вариант A: индексируемые страницы пагинации
Используется когда страницы пагинации могут ранжироваться сами по себе — например, в каталоге с тысячами товаров, где страница 2 содержит уникальные товары.
<!-- На /products/?page=2 -->
<link rel="canonical" href="https://example.com/products/?page=2" />
Каждая страница ссылается сама на себя. Уникальный <title> и <h1>:
<title>Каталог смартфонов — страница 2 | Магазин</title>
<meta name="description" content="Страница 2 каталога смартфонов. 48 моделей от 5 000 ₽." />
Вариант B: все страницы пагинации → canonical на первую
Для информационных разделов, блогов, архивов — где страница 2 не имеет отдельной поисковой ценности:
<!-- На /blog/?page=3 -->
<link rel="canonical" href="https://example.com/blog/" />
Но: если на страницах пагинации нет ссылок в sitemap и они не ранжируются по каким-либо запросам — noindex будет чище:
<meta name="robots" content="noindex, follow" />
follow важен: роботу нужно перейти по ссылкам на этих страницах, чтобы обнаружить товары/статьи.
URL-структура:
Предпочтительна path-based пагинация (/products/page/2/) перед query-string (/products/?page=2) — лучше воспринимается краулерами и проще в настройке canonical. Оба варианта работают, но надо быть последовательным.
В nginx:
# Нормализация: /products?page=1 → /products/
if ($arg_page = "1") {
return 301 $uri;
}
Load More: SEO без пагинации в URL
Кнопка «Загрузить ещё» подгружает следующую порцию контента через AJAX, не меняя URL. С точки зрения SEO — Google видит только то, что есть в исходном HTML при первой загрузке страницы, плюс то, что отображается после JavaScript-рендеринга.
Проблема: Google рендерит JavaScript, но с задержкой. Кнопка «Ещё» никогда не нажмётся автоматически ботом — весь контент за ней невидим без дополнительных мер.
Решение 1: History API + pushState
При клике на «Загрузить ещё» меняем URL в браузере:
function loadMore(page) {
fetch(`/api/products?page=${page}`)
.then(r => r.json())
.then(data => {
appendProducts(data.items);
history.pushState(
{ page },
'',
`/products/?page=${page}`
);
});
}
Теперь при скролле пользователь видит URL /products/?page=2, который Google умеет краулить как обычную пагинацию.
Решение 2: SSR/SSG начального контента + динамическая подгрузка
Первые N товаров рендерятся на сервере. Остальные — через JS. Google проиндексирует первую порцию гарантированно:
<!-- В HTML: первые 24 товара статично -->
<div id="product-grid">
<!-- серверный рендер 24 товаров -->
</div>
<button id="load-more" data-page="2">Загрузить ещё</button>
Infinite Scroll: совместимость с SEO
Infinite Scroll — худший вариант для SEO по умолчанию. Всё, что загружается ниже видимой области, Google не гарантирует проиндексировать.
Правильная реализация: Infinite Scroll + фрагментные URL
При пересечении порога прокрутки (Intersection Observer) меняем URL:
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' });
document.querySelectorAll('[data-page-sentinel]').forEach(el => {
observer.observe(el);
});
Каждый «экран» пагинации помечен sentinel-элементом. При скролле URL обновляется — пользователь может скопировать ссылку на нужную «страницу».
SEO-компромисс для Infinite Scroll:
Добавить в footer или в отдельный <nav> стандартную нумерованную пагинацию, скрытую через CSS для пользователей, но видимую поисковику:
<nav aria-label="Pagination" class="sr-only">
<a href="/products/?page=1">1</a>
<a href="/products/?page=2">2</a>
<!-- ... -->
</nav>
sr-only (screen-reader-only) в Tailwind или Bootstrap — элемент визуально скрыт, но присутствует в DOM. Google следует по ссылкам.
View-All страница
Для небольших каталогов (до 200–300 товаров) оптимальна единая страница /products/all/ со всеми товарами. На неё ставится canonical со всех страниц пагинации, она получает весь ссылочный вес.
<!-- На /products/?page=2, /products/?page=3 и т.д. -->
<link rel="canonical" href="https://example.com/products/all/" />
Если страница «все товары» слишком тяжёлая — оптимизируем: lazy load изображений, виртуальный скролл на клиенте.
Проверка результата
# Проверить, что страницы пагинации не индексируются (если выбран noindex)
curl -s "https://example.com/products/?page=5" | grep -i 'canonical\|noindex'
# Рендеринг JS через Googlebot-эмулятор
npx puppeteer-core --url "https://example.com/products/" --js-enabled true
Инструмент проверки в GSC: URL Inspection для конкретных страниц пагинации. Смотрим: canonical определён верно, noindex применён (если задуман), ссылки обнаружены.
Сроки
Аудит текущей пагинации + рекомендации — 1–2 дня. Техническая реализация выбранной модели (настройка canonical/noindex, рефакторинг JS для Load More или Infinite Scroll) — 3–6 дней в зависимости от стека и сложности фронтенда.