Пагинация на сайте: что это и какой способ выбрать

Коротко: пагинация на сайте - показ длинного списка товаров, записей блога или отзывов частями с номерами страниц. Google описывает три способа показать список частями: разбивку на страницы, кнопку «Ещё» и бесконечную прокрутку. Способ выбирает заказчик; устройство ссылок и адресов он записывает в задание и проверяет при приёмке.

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

Примеры вымышленные: магазин чая с сайтом example.com. Страницы Google и Яндекса русские, страницы MDN и web.dev английские: после каждой английской цитаты стоит перевод, он не заменяет оригинал. Все страницы открыты 10.10.2026.

Что такое пагинация на сайте и где она встречается?

Коротко: в статье пагинация - ссылки «Далее», «Назад» и номера под списком. Русская версия справки Google называет такой способ «Разбивка на страницы» (в английской версии - Pagination) и перечисляет места, где список показывают частями.

Слова пагинация нет в русских страницах Google, разобранных ниже: там написано «разбивка на страницы». MDN использует слово pagination для блока номеров страниц:

"This cookbook pattern demonstrates the navigation pattern used to display pagination, where the user can move between pages of content such as search results."

• MDN, Pagination - CSS | MDN

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

Вопрос, как показать длинный список, шире блока с номерами. Справка Google называет его показом контента по частям и описывает три способа, они разобраны ниже. Места, где список делят частями, перечислены так:

Источник таблицы: Google, Рекомендации по разбивке контента на страницы | Центр Google Поиска | Documentation | Google for Developers, вводная часть. Там же сказано, что разбивка «удобна для показа не только результатов поиска, но и других элементов сайта».

Зачем список показывают по частям?

Коротко: справка называет четыре преимущества поэтапной загрузки: страница быстрее открывается, сокращается объём передаваемых данных, серверный код работает эффективнее, сайт надёжнее. К одному из трёх способов она их не привязывает.

Магазин чая из примера держит в разделе Чай example.com/catalog/tea/ 240 товаров. Показать их одной страницей или частями - решение, которое принимает владелец сайта. Преимущества частичного показа справка перечисляет так:

«Поэтапная загрузка контента имеет определенные преимущества: Страница быстрее открывается на устройстве пользователя, поскольку не нужно показывать сразу все материалы. Сокращается объем передаваемых данных (что особенно важно для мобильных устройств). Серверный код работает более эффективно за счет уменьшения объемов контента, получаемого из баз данных, и т. п. Повышается надежность сайта, поскольку составление слишком длинных списков может привести к исчерпанию ресурсов и, как следствие, ошибкам в браузере и серверных системах.»

• та же страница о разбивке, вводная часть

Серверный код - программа сайта, которая работает на сервере. База данных - хранилище, из которого сайт берёт список товаров. Третье преимущество связано с меньшим объёмом контента, получаемого из баз данных.

Какие три способа показа длинного списка описаны в справке?

Коротко: три способа - разбивка на страницы, кнопка «Ещё» и бесконечная прокрутка. В первом посетитель идёт по ссылкам, во втором нажимает кнопку, в третьем новые ссылки показываются по мере прокрутки.

Раздел «Как на сайте может быть реализован показ контента по частям» определяет способы так:

«Разбивка на страницы. Пользователь может переходить по ссылкам "Далее", "Назад" и по номерам страниц, на каждой из которых представлена определенная часть результатов поиска.»

«Кнопка "Ещё". Для того чтобы увидеть больше результатов, пользователю понадобится нажать кнопку.»

«Бесконечная прокрутка. Новые ссылки показываются по мере прокрутки страницы с результатами поиска.»

• та же страница о разбивке, раздел «Как на сайте может быть реализован показ контента по частям»

Русская версия справки - перевод английской. Название второго способа «Кнопка "Ещё"» в английской версии - Load more. Слова бесконечный скролл и кнопка показать ещё, которые могут встретиться в смете или макете, в справке Google не используются; по смыслу им соответствуют «Бесконечная прокрутка» и «Кнопка "Ещё"».

Как это выглядит в разделе Чай (наш пример; порция в 24 товара выбрана для наглядности, источники размер порции не называют):

• Разбивка: в окне 24 сорта, под ними ряд Назад 1 2 3 ... 10 Далее. Посетитель выбирает номер или идёт дальше по ссылке.
• Кнопка «Ещё»: те же 24 сорта, под последним кнопка Показать ещё. После нажатия ниже добавляются следующие, а общее количество результатов, по таблице справки, может стоять «на кнопке или возле нее».
• Бесконечная прокрутка: после 24 сортов ниже сами появляются следующие, пока посетитель листает раздел вниз.

Какие плюсы и минусы у трёх способов по таблице Google?

Коротко: плюсы и минусы способов даны только в таблице Google, ниже она перенесена словами справки. Минус о невозможности показывать большое количество результатов стоит у кнопки «Ещё» и у бесконечной прокрутки.

Лучший способ справка Google не называет, выбор она оставляет владельцу сайта:

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

• та же страница о разбивке

Каждая строка ниже - одно предложение из этой таблицы, оценок статьи в ней нет.

Таблица говорит о результатах, а в начале справка пишет, что разбивка удобна для показа не только результатов поиска, но и других элементов сайта (перечень - в разделе о том, где встречается пагинация).

Какие вопросы о списке следуют из строк таблицы?

Коротко: таблица не называет лучший способ, поэтому выбор начинается с вопросов владельца о собственном списке; пять вопросов ниже привязаны к строкам таблицы.

Вопросы задаются для каждого списка магазина чая: каталога, блога, комментариев, отзывов.

Что удобнее посетителям магазина, таблица не утверждает.

Что Google пишет о роботе и кнопках?

Коротко: Google пишет, что его роботы не нажимают кнопки и не активируют функции JavaScript, которые обновляют контент страницы в ответ на действия пользователей. Вопрос подрядчику: по каким ссылкам открываются товары, которые появляются после нажатия.

JavaScript - программный код в составе страницы, который работает в браузере посетителя. Элемент <a> с атрибутом href - ссылка, в которой записан адрес страницы. Раздел «Как Google индексирует контент при его разбивке на части» пишет об этом так:

«Функция "Ещё" и бесконечная прокрутка обычно реализуются с помощью JavaScript. Когда робот Google ищет на сайте страницы, которые нужно добавить в индекс, обычно он сканирует URL, обнаруженные в атрибуте href элементов <a>. Роботы Google не нажимают кнопки и не активируют функции JavaScript, призванные обновлять контент страницы в результате действий пользователей.»

• та же страница о разбивке, раздел «Как Google индексирует контент при его разбивке на части»

Для example.com ссылка ко второй части списка чая выглядит так:

<a href="https://example.com/catalog/tea?page=2">Далее</a>

Как сделать доступными по ссылкам товары за кнопкой «Ещё», справка не описывает. Это вопрос подрядчику, ответ записывается в задание. В том же разделе названо ещё одно средство для всех товаров сайта:

«Создайте файл Sitemap или фид Google Merchant Center, чтобы робот Google мог найти все товары на вашем сайте.»

• та же страница о разбивке, тот же раздел

Иерархия магазина (категории, подкатегории, товары) и товары, доступные только через поиск по сайту, разобраны в статье о структуре сайта; цепочка ссылок с местом страницы в иерархии - в статье о хлебных крошках.

Какие требования к ссылкам и адресам называет Google?

Коротко: пять требований к реализации: ссылки a href к следующей и к первой части списка, уникальный адрес у каждой части (пример - ?page=n), первая часть не назначается канонической, символ # в номерах не используется.

Требования собраны в таблицу. Правая колонка - наш пример для example.com.

Источник таблицы: та же страница о разбивке, разделы «Последовательные ссылки на страницы» и «Как правильно использовать URL».

Отдельным советом справка называет ускорение перехода между частями: «Если вы хотите сделать переход на следующую страницу более удобным для посетителя, используйте предзагрузку или упреждающий запрос.» Это пожелание к реализации, которое заказчик может обсудить с подрядчиком. О символе # справка пишет так: «Google игнорирует такие идентификаторы. Если наш робот обнаруживает ссылку на следующую страницу, которая отличается только текстом после символа #, он может не перейти по ней, приняв ее за уже отсканированную.»

О каноническом URL Google пишет в отдельной справке. Её первая фраза говорит о способах передать такой адрес Google, и аннотация link с атрибутом rel="canonical" названа одним из них:

«Есть несколько способов передать в Google Поиск канонический URL для одинаковых или очень похожих страниц.» «Аннотации link с атрибутом rel="canonical". Явный признак того, что указанный URL должен рассматриваться как канонический.»

• Google, Как указать канонический URL с помощью атрибута rel="canonical" и другими способами | Центр Google Поиска | Documentation | Google for Developers

Канонический URL - адрес, который указан Google как главный для одинаковых или очень похожих страниц.

Для адресов с фильтрами и сортировкой (пример Google - параметр ?order=price) справка советует:

«Чтобы наша система не добавляла варианты одного и того же списка страниц в индекс, запретите индексирование относящихся к ним URL при помощи метатега robots с директивой noindex или указав соответствующие шаблоны URL в файле robots.txt.»

• та же страница о разбивке, раздел «Почему рекомендуется запрещать индексирование URL при использовании фильтров или других методов сортировки»

Директива noindex в метатеге robots - способ запретить индексирование адреса, второй способ из цитаты - шаблоны в файле robots.txt. Метатег и файл robots.txt настраивает разработчик. Заказчик записывает в задание, что такие адреса закрыты.

Как сделать бесконечную прокрутку доступной по адресам?

Коротко: для бесконечной прокрутки справка называет пять рекомендаций: свой URL у сегмента, неизменное содержимое по адресу (пример - точный номер ?page=12), отказ от относительной адресации в URL, последовательную нумерацию и обновление адреса в браузере через History API.

Сегмент - порция списка, которая подгружается при прокрутке. В разделе «Обеспечьте поддержку постраничной загрузки для бесконечной прокрутки» названо условие:

«Чтобы страницу с бесконечной прокруткой можно было проиндексировать, убедитесь, что сайт поддерживает постраничную загрузку подобных сегментов.»

• Google, Устранение неполадок на страницах с отложенной загрузкой | Центр Google Поиска | Documentation | Google for Developers, раздел «Обеспечьте поддержку постраничной загрузки для бесконечной прокрутки»

Дальше идут рекомендации страницы, в кавычках её слова:

1. «Назначьте каждому сегменту уникальный собственный URL.»
2. «Контент, предназначенный для показа в браузере по каждому подобному URL, должен оставаться неизменным.» Как это сделать, страница подсказывает так: «Для этого можно использовать в URL точные номера страниц, например добавив параметр запроса ?page=12.»
3. «Не добавляйте в URL элементы относительной адресации, например ?date=yesterday для отбора вчерашних публикаций.» Адрес с yesterday отбирает вчерашние публикации: на следующий день тот же адрес покажет другой список.
4. «Назначьте имеющимся URL последовательные номера страниц (...)»
5. «Установите настройки так, чтобы в случаях, когда при прокрутке страницы появляется очередной сегмент и становится основным элементом на экране, обновление отображаемого URL выполнялось с помощью History API.» Результат: «Это позволит пользователям обновлять текущий URL, отображаемый в браузере, а также делиться им и ссылаться на него.»

Что такое History API, страница не объясняет. Из её слов следует, что адрес в строке браузера меняется, когда в окне появляется следующий сегмент. Для example.com при бесконечной прокрутке записей блога пятая порция должна открываться по адресу example.com/blog?page=5, и этим адресом можно поделиться.

Раздел о загрузке контента в области просмотра перечисляет варианты загрузки и пишет:

«Эти варианты предусматривают загрузку контента, не полагаясь на действия пользователей, такие как прокрутку и клики. Это важно, так как Google Поиск не взаимодействует с вашими страницами.»

• та же страница об отложенной загрузке, раздел «Загружайте контент, когда он находится в области просмотра»

Результат Google предлагает проверить инструментом: «С помощью инструмента проверки URL в Search Console можно узнать, был ли загружен весь контент.» Отложенная загрузка картинок и встроенных блоков iframe - другая тема, о ленивой загрузке iframe рассказывает статья о виджетах на сайте.

Что MDN пишет о блоке номеров страниц и о ленте?

Коротко: образец MDN размечает номера как список внутри элемента nav с подписью aria-label="pagination"; для ленты, которая подгружается при прокрутке, MDN описывает роль feed, требующую своей клавиатурной навигации.

Программа чтения с экрана читает содержимое страницы вслух. Раздел Requirements образца MDN объясняет, как сделать блок понятным для такой программы:

"To ensure that the pagination is understandable by people using a screen reader, we mark the items up as a list inside a <nav> element, and then use CSS to display the layout visually as a row."

• MDN, там же, раздел Requirements

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

Раздел Accessibility concerns добавляет два пояснения:

"We want to ensure that a person using a screen reader understands what this navigation does, and where they will go when clicking a link. To help with this we have added aria-label="pagination" on the <nav> element." "We have also added some additional content that would be read by a screen reader but is hidden visually, and set the aria-hidden attribute on the paging arrows."

• MDN, там же, раздел Accessibility concerns

Перевод наш: мы хотим, чтобы человек с программой чтения с экрана понимал, что делает эта навигация и куда он попадёт по ссылке. Для этого у элемента nav есть подпись aria-label="pagination". Мы также добавили текст, который программа прочитает, но который скрыт визуально, и задали атрибут aria-hidden у стрелок.

Разметка образца с той страницы (отступы строк сокращены, текст кода не менялся):

<nav aria-label="pagination">
 <ul class="pagination">
 <li>
 <a href="">
 <span aria-hidden="true">&laquo;</span>
 <span class="visuallyhidden">previous set of pages</span>
 </a>
 </li>
 <li>
 <a href=""><span class="visuallyhidden">page </span>1</a>
 </li>
 <li>
 <a href="" aria-current="page">
 <span class="visuallyhidden">page </span>2
 </a>
 </li>
 <li>
 <a href=""> <span class="visuallyhidden">page </span>3 </a>
 </li>
 <li>
 <a href=""> <span class="visuallyhidden">page </span>4 </a>
 </li>
 <li>
 <a href="">
 <span class="visuallyhidden">next set of pages</span
 ><span aria-hidden="true">&raquo;</span>
 </a>
 </li>
 </ul>
</nav>

В коде видны четыре детали, о которых заказчик может спросить подрядчика: блок nav с подписью aria-label, список из пунктов, скрытый визуально текст перед номером и атрибут aria-current="page" у ссылки на вторую страницу в примере. Страница MDN объясняет только первые три; назначение aria-current в разделе Accessibility concerns не описано. В примере MDN каждый номер - ссылка с атрибутом href, адреса в примере пустые (href="").

Для списка, который подгружается при прокрутке, MDN описывает отдельную роль feed:

"A feed is a dynamic scrollable list of articles in which articles are added to or removed from either end of the list as the user scrolls."

• MDN, ARIA: feed role - ARIA | MDN

Перевод наш: feed - динамический прокручиваемый список статей, в котором при прокрутке статьи добавляются или убираются с любого конца списка.

Примеры из раздела Description, среди них «a list of related products on an e-commerce page» (перевод наш: список связанных товаров на странице магазина). Условие реализации там же:

"Unlike the document structure elements that represent static HTML elements, the feed role requires specific interactions and implementation of keyboard navigation."

• MDN, там же, раздел Description

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

О размере ленты MDN пишет в разделе Description: "However, if the total number is extremely large, indefinite, or changes often, set aria-setsize="-1" to indicate that the size of the feed is not known." Перевод наш: если общее число очень велико, не определено или часто меняется, задайте aria-setsize="-1", чтобы показать, что размер ленты неизвестен. Нужна ли роль feed конкретному списку магазина, страница MDN не решает. Раздел Best practices этой страницы даёт три совета для ленты:

"To ensure good user experience, avoid inserting or removing articles in the middle of a feed, load new articles before the user has reached the end of the feed, and provide keyboard commands for moving focus among articles so that keyboard users can navigate through your feed."

• MDN, там же, раздел Best practices

Перевод наш: чтобы пользоваться лентой было удобно, не вставляйте и не удаляйте статьи в середине ленты, загружайте новые статьи до того, как пользователь дошёл до конца ленты, и предусмотрите клавиатурные команды для перемещения фокуса между статьями, чтобы пользователи клавиатуры могли ходить по ленте. Клавиши, которые страница советует поддержать, она перечисляет в разделе Keyboard interactions:

"Page Down: Move focus to next article." "Page Up: Move focus to previous article." "Control + End: Move focus to the first focusable element after the feed." "Control + Home: Move focus to the first focusable element before the feed."

• MDN, там же, раздел Keyboard interactions

Перевод наш: Page Down - перевести фокус к следующей статье; Page Up - к предыдущей; Control + End - к первому элементу после ленты, до которого можно дойти фокусом; Control + Home - к первому такому элементу перед лентой. Раздел начинается словами "Supporting the following, or a similar, interface is recommended when focus is inside the feed" (перевод наш: когда фокус внутри ленты, рекомендуется поддержать такой или похожий интерфейс). Там же сказано о ленте внутри ленты, и пример в этих словах совпадает с перечнем Google, где есть комментарии к записям блога:

"If a feed is nested within a feed, such as a comments feed within a feed of blog posts, the convention is to tab into the nested feed with the Tab key and to provide another key, such as Alt + Page Down, to navigate from an 'outer' article to the first item in that article's nested feed."

• MDN, там же, раздел Keyboard interactions

Перевод наш: если лента вложена в ленту, как лента комментариев внутри ленты записей блога, принято входить во вложенную ленту клавишей Tab и предусматривать другую клавишу, например Alt + Page Down, чтобы перейти от внешней статьи к первому элементу вложенной ленты этой статьи. Вопрос подрядчику: подключена ли роль feed у списка с бесконечной прокруткой и как в нём работают эти клавиши.

Что web.dev пишет о подгрузке по кнопке и сдвигах макета?

Коротко: web.dev называет один из приёмов для списков, которые дополняются по ходу чтения: загрузку запускает сам пользователь, например кнопкой "Load more". Сдвиги макета в пределах 500 миллисекунд после действия пользователя в метрику CLS не входят.

Сдвиг макета - ситуация, когда элементы страницы смещаются, пока человек её читает. Оценку таких сдвигов web.dev называет метрикой Cumulative Layout Shift (CLS) и описывает сам сдвиг так:

"Imagine you've started reading an article when all of a sudden elements shift around the page, throwing you off and requiring you to find your place again."

• web.dev, Optimize Cumulative Layout Shift | Articles | web.dev

Перевод наш: представьте, что вы начали читать статью, и вдруг элементы страницы сдвигаются, сбивая вас и заставляя искать своё место заново.

О сдвигах после загрузки, в том числе при прокрутке, страница пишет в разделе «Understand the causes of layout shifts» (перевод наш: разберитесь в причинах сдвигов макета):

"However, other post-load shifts that are unexpected by the user may be included where there was no qualifying interaction - for example, if you scroll further along the page and lazy-loaded content is loaded and that causes shifts."

• web.dev, там же, раздел «Understand the causes of layout shifts»

Перевод наш: сдвиги после загрузки, которых пользователь не ожидает, могут учитываться там, где не было подходящего действия, - например, если вы прокручиваете страницу дальше, лениво загружаемое содержимое подгружается и вызывает сдвиги.

Динамическое добавление содержимого страница иллюстрирует примером: подгрузка товаров в список. Раздел «Avoid inserting new content without a user interaction» (перевод наш: не вставляйте новое содержимое без действия пользователя) предлагает несколько способов избежать неожиданных сдвигов; один из них:

"Have the user initiate the load of new content, so they are not surprised by the shift (for example with a "Load more" or "Refresh" button). It's recommended to prefetch the content before the user interaction so that it shows up immediately. As a reminder, layout shifts that occur within 500 milliseconds of user input are not counted towards CLS."

• web.dev, там же, раздел «Avoid inserting new content without a user interaction»

Перевод наш: пусть пользователь сам запускает загрузку нового содержимого, чтобы сдвиг его не удивил (например, кнопкой "Load more" или "Refresh"). Рекомендуется заранее подгрузить содержимое, до действия пользователя, чтобы оно появилось сразу. Напомним: сдвиги макета в пределах 500 миллисекунд после действия пользователя в CLS не учитываются.

Два других приёма из того же раздела:

"Replace the old content with the new content within a fixed size container or use a carousel and remove the old content after the transition." "Seamlessly load the content offscreen and overlay a notice to the user that it's available (for example, with a "Scroll to top" button)."

• web.dev, там же, раздел «Avoid inserting new content without a user interaction»

Перевод наш: замените старое содержимое новым внутри контейнера фиксированного размера или используйте карусель и убирайте старое содержимое после перехода. Загружайте содержимое незаметно, за пределами экрана, и показывайте пользователю уведомление, что оно доступно (например, кнопкой "Scroll to top"). Страница web.dev написана о метрике сдвигов и плюсы и минусы трёх способов не сравнивает.

Чем расходятся Google и Яндекс Вебмастер в заголовках страниц списка?

Коротко: Google пишет, что для страниц списка можно использовать одно название и описание. Яндекс Вебмастер в справке о дублях советует при автоматических заголовках, например, добавить номер страницы. Это два отдельных утверждения двух источников.

Какое правило заложить в шаблон заголовков страниц списка, решают заказчик и подрядчик.

В русской версии слова «Для них» относятся к страницам с результатами поиска: «(...) эта рекомендация не касается страниц с результатами поиска». Справка Яндекса посвящена одинаковым заголовкам и описаниям; слов о списках и о разбивке в приведённом разделе нет. Правила Яндекса о списках здесь ограничены этой одной строкой.

Что записать в задание для каждого способа?

Коротко: таблица сводит для каждого способа плюс из таблицы справки и требования источников; правая колонка - формулировки статьи.

Как записать требование проверяемо, объясняет статья о техническом задании на сайт.

Что заказчику решить до дизайна и что проверить при приёмке?

Коротко: способ показа списка заказчик выбирает до дизайна, вместе с остальными вопросами о структуре сайта. На главной BITSPARK шаг «Структура» стоит перед шагом «Дизайн» и описан одной фразой, услуга «Интернет-магазин» - словами «каталог, корзина, оплаты и необходимые интеграции».

Главная страница BITSPARK описывает шаг «Структура» так:

«Собираем архитектуру: сценарии, страницы, контент и логику взаимодействия.»

• BITSPARK, BITSPARK - Digital studio, шаг «Структура»

Услуга «Интернет-магазин» там же: «От 55 000 ₽ - каталог, корзина, оплаты и необходимые интеграции.» Слов о способах показа списка в этих формулировках нет. Другие вопросы о структуре, которые заказчик решает до дизайна, собраны в статье о структуре сайта.

До дизайна заказчик решает пять вопросов: какие списки делятся на части (категории товаров, записи блога, отзывы, комментарии - по перечню Google); какой способ выбран для каждого списка; как записаны адреса, ссылки и канонический адрес частей; как закрыты адреса фильтров и сортировки; какое правило заложено для заголовков частей.

Что проверить при приёмке каталога example.com:

1. Откройте вторую часть списка чая: адрес отличается от адреса первой части и содержит номер (в справке - ?page=n, для прокрутки - ?page=12).
2. Откройте тот же адрес в новом окне: список должен совпасть. Для прокрутки Google пишет, что контент по такому URL должен «оставаться неизменным».
3. Попросите показать в коде ссылки <a href> к следующей и к первой части.
4. В номерах частей не должно быть символа #.
5. Спросите про канонический адрес части ?page=3. Google советует не использовать первую страницу «в качестве канонической».
6. При прокрутке дойдите до следующего сегмента и посмотрите на адресную строку: Google называет для этого History API.
7. При кнопке «Ещё» спросите, по каким ссылкам открываются товары после нажатия.
8. Попросите показать разметку блока номеров по образцу MDN: nav, aria-label, список, aria-current="page" у ссылки, как в примере.
9. Адрес с сортировкой ?order=price: спросите, чем он закрыт - метатегом robots с noindex или шаблоном в robots.txt.
10. Откройте список с телефона и проверьте блок номеров или кнопку; как проверять адаптив, разбирает статья об адаптивном сайте.
11. Если у сайта подключён Search Console, попросите результат проверки инструментом проверки URL и обработанный HTML-код страницы: Google пишет, что по нему можно убедиться «в наличии нужного контента».

Источники

Дата обращения к страницам: 10.10.2026. Русские страницы Google - перевод английских.

• Рекомендации по разбивке контента на страницы | Центр Google Поиска | Documentation | Google for Developers (обновлена 2025-12-18 UTC; английская версия - 2025-12-10 UTC).
• Устранение неполадок на страницах с отложенной загрузкой | Центр Google Поиска | Documentation | Google for Developers (обновлена 2025-12-18 UTC).
• Как указать канонический URL с помощью атрибута rel="canonical" и другими способами | Центр Google Поиска | Documentation | Google for Developers (обновлена 2026-07-14 UTC).
• Pagination - CSS | MDN (английский, изменена 7 ноября 2025 года).
• ARIA: feed role - ARIA | MDN (английский, изменена 23 июня 2025 года).
• Optimize Cumulative Layout Shift | Articles | web.dev (английский, обновлена 2025-02-07 UTC).
• Одинаковые заголовки и описания (дубли) | Вебмастер (дата обновления не указана).
• BITSPARK - Digital studio (текст главной страницы на 10.10.2026).

Обсудить проект в Telegram: t.me/billioniks