Страницы пагинации не индексируются: современные стратегии пагинации для Google
Google отказался от rel=prev/next, и Ваш пагинированный контент выпал из индекса. Изучите современные стратегии пагинации, работающие с текущим поведением индексации Google.
В этой инструкции
Пагинация повсюду в интернете. Архивы блогов, страницы категорий в e-commerce, страницы результатов поиска, индексы веток форумов, новостные архивы и галереи изображений — все они используют пагинацию, чтобы разбить большие наборы контента на удобные страницы. Долгие годы стандартом было реализовывать теги rel=prev и rel=next, говорящие Google, что набор страниц образует пагинированную серию. Google понимал связь и соответствующим образом консолидировал сигналы индексации.
В марте 2019 года Google подтвердил, что уже несколько лет не использует rel=prev/next как сигнал индексации. Это объявление застало индустрию SEO врасплох, поскольку многие сайты построили всю стратегию пагинации вокруг этих тегов. Практические последствия проявились сразу: без rel=prev/next Google трактует каждую страницу пагинации как самостоятельную, а не как часть связанной серии.
Это изменение означает, что страница 2 архива Вашего блога оценивается Google полностью по её собственным заслугам. Если страница 2 показывает список отрывков записей без уникального вступительного контента, без уникального заголовка и без контекста, объясняющего, о чём страница, Google видит тонкую страницу с переиспользованными фрагментами. Неудивительно, что Google часто решает не индексировать такие страницы.
Последствия выходят за пределы самих пагинированных страниц. Контент, появляющийся только на глубоких страницах пагинации, становится для Google труднее обнаружить. Если продукт или запись блога не вынесены на страницу 1 ни одного листинга и ни откуда больше не ссылаются, они фактически становятся осиротевшими, и Google может никогда их не просканировать. Это превращает пагинацию из проблемы листинговых страниц в проблему обнаружения контента всего сайта.
Это руководство охватывает современные стратегии пагинации, работающие с текущим поведением индексации Google, затрагивает специфические сложности infinite scroll и Load More и даёт конкретные исправления для возврата контента, потерянного, когда rel=prev/next перестали работать.
Что изменилось, когда Google отменил rel=prev/next
Чтобы понять текущее состояние индексации пагинации, полезно знать, что rel=prev/next должны были делать и что Google делает сейчас.
rel=prev/next — это набор HTML-элементов link, сообщавших Google, что серия страниц связана как пагинированная последовательность. Замысел был в том, чтобы Google консолидировал страницы и понимал, что страница 1, страница 2, страница 3 и так далее образуют непрерывный набор. В теории Google трактовал серию как единое логическое целое, консолидировал ссылочный вес и, возможно, показывал в результатах только первую страницу, понимая, что контент продолжается на последующих.
Когда Google раскрыл, что не использовал эти сигналы годами, импликация была ясна: Google полагался на другие сигналы для понимания пагинации. Среди них — шаблоны URL (Google умеет распознавать привычные шаблоны вроде ?page=2 или /page/2/), структуры внутренних ссылок (последовательные ссылки между страницами намекают на пагинацию) и анализ контента (страницы с одинаковыми шаблонами и разными наборами контента указывают на пагинированный список).
Практическое изменение в поведении в том, что Google теперь оценивает каждую пагинированную страницу независимо. Страница 1 категории с уникальным вступительным абзацем, сильными внутренними ссылками и 20 рекомендуемыми товарами может быть проиндексирована. Страница 2, показывающая следующие 20 товаров без уникального контента, оценивается как самостоятельная и может не быть проиндексирована, потому что сама по себе не предлагает достаточной уникальной ценности.
Такая независимая оценка означает, что страницы пагинации после первой редко индексируются, если у них нет какого-то уникального ценностного предложения. Перечисленные на странице 2 элементы отличаются от страницы 1, но шаблон, навигация, мета-информация и общая структура идентичны. С точки зрения Google страница 2 — тонкая вариация страницы 1.
Потеря консолидации rel=prev/next также означает, что ссылочный вес больше не объединяется между страницами пагинации. Раньше бэклинк, указывающий на страницу 3 Вашей категории, мог бы помочь всей пагинированной серии. Теперь этот вес остаётся только на странице 3. Если страница 3 не проиндексирована, ссылочный вес фактически растрачивается.
Текущая рекомендация Google по пагинации — обеспечить, чтобы важные отдельные страницы контента (товары, статьи, записи) напрямую ссылались из карты сайта и других страниц сайта, а не зависели от пагинации как единственного пути обнаружения. Пагинация теперь — прежде всего функция UX, а не SEO.
Infinite scroll: проблема невидимого контента
Infinite scroll заменяет традиционную пагинацию шаблоном, в котором новый контент подгружается автоматически по мере прокрутки. Пользователь получает бесшовную, бесконечную ленту. С точки зрения SEO infinite scroll — один из самых проблемных шаблонов пагинации, потому что краулер Google не прокручивает.
Когда Googlebot загружает страницу с infinite scroll, он обрабатывает исходный HTML и любой контент, отрисованный JavaScript-ом при первой загрузке. Он не запускает события прокрутки, поэтому любой контент, подгружаемый, когда пользователь прокручивает мимо определённого порога, полностью невидим для Google. Если Ваша страница категории показывает 20 товаров при загрузке и подгружает оставшиеся 200 через infinite scroll, Google увидит только 20.
Последствия для обнаружения контента серьёзны. Товары или записи, появляющиеся только через infinite scroll, не имеют пути сканирования со страницы категории. Если они не связаны с других страниц и не включены в карту сайта, Google может их никогда не найти. Даже при наличии в карте сайта сама страница категории не даёт им внутренней ссылки, ослабляя их воспринимаемую важность.
Рекомендуемое исправление — реализовать infinite scroll параллельно с традиционными пагинированными URL. Такой гибрид даёт пользователям плавный UX infinite scroll, а Google — сканируемые страницы пагинации с реальными URL. Реализация выглядит так: создайте традиционные URL пагинации (/category/page/2/, /category/page/3/), отображающие те же наборы контента, что и каждый сегмент infinite scroll. Когда пользователь прокручивает и подгружается новый контент, используйте History API для обновления URL браузера на соответствующий URL пагинации. При обновлении или поделившейся ссылке пользователь увидит пагинированную версию с контентом, до которого долистал.
Google специально рекомендует подход с pushState для infinite scroll. URL пагинации служат якорями, которые Google может сканировать, а infinite scroll даёт ожидаемый посетителями UX. Без подлежащих URL пагинации infinite scroll полностью скрывает от Google весь контент за пределами первого видимого набора.
Альтернативный подход для небольших наборов — загружать весь контент на одной странице без пагинации и подгрузок по прокрутке. Если в категории не больше 50 товаров, рендеринг всех на одной странице полностью устраняет проблему пагинации. Для категорий с сотнями или тысячами элементов такой подход непригоден из-за производительности, но для меньших коллекций работает хорошо.
Кнопки Load More: лучше infinite scroll, но всё ещё проблематично
Кнопки Load More — компромисс между традиционной пагинацией и infinite scroll. Пользователь видит начальный набор контента и нажимает кнопку, чтобы подгрузить дополнительный контент на ту же страницу. С точки зрения UX Load More часто предпочтительнее традиционной пагинации, потому что пользователь остаётся на той же странице и сохраняется позиция прокрутки.
Однако у Load More та же фундаментальная SEO-проблема, что и у infinite scroll: Google не нажимает кнопки. Контент, подгружаемый кнопкой Load More, запускается событием клика, а рендерер Google не имитирует клики. Контент за кнопкой Load More невидим для Google, если не предприняты специальные меры.
Исправление зеркалит решение для infinite scroll: реализовать традиционные URL пагинации параллельно с функцией Load More. Каждый сегмент Load More должен соответствовать сканируемому URL пагинации. Включите ссылки на эти URL где-то в HTML (их можно скрыть от визуального дизайна через CSS), чтобы Google мог их обнаружить и сканировать. Некоторые реализации помещают пагинационные ссылки в тег noscript, чтобы они были доступны краулерам без JavaScript, а кнопка Load More появлялась для браузеров с JavaScript.
Другой подход — рендерить контент Load More в исходном HTML-ответе, но скрывать визуально через CSS. Когда пользователь нажимает Load More, JavaScript раскрывает скрытый контент, а не запрашивает его с сервера. Так Google видит весь контент в исходном HTML без необходимости взаимодействия с кнопками. Однако это работает только для умеренных объёмов скрытого контента (загрузка 200 товаров в скрытом HTML значительно увеличивает вес страницы и время загрузки).
Третий подход — реализовать Load More с прогрессивной загрузкой пагинированных URL. Исходная страница загружается с первым набором контента и кнопкой Load More. Клик по кнопке через AJAX подгружает и отображает следующий набор и одновременно обновляет URL на следующую страницу пагинации (/page/2/). Каждый URL пагинации рендерит свой набор контента на сервере, так что Google может сканировать /page/2/ напрямую и видеть этот контент без нажатия кнопок. Кнопка Load More — прогрессивное улучшение для пользователей, а подлежащая структура URL пагинации — сканируемая основа для Google.
Стратегия канонических тегов для серий пагинации
Канонические теги на пагинированных страницах — одна из самых обсуждаемых тем технического SEO. Вопрос в том, должны ли страница 2, страница 3 и последующие иметь canonical, указывающий на страницу 1, или у каждой страницы должен быть самореферентный canonical.
Указание всех пагинированных страниц на страницу 1 как канонического говорит Google, что страница 1 — определяющая версия, а остальные — вторичные. Этот подход уместен, когда Вы не хотите или не нуждаетесь в индексации глубоких страниц и когда все отдельные элементы обнаруживаемы другими путями (карта сайта, прямые ссылки). Плюс — простота: Google индексирует только страницу 1, а Вы не беспокоитесь о тонком контенте на глубоких страницах. Риск — элементы, появляющиеся только на глубоких страницах, могут потерять сигналы внутренних ссылок от пагинированных листингов.
Самореферентные canonical на каждой пагинированной странице говорят Google, что каждая страница — отдельная сущность. Этот подход уместен, когда каждая пагинированная страница таргетирует другой контент или когда Вы хотите, чтобы Google индексировал все страницы серии. Плюс — каждая страница сохраняет свой ссылочный вес и может появляться в результатах поиска. Риск — Google может счесть глубокие страницы тонким контентом и не проиндексировать их вне зависимости от настроек.
Прагматичная рекомендация для большинства сайтов — гибридный подход. Страница 1 получает самореферентный canonical и Ваши усилия по оптимизации (уникальный вступительный контент, корректные мета-теги, рекомендуемые элементы). Страницы 2–5 получают самореферентные canonical, но рассматриваются как вторичные (более низкий приоритет оптимизации, готовность к тому, что часть из них не будет проиндексирована). Страницы 6 и далее получают canonical, указывающий на страницу 1, поскольку контент такой глубины маловероятно проиндексируется по собственным заслугам, а бюджет сканирования лучше потратить в другом месте.
Независимо от стратегии канонизации убедитесь, что каждая отдельная страница элемента (товара, записи, статьи) включена в XML-карту сайта с прямым URL. Карта сайта даёт независимый путь обнаружения, не зависящий от пагинации. Даже если Google никогда не проиндексирует страницу 7 категории, товары на странице 7 могут быть найдены и проиндексированы через карту сайта.
Влияние глубокой пагинации на бюджет сканирования
Глубокая пагинация, когда листинг контента растягивается на десятки или сотни страниц, — один из самых значительных потребителей бюджета сканирования на контентных сайтах. Каждая пагинированная страница — это URL, который Google может попытаться просканировать, оценить и потенциально проиндексировать. Сайт со 100 категориями, каждая с 20 страницами пагинации, генерирует 2000 URL листингов плюс собственно URL отдельного контента.
Планировщик сканирования Google должен решить, как распределить ограниченные ресурсы между всеми этими URL. Когда листинговые страницы пагинации превосходят по количеству реальные страницы контента, Google может тратить большую часть бюджета на листинги, а не на тот контент, который Вы хотите видеть в индексе. Это особенно проблема для e-commerce, где страницы товаров генерируют выручку, а Google тратит время на сканирование и повторное сканирование пагинации категорий.
Диагностический сигнал растраты бюджета сканирования на пагинацию — в статистике сканирования Google Search Console. Если Вы видите большой объём просканированных страниц при низкой доле проиндексированных, виноватой может быть избыточная пагинация. Выгрузите URL, которые Google сканирует чаще всего, и проверьте, какая доля приходится на пагинированные листинги, а какая — на реальный контент.
Несколько стратегий снижают воздействие глубокой пагинации на бюджет сканирования. Во-первых, ограничьте глубину сканируемой пагинации. Используйте robots.txt, чтобы блокировать сканирование пагинации после определённой глубины (например, блокируйте /page/6/ и глубже). Или добавляйте теги noindex,follow на глубокие страницы, чтобы Google их не индексировал, но мог переходить по ссылкам к отдельным элементам. Во-вторых, увеличьте число элементов на странице, чтобы уменьшить общую глубину пагинации. Показ 50 элементов вместо 20 превращает 20-страничную категорию в 8-страничную. В-третьих, реализуйте страницу View All там, где вес страницы позволяет, полностью устраняя пагинацию.
Для динамичной пагинации, которая часто меняется (новые товары ежедневно, перетасовываемые тренды), держите карту сайта основным механизмом обнаружения, а не полагайтесь на пагинацию. Карта сайта даёт полный список всех URL отдельного контента, который Google может сканировать в своём темпе, независимо от того, как эти URL появляются в пагинированных листингах в конкретный день.
Ещё одна техника — приоритизировать бюджет сканирования на страницу 1 каждой категории, усиливая внутренние ссылки на неё и ослабляя ссылки на более глубокие страницы. Навигация сайта ведёт на страницу 1 каждой категории. Внутренние ссылки из записей блога и других материалов — на страницу 1. Секции рекомендуемых товаров или записей на главной — на страницу 1. Эти сильные внутренние ссылки сигнализируют Google, что страница 1 — самый приоритетный URL листинга для каждой категории.
Пошаговое руководство
Проведите аудит текущей реализации пагинации по всему сайту
Просканируйте сайт и выявите все шаблоны URL пагинации. Частые шаблоны: /page/2/, ?page=2, /p2, ?start=20. Подсчитайте общее число URL пагинированных листингов против URL реальных страниц контента. Проверьте, какие пагинированные страницы сейчас в индексе, оператором «site:» с шаблонами пагинации. Определите, у каких категорий или разделов самая глубокая пагинация. Документируйте текущие настройки канонических тегов, правила robots.txt и статус noindex для пагинированных страниц. Этот базовый аудит показывает масштаб проблемы пагинации и направляет приоритизацию.
Проверьте пути обнаружения контента помимо пагинации
Убедитесь, что каждая отдельная страница контента (товар, статья, запись) обнаруживаема хотя бы одним путём помимо пагинации. Проверьте, что все URL контента есть в XML-карте сайта. Удостоверьтесь, что страницы контента получают внутренние ссылки от других материалов (блоки похожих товаров, похожих записей). Проведите анализ осиротевших страниц — найдите страницы контента, доступные только через глубокую пагинацию и не имеющие других внутренних ссылок. Для осиротевших добавляйте внутренние ссылки из связанных страниц или подборок, создавая альтернативные пути обнаружения.
Внедрите сканируемые URL для infinite scroll или Load More
Если на сайте используется infinite scroll или Load More, реализуйте подлежащие URL пагинации, соответствующие каждому сегменту контента. С помощью History API обновляйте URL в браузере по мере прокрутки или нажатий Load More. Убедитесь, что каждый URL пагинации рендерит свой контент на сервере без необходимости взаимодействия с JavaScript. Проверьте, прямо обращаясь к /page/2/ в браузере, отображается ли правильный набор контента. Включите эти URL пагинации в HTML (как пагинационные ссылки в подвале или в блоке noscript), чтобы Google мог их обнаружить без выполнения JavaScript.
Настройте канонические теги на пагинированных страницах
Реализуйте выбранную стратегию канонизации. Для большинства сайтов используйте самореферентные canonical на страницах 1–5 и canonical, указывающий на страницу 1, для страниц 6 и далее. Проверьте canonical, просматривая исходный код пагинированных страниц на разных глубинах. Убедитесь, что URL в canonical используют правильный протокол (HTTPS) и формат домена (с www или без, соответствующий Вашему предпочтительному формату). Если CMS генерирует canonical автоматически, проверьте корректность автоматических тегов на пагинированных страницах: некоторые CMS ошибочно делают самореферентные canonical на всех страницах пагинации независимо от глубины.
Оптимизируйте страницу 1 каждой пагинированной серии
Поскольку страница 1 — самая вероятная к индексации, инвестируйте в то, чтобы сделать её максимально сильной. Добавьте уникальный вступительный контент (описание категории, гайд по покупке, обзор темы), который появляется только на странице 1. Обеспечьте странице 1 уникальный, оптимизированный по ключевым словам title и meta description. Выводите самые важные элементы на страницу 1 ручной кураторкой или алгоритмами сортировки. Добавьте микроразметку (ItemList schema) на страницу 1, чтобы помочь Google понимать формат листинга. Усиливайте внутренние ссылки на страницу 1 из навигации, хлебных крошек и страниц контента.
Контролируйте бюджет сканирования глубокой пагинации
Внедряйте контроль бюджета сканирования для глубокой пагинации. Добавляйте теги noindex,follow на страницы пагинации глубже пятой (или выбранного Вами порога). Это позволяет Google переходить по ссылкам глубоких страниц для обнаружения отдельных элементов, но не пускает сами глубокие страницы в индексное квоту. Для очень глубокой пагинации (страница 20 и далее) рассмотрите добавление правил disallow в robots.txt, чтобы полностью запретить сканирование, полагаясь на карту сайта для обнаружения контента глубже этого порога. После внедрения контроля отслеживайте статистику сканирования в Search Console, чтобы убедиться, что бюджет смещается от листинговых страниц к страницам контента.
Отправьте ключевые пагинированные страницы и отдельный контент на индексацию
После реализации исправлений пагинации отправьте страницу 1 каждой важной категории или раздела через инструмент «Проверка URL» в Google Search Console. Для отдельных страниц контента, ранее обнаружимых только через глубокую пагинацию, отправляйте их через IndexBolt, чтобы Google проиндексировал их независимо от позиции в пагинации. Отслеживайте индексацию как листинговых страниц, так и отдельных страниц контента в течение последующих недель. Если страницы контента остаются непроиндексированными, несмотря на наличие в карте сайта и прямые внутренние ссылки, выясняйте, нет ли у них проблем качества или техники вне контекста пагинации.
Частые проблемы и способы их решения
Товары/записи на странице 2 и далее не индексируются, хотя элементы со страницы 1 проиндексированы
Причина: Элементы на странице 1 получают сильные сигналы внутренних ссылок со страницы категории (которая сама хорошо связана из навигации). Элементы на глубоких страницах получают более слабые сигналы, потому что у самих пагинированных страниц меньше авторитета и их сканируют реже. К тому же, если страницы пагинации после первой не проиндексированы, Google находит элементы на них реже, чем элементы на странице 1.
Решение: Убедитесь, что все URL отдельных страниц контента есть в XML-карте сайта, давая путь обнаружения независимо от пагинации. Добавляйте внутренние ссылки на важные элементы из непагинационных контекстов: блоки похожих товаров, упоминания в записях блога, рекомендуемые элементы на главной и виджеты кросс-продаж. Рассмотрите ротацию рекомендуемых элементов, чтобы со временем на странице 1 появлялись разные товары. Используйте IndexBolt, чтобы отправлять URL отдельных элементов, застрявших на глубоких страницах и не индексирующихся органически.
На сайте с infinite scroll проиндексирована только первая партия элементов
Причина: Google не умеет прокручивать, поэтому ему видны только элементы, отрисованные при исходной загрузке страницы. Элементы, подгружаемые JavaScript-запросами по прокрутке, невидимы. Без подлежащих URL пагинации у Google нет способа добраться до контента за пределами первой видимой партии. Элементы после первой загрузки фактически не существуют с точки зрения Google.
Решение: Реализуйте URL пагинации параллельно с infinite scroll через подход pushState из History API. Каждый сегмент прокрутки должен соответствовать сканируемому URL пагинации. Включите пагинационные навигационные ссылки в HTML, чтобы Google мог по ним переходить. Удостоверьтесь, что каждый URL пагинации рендерит свой набор контента на сервере. После реализации отправьте URL пагинации через IndexBolt или Search Console, чтобы ускорить обнаружение Google новой структуры URL.
Все пагинированные страницы помечены в Search Console как «Дубликат, Google выбрал другой канонический»
Причина: Google трактует пагинированные страницы как дубликаты друг друга или страницы 1. Это случается, когда у пагинированных страниц идентичные title, идентичные meta description, идентичный вступительный контент и различия только в перечисленных элементах. Google видит их вариациями одной страницы, а не разными страницами, и выбирает одну (обычно страницу 1) как каноническую.
Решение: Если Вы хотите, чтобы пагинированные страницы индексировались независимо, дифференцируйте их. Добавляйте номера страниц в title («Беговые кроссовки — страница 2 из 8»). Создавайте уникальные meta description для каждой пагинированной страницы или вообще убирайте meta description со страниц 2 и далее, чтобы Google генерировал их из контента. Показывайте вступительный контент только на странице 1. Если глубокие страницы Вам в индексе не нужны, явно указывайте canonical на странице 2 и далее, ведущий на страницу 1, и смиритесь с тем, что в индексе будет только страница 1.
Контент за кнопкой Load More со временем исчезает из индекса Google
Причина: Контент за кнопками Load More, ранее доступный через альтернативные пути (старая карта сайта, прямые ссылки), может терять индексацию по мере переоценки сайта Google. Если контент Load More недоступен без JavaScript-взаимодействия, а альтернативные пути больше не поддерживаются, у Google нет текущего способа добраться до контента, и он может деиндексировать ранее проиндексированные элементы, существование которых больше не может подтвердить.
Решение: Внедрите серверно-рендерящиеся URL пагинации, которые Google может сканировать напрямую. Убедитесь, что эти URL есть в карте сайта и ссылаются из HTML листинговой страницы. Проверьте, что отключение JavaScript всё ещё даёт доступ ко всему контенту через URL пагинации. После исправлений отправьте затронутые URL элементов через IndexBolt, чтобы восстановить индексацию ранее деиндексированного контента.
Советы профи
Пагинация не должна определять, попадёт ли Ваш контент в индекс. IndexBolt отправляет URL отдельных страниц контента напрямую в Google, полностью обходя путь обнаружения через пагинацию. Будь Ваши товары на странице 1 или 50 — IndexBolt гарантирует индексацию каждой. Отправьте полный список URL контента и позвольте каждой странице попасть в Google независимо от позиции в пагинации.
100 бесплатных кредитов. Без банковской карты. Результаты менее чем за 24 часа.
Часто задаваемые вопросы
Поддерживает ли Google rel=prev/next хоть как-то?+
Нет. Google подтвердил в марте 2019 года, что несколько лет не использует rel=prev/next как сигнал ранжирования или индексации. Наличие этих тегов в HTML вреда не причиняет, но и пользы для Google не даёт. Другие поисковики (Bing) могут их по-прежнему использовать, так что сохранять их не повредит, но полагаться на них для индексации в Google нельзя. Стратегия пагинации для Google должна строиться на канонических тегах, директивах noindex, включении в карту сайта и качестве контента, а не на сигналах rel=prev/next.
Создавать ли страницу View All вместо пагинации?+
Страница View All, перечисляющая все элементы на одной странице, — самое простое решение для Google, потому что полностью устраняет пагинацию. Google заявлял, что в целом предпочитает View All, когда это технически возможно. Однако View All практичны только для небольших наборов (до 100 элементов). Для категорий с сотнями или тысячами товаров View All была бы слишком медленной для загрузки, слишком ресурсоёмкой для рендеринга и слишком перегружающей пользователей. Для больших наборов используйте гибрид традиционной пагинации с полноценной XML-картой сайта.
Насколько глубоко позволять Google сканировать пагинацию?+
Универсального ответа нет, но практичный ориентир — разрешать индексацию первых трёх–пяти страниц и применять noindex (с follow) к более глубоким. Точный порог зависит от качества пагинированных страниц и бюджета сканирования сайта. Если сайт обладает сильным авторитетом и Google активно сканирует, можно разрешать большую глубину. Если бюджет ограничен, ограничьтесь индексацией только страницы 1 и полагайтесь на карту сайта для обнаружения контента. Ключевая метрика — действительно ли более глубокие страницы пагинации генерируют показы в поиске. Проверьте Search Console: получают ли URL страниц 5 и далее показы. Если нет, noindex для них экономит бюджет сканирования без потери трафика.
Мой infinite scroll использует AJAX для загрузки контента. Видит ли Google AJAX-контент?+
Google умеет рендерить контент, загружаемый JavaScript-ом, включая AJAX-ответы, но только если загрузка запускается исходным рендером страницы, а не пользовательским взаимодействием (прокруткой, кликом). AJAX-контент, загружающийся автоматически при загрузке страницы, виден Google. AJAX-контент, загружающийся в ответ на событие прокрутки, — нет, потому что рендерер Google не прокручивает. Если infinite scroll запускает AJAX-запросы по позиции прокрутки, такой контент невидим для Google. Реализуйте подлежащие URL пагинации с серверным рендерингом как основу, а опыт infinite scroll с AJAX наслаивайте сверху для пользователей.
Имеет ли порядок элементов в пагинации значение для SEO?+
Порядок имеет значение прежде всего потому, что элементы на странице 1 получают существенно больше внимания при сканировании и веса от внутренних ссылок, чем элементы на глубоких страницах. Google с большей вероятностью просканирует и проиндексирует контент страницы 1, чем страницы 10. Если есть высокоприоритетные элементы, которые Вы хотите видеть в индексе и в выдаче, обеспечьте их попадание на страницу 1 ручной курацией, закреплением или алгоритмами сортировки, выносящими важные элементы первыми. Для e-commerce сортировка по бестселлерам, рейтингу или новинкам естественно выводит самые релевантные товары на страницу 1. Избегайте случайной сортировки, меняющейся при каждой загрузке: Google трудно оценивать страницы с непостоянным контентом.
Стоит ли добавлять уникальный контент на каждую страницу пагинации, чтобы они индексировались?+
Добавление уникального контента на каждую страницу пагинации для большинства сайтов непрактично и не нужно. Сфокусируйте усилия по оптимизации на странице 1, которая с наибольшей вероятностью будет проиндексирована и важнее всего для поискового трафика. Для страниц 2–5 достаточно дифференцированных title с номерами страниц. Для глубоких страниц применяйте noindex и не беспокойтесь об уникальном контенте. Отдельные элементы, перечисленные на этих страницах, должны иметь свой уникальный контент по собственным URL. Страница пагинационного листинга — механизм навигации, а не конечная точка контента. Инвестируйте усилия по созданию контента в отдельные элементы, а не в листинговые страницы.