Каталог на 50 000 товаров, а в индексе поисковиков – 3000. Знакомая картина? Чаще всего причина не в качестве контента, а в том, как реализована навигация по страницам категорий.
Пагинация и бесконечный скролл – одна из тем, на которой я видел больше всего потерянного трафика у e-commerce проектов.
Я Пётр Гришечкин, последние 15 лет проектирую системы кратного роста трафика для крупных сайтов. Делюсь разными разборами в своём канале.
Почему способ навигации определяет объём индексации
Пагинация и бесконечный скролл решают одну задачу – показать пользователю большой объём контента. Но поисковые роботы воспринимают эти подходы принципиально по-разному.
Googlebot и робот Яндекса заходят на URL, забирают HTML-ответ сервера и парсят ссылки. Они не прокручивают страницу вниз. Не кликают кнопку «Показать ещё». Не ждут, пока сработает IntersectionObserver.
Результат: если контент подгружается только при скролле через JavaScript, робот видит только первый экран. На практике это означает потерю до 90% контента из индекса. Для интернет-магазина с глубокими категориями это прямой удар по видимости и трафику.
Проблемы бесконечного скролла с точки зрения SEO
Бесконечный скролл (контент подгружается автоматически при прокрутке) удобен для пользователя, но токсичен для краулинга по нескольким причинам:
Нет уникальных URL. Весь контент живёт на одном адресе. Роботу некуда переходить – он видит только первую порцию данных.
JavaScript-зависимость. Googlebot рендерит JS, но делает это в отложенной очереди. Время ожидания – от нескольких часов до нескольких недель. Яндекс рендерит JS ещё менее предсказуемо.
Отсутствие ссылочных путей. Если в DOM нет HTML-ссылок на следующие «страницы», робот физически не может до них добраться.
Раздувание DOM. При длительном скролле в память попадают сотни элементов. Это бьёт по Core Web Vitals – растёт CLS (смещение макета при подгрузке), ухудшается отзывчивость страницы.
Техническая реализация пагинации для краулинга
Каждая страница пагинации должна быть самостоятельным ресурсом. Вот конкретные требования.
URL-структура
Используйте чистые, предсказуемые адреса:
/category/?page=2 /category/page/2/
Избегайте хеш-фрагментов (#page2) – они не передаются на сервер и невидимы для краулера.
HTML-ссылки пагинации
Блок навигации с ссылками <a href="/category/?page=3">3</a> должен присутствовать в HTML всех версий страницы – десктопной и мобильной. Не скрывайте его через display: none и не удаляйте из DOM при инициализации JS.
rel=“prev” и rel=“next”
Google в 2019 году объявил, что больше не использует эти теги как сигнал индексации. Однако Яндекс по-прежнему их учитывает. Если Ваш проект ориентирован на русскоязычную аудиторию, добавляйте:
<link rel="prev" href="https://site.com/category/?page=1" /> <link rel="next" href="https://site.com/category/?page=3" />
Это занимает минуту, а для Яндекса остаётся полезным сигналом.
rel=“canonical” – на себя, не на первую страницу
Критически важный момент. Каждая страница пагинации должна указывать каноникал на саму себя:
<link rel="canonical" href="https://site.com/category/?page=2" />
Если вы укажете canonical всех страниц на первую – поисковик проигнорирует остальные. Товары со страниц 2, 3, 10, 50 выпадут из индекса.
Индексировать страницы 2+ или закрыть?
Здесь два рабочих сценария. Выбор зависит от стратегии.
Открыть всё для индексации, если:
на каждой странице уникальный набор товаров/статей,
вы хотите максимальный охват длиннохвостовых запросов,
каталог большой (тысячи позиций).
Закрыть страницы 2+ через noindex, если:
контент на страницах пагинации незначительно отличается,
каталог маленький, и весь трафик идёт на первую страницу,
вы хотите сконцентрировать краулинговый бюджет.
При этом не закрывайте страницы через robots.txt – робот не увидит директиву noindex на заблокированной странице и может всё равно проиндексировать URL.
Метаданные: уникальные Title и Description
Одинаковые заголовки на всех страницах пагинации – прямой путь к каннибализации ключевых слов (когда несколько Ваших страниц конкурируют в выдаче за один запрос).
Формула простая. Добавляйте номер страницы:
Title: Ноутбуки в каталоге – страница 2 | МагазинX Description: Смотрите ноутбуки 21–40 из 380. Бесплатная доставка, гарантия.
Это занимает минимум усилий на бэкенде, но снимает проблему дублей.
Как сделать бесконечный скролл SEO-friendly
Если отказаться от бесконечного скролла нельзя – сделайте его «двойным»: для пользователя – скролл, для робота – пагинация.
Реализация через History API
Суть подхода: при подгрузке каждой порции контента вы обновляете URL в адресной строке через pushState. Краулер, зайдя на любой из этих URL, получает соответствующую порцию контента в HTML.
// Фронтенд: при подгрузке блока товаров function loadNextPage(pageNumber) { fetch(`/api/products?page=${pageNumber}`) .then(res => res.json()) .then(data => { renderProducts(data.items); window.history.pushState( { page: pageNumber }, '', `/category/?page=${pageNumber}` ); }); }
Бэкенд: серверный рендеринг каждой страницы
Каждый URL вида /category/?page=N должен возвращать полноценный HTML с контентом именно этой страницы. Если краулер зайдёт на /category/?page=5 и получит пустой шаблон, ожидающий JS, – контент потерян.
Ссылки пагинации остаются в DOM
Даже при активном бесконечном скролле не убирайте из HTML блок <nav> с ссылками на страницы. Это основной механизм, через который Googlebot находит все страницы.
Проверка: как убедиться, что всё работает
Реализовали – проверяйте. Вот конкретный чеклист:
Google Search Console → Проверка URL. Вставьте адрес
/category/?page=5. Посмотрите, видит ли Google контент на этой странице.Яндекс.Вебмастер → Проверка ответа сервера. Аналогичная проверка для Яндекса.
Screaming Frog. Запустите краулинг сайта. Убедитесь, что все страницы пагинации обнаружены и возвращают 200. Проверьте, что Title и canonical уникальны.
Логи сервера. Отфильтруйте запросы от Googlebot и Yandexbot. Посмотрите, заходят ли они на страницы 2, 3, 10+. Если нет – ссылочные пути не работают.
Отключите JS в браузере и откройте страницу категории. Если контент пропал – краулер его тоже не увидит.
Частые ошибки разработчиков
За годы аудитов я видел одни и те же проблемы. Вот топ-6:
Ошибка | Почему проблема | Как исправить |
|---|---|---|
Ссылки пагинации удалены из HTML | Краулер не находит страницы 2+ | Вернуть |
Контент только через JS без серверного fallback | Робот видит пустую страницу | SSR или pre-rendering для каждого URL |
Одинаковые Title на всех страницах | Каннибализация ключевых слов | Добавить номер страницы в Title и Description |
canonical всех страниц на первую | Страницы 2+ выпадают из индекса | canonical на саму себя |
Нет fallback при отключённом JS | Потеря контента для краулеров | Серверный рендеринг основного контента |
Параметры фильтров не обработаны | Взрывной рост дублей | Настроить canonical или параметры в Search Console |
Миграция между схемами без потери позиций
Если вы переходите с бесконечного скролла на пагинацию (или меняете URL-структуру), действуйте поэтапно:
Составьте маппинг старых URL на новые.
Настройте 301-редиректы со старых адресов.
Обновите внутренние ссылки и sitemap.xml.
Проверьте в Search Console, что новые URL корректно обрабатываются.
Мониторьте индексацию 2–4 недели – именно столько по опыту занимает полный перекраул крупного каталога.
Не делайте миграцию одним коммитом в пятницу вечером. Разделите на этапы и отслеживайте метрики после каждого.
Вывод
Оптимизация пагинации и бесконечного скролла для поисковиков – это не теоретическое упражнение, а прямой рычаг увеличения индексируемого контента. Если из 5 000 товаров в индексе 300 – проблема почти наверняка в навигации.
Первый шаг прямо сейчас: откройте Google Search Console, проверьте URL /category/?page=5 и посмотрите, что видит робот. Если пустую страницу – у Вас есть конкретная задача на ближайший спринт.
Больше подобных разборов – в телеграм-канале.
FAQ
Может ли Гугл индексировать JavaScript-подгрузку контента при скролле?
Googlebot использует headless Chromium и теоретически может рендерить JS. Но он не прокручивает страницу и не триггерит события скролла. Контент, привязанный к scroll или IntersectionObserver, робот не увидит. Рассчитывайте на то, что робот получает только то, что отрендерилось при начальной загрузке без взаимодействия.
Стоит ли использовать кнопку «Загрузить ещё» вместо бесконечного скролла?
С точки зрения UX – это промежуточный вариант. Но для SEO проблема та же: если кнопка работает через JS без обновления URL и без серверного fallback, робот не доберётся до контента. Кнопка безопасна только при реализации через History API с полноценными серверными страницами за каждым URL.
Нужен ли sitemap.xml для страниц пагинации?
Если страницы пагинации открыты для индексации – да, добавьте их в sitemap. Это дополнительный сигнал краулеру. Но sitemap не заменяет внутренние HTML-ссылки. Робот должен находить страницы и через навигацию, и через карту сайта.
Как быть с фильтрами и сортировкой в сочетании с пагинацией?
Фильтры и сортировка генерируют параметрические URL, которые могут создать тысячи дублей. Решение: определите, какие комбинации фильтров имеют поисковый спрос и должны индексироваться. Остальные закройте через canonical на «чистый» URL категории без параметров, либо используйте noindex. В Google Search Console можно также указать обработку параметров URL.
Влияет ли пагинация на Core Web Vitals?
Классическая пагинация обычно лучше для Web Vitals, чем бесконечный скролл. При скролле DOM растёт с каждой подгрузкой – это увеличивает потребление памяти и может вызывать layout shifts (CLS). Пагинация загружает фиксированный объём контента, что проще оптимизировать по LCP и CLS.
