Как Google индексирует страницы с бесконечной прокруткой

Google не следует рассматривать как пользователя, который прокручивает главную страницу до конца, чтобы открыть следующую порцию новостей. Если новые материалы появляются только после действия пользователя, полагаться на такую прокрутку для их обнаружения нельзя. Googlebot умеет выполнять JavaScript, но не стоит рассчитывать, что он последовательно прокрутит страницу до самого конца и загрузит весь архив.

В описанной схеме есть дополнительная проблема:

https://site.ru/#page=2 https://site.ru/#page=3

Часть URL после символа # — это fragment identifier. Для пагинации такой вариант использовать не следует. URL:

https://site.ru/ https://site.ru/#page=2 https://site.ru/#page=3

не образуют нормальную последовательность отдельных страниц пагинации для Google.

Сам JavaScript Google выполнять умеет. При рендеринге страницы может загрузиться часть контента, который появляется динамически. Но это не надёжный способ обхода бесконечной ленты. Нельзя рассчитывать, что робот последовательно прокрутит десятки или сотни экранов и таким способом найдёт весь архив материалов.

Правильная схема — оставить бесконечную прокрутку для пользователя, но технически построить под ней обычную пагинацию с отдельными URL.

Например:

https://site.ru/ https://site.ru/?page=2 https://site.ru/?page=3 https://site.ru/?page=4

или:

https://site.ru/ https://site.ru/page/2/ https://site.ru/page/3/ https://site.ru/page/4/

Каждый такой URL должен открываться напрямую без предварительного посещения первой страницы и возвращать соответствующую порцию материалов с HTTP 200.

Между страницами должны существовать обычные ссылки через <a href>. Например, со второй страницы должна быть доступна третья:

<a href="/?page=3">Следующая страница</a>

Именно такие ссылки дают Googlebot нормальный путь обхода. Наличие JavaScript-функции, которая при достижении низа страницы запрашивает следующую порцию материалов, само по себе этого не заменяет.

При этом интерфейс для пользователя менять необязательно. Человек может продолжать просто прокручивать новости. Когда JavaScript загружает очередной блок, URL в адресной строке можно менять через History API:

https://site.ru/?page=2

затем:

https://site.ru/?page=3

При прямом открытии каждого такого URL сайт должен показывать соответствующий участок списка.

Для пагинации также не стоит ставить canonical со всех ?page=2, ?page=3 и последующих страниц на главную. Если страницы пагинации нужны Google для обхода архива, они должны существовать как самостоятельные доступные URL.

Для СМИ есть ещё один нюанс: задача обычно состоит не в том, чтобы каждая страница пагинации обязательно попала в индекс и ранжировалась, а в том, чтобы Googlebot через неё находил ссылки на старые статьи. Поэтому пагинация прежде всего должна оставаться доступным маршрутом обхода архива.

XML Sitemap стоит использовать как дополнительный канал обнаружения самих статей, особенно на крупном сайте, но sitemap не заменяет нормальную внутреннюю структуру ссылок. Статья не должна становиться практически недоступной для робота после того, как её вытеснили с главной новые публикации.

Если архив постоянно растёт, полезно также иметь устойчивую структуру архива — например, страницы по датам, месяцам или рубрикам. Это уменьшает зависимость обнаружения старой новости от её текущей позиции в бесконечной ленте.

После внедрения нужно проверять не сам факт работы прокрутки, а доступность отдельных URL для Google. Откройте ?page=2 или /page/2/ напрямую, убедитесь, что страница возвращает HTTP 200 и содержит ссылки на статьи этого блока. Затем аналогично проверьте более глубокие страницы. В серверных логах можно дополнительно посмотреть, запрашивает ли Googlebot URL пагинации.

Рабочая архитектура здесь простая: infinite scroll остаётся интерфейсом для пользователя, а для поискового робота под ним существует обычная последовательность отдельных URL с реальными <a href>-ссылками. Вариант #page=2 для этой задачи использовать не нужно.