← Все статьи

SiteGuard12 мин чтения

Пагинация, «Показать ещё» и бесконечная прокрутка: как открыть каталог для поиска

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

Настройка пагинации для SEO начинается с проверяемого маршрута к каждому доступному товару: у частей каталога есть собственные адреса, они открываются напрямую и связаны обычными ссылками. Интерфейс может сохранять подгрузку без перезагрузки. Важно, чтобы она дополняла доступную структуру каталога. Ниже — порядок проектирования и проверки такой структуры для владельца сайта и разработчика, с учебным расчётом охвата товаров.

Определите, какие товары должны быть обнаружены

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

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

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

Результат первого этапа — конкретный список ожидаемых URL и описание пути к ним. Формулировка «каталог индексируется» слишком общая: первая страница может быть доступна, а товары после неё фактически изолированы.

Ссылка должна содержать адрес следующей части

Руководство Google по доступным для обхода ссылкам рекомендует элемент <a> с атрибутом href, содержащим настоящий URL. Обработчик клика на произвольном элементе не равнозначен такой ссылке. JavaScript может добавлять ссылки, если итоговая разметка сохраняет корректную структуру.

Условный фрагмент навигации категории:

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

Пример предполагает, что пользователь находится на второй странице, а третья существует. Значения формируются по реальному состоянию каталога. На последней странице не должно оставаться активной ссылки на несуществующую следующую часть.

Проверьте адрес через копирование ссылки и открытие в новой вкладке. Если вместо него получается #, команда JavaScript или пустое значение, навигация зависит от поведения интерфейса. Добавить атрибут с красивым, но неработающим адресом тоже недостаточно: сервер должен обслуживать этот URL.

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

Дайте каждой части самостоятельный URL

Адрес должен однозначно выбирать часть каталога. Подойдёт согласованный параметр вроде ?page=3 или другой устойчивый маршрут, если приложение действительно использует его при получении содержимого. Номер в адресной строке не должен быть декоративной подписью к состоянию, которое существует только в памяти браузера.

Документация Google по структуре URL не рекомендует фрагменты после # для изменения основного содержимого. Адреса /catalog/lamps#page=2 и /catalog/lamps#page=3 не стоит использовать как единственный способ представить разные документы каталога для поиска.

Опишите контракт первой страницы: какой адрес считается основным и что делает вариант с явным номером 1. Затем согласуйте правила для второй и последующих страниц, недопустимого значения, последней части и номера за границей списка. Это устраняет случайные различия между шаблоном, API и маршрутизатором.

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

Прямое открытие должно показывать нужную страницу

Скопируйте адрес третьей части и откройте его отдельно. Должны загрузиться товары третьей части, название категории и понятная навигация. Повторите перезагрузку. Если сайт возвращает первый набор, пустой экран или просит сначала нажать кнопку несколько раз, URL не выполняет свой контракт.

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

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

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

Если разные адреса неожиданно показывают одинаковые товары, сравните фактический параметр запроса с ответом приложения и кеша. Например, интерфейс может отправлять номер страницы, но промежуточный слой учитывать только путь категории. Тогда переходы меняют URL, а содержимое остаётся первым набором. Проверка трёх заранее известных карточек из разных частей помогает быстро заметить такую подмену без предположений о том, какой слой виноват.

Сохраните «Показать ещё» как улучшение навигации

Удобная реализация может сочетать обычные страницы и добавление следующей порции в текущий список. Базовая ссылка ведёт на самостоятельный URL. JavaScript перехватывает действие только при возможности загрузить данные и корректно добавить карточки. При отказе улучшения остаётся понятный путь к следующей странице.

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

Для посетителя отдельно спроектируйте возврат назад и восстановление позиции. Если после просмотра товара браузер возвращает в начало огромного списка, технически доступная пагинация всё равно работает неудобно. При изменении отображаемого URL через History API прямое открытие этого адреса должно восстанавливать соответствующую часть.

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

Проверьте порядок и изменение каталога

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

Учебный пример: в первой порции 24 товара, во второй — следующие 24. Пока пользователь смотрел первую, в начало списка добавили новую позицию. Если вторая порция выбирается простым смещением, последний товар первой порции может встретиться повторно. При удалении записи возможен обратный эффект — пропуск.

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

Курсорная схема может быть полезна для приложения, однако публичная навигация всё равно нуждается в адресах с понятным сроком действия и прямым открытием. Не заменяйте постоянные страницы одноразовыми курсорами без проверки поискового сценария. Для первоначального теста полноты используйте фиксированный набор данных, затем отдельно проверьте добавление и удаление товаров между переходами.

Устойчивый адрес не требует навсегда заморозить ассортимент. Он должен обозначать предсказуемую часть выбранной категории, а не случайный набор, зависящий от предыдущих кликов. Изменение опубликованных товаров — нормальное событие, которое учитывается в правилах обновления. Для отчёта о проверке фиксируйте время и условия выдачи, включая выбранный регион, если он меняет доступный ассортимент. Иначе два корректных снимка легко принять за пропуск.

Настройте canonical по смыслу каждой страницы

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

В учебной схеме страница /catalog/lamps?page=3 указывает своим canonical тот же самостоятельный адрес. При этом дубли одного и того же представления нормализуются по отдельному договору. Например, вариант первой страницы с лишним параметром не требует создания ещё одной содержательно одинаковой точки входа.

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

Google также больше не использует rel="next" и rel="prev" как прежний сигнал связи страниц пагинации. Их наличие не заменяет переходы через обычные ссылки. Не считайте добавление этих тегов достаточным результатом исправления, если до товаров следующих частей по-прежнему невозможно дойти.

Не закрывайте продолжение каталога по шаблонному правилу

Совет «оставить в поиске только первую страницу, остальные поставить noindex» требует оценки конкретной структуры. Если продолжение содержит единственные ссылки на часть ассортимента, сначала нужно понять последствия для обнаружения карточек и проверить другие пути к ним. Номер страницы сам по себе не определяет её полезность.

Правило noindex исключает страницу из результатов Google после обработки соответствующей инструкции. Чтобы прочитать её, робот должен иметь доступ к странице; блокировка в robots.txt не является взаимозаменяемым способом сообщить noindex.

Не смешивайте задачи: canonical выбирает предпочтительный вариант среди представлений, а noindex управляет участием страницы в поиске. Ни один из механизмов не создаёт отсутствующую ссылку на товар. Решение об исключении отдельных страниц принимают после проверки их содержимого и роли в навигации.

В этой проверке достаточно отделить обычную последовательность каталога от альтернативных представлений. Настройка большого набора фильтров и сортировок требует отдельного разбора. Сначала обеспечьте работоспособность базового пути: категория, последовательные части, карточки. Иначе дополнительные ограничения затруднят поиск исходной проблемы.

Последняя страница и несуществующий номер — разные состояния

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

Если запрошенная часть действительно не существует, сервер должен сообщить об этом корректным статусом, например 404. Не возвращайте для любого огромного номера пустой шаблон со статусом 200. В документации Google по HTTP-статусам описано, что пустое содержимое или сообщение об ошибке с успешным статусом может распознаваться как soft 404.

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

Отдельно обработайте временный отказ источника данных. Ошибка получения товаров не доказывает, что категория или часть списка исчезла. В интерфейсе подгрузки такой отказ также не должен маскироваться под последнюю страницу. Для существующей, но временно пустой категории правило выбирают по её назначению, а не механически копируют поведение номера за диапазоном.

Посчитайте охват на фиксированном учебном каталоге

Возьмём условную категорию из 143 опубликованных товаров без исключений. Размер страницы — 24 позиции, порядок зафиксирован на время теста. Пять полных страниц содержат 120 товаров, остаток составляет 23. Значит, ожидаются шесть страниц.

СтраницаПозиции в фиксированном спискеКоличество
11–2424
225–4824
349–7224
473–9624
597–12024
6121–14323

Соберите идентификаторы или нормализованные URL карточек со всех шести страниц. Сравните их объединение с исходным ожидаемым набором. Простая сумма карточек недостаточна: если среди 143 показанных позиций две повторяют уже встреченные товары, уникальных карточек может оказаться только 141.

Условие приёмки для этого опыта: получены все 143 ожидаемых идентификатора, лишних нет, повторов нет, каждый URL карточки корректно открывается. Седьмая страница не существует, а шестая не создаёт на неё активный переход.

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

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

Проверьте представление страницы для Google

После локальной проверки выберите первую, среднюю и последнюю части, а также контрольную карточку, которая раньше находилась только после подгрузки. В инструменте проверки URL Search Console можно исследовать доступность страницы, полученный код, ресурсы и результат рендеринга. Смотрите наличие конкретных товарных ссылок, а не только общий скриншот категории.

Различайте проверку текущего URL и сведения об уже обработанной версии. Данные индекса могут относиться к предыдущему обходу. Успешный live test не гарантирует включения в индекс и не предсказывает окончательный выбор канонической страницы; эти ограничения прямо указаны в документации инструмента.

Для технического отчёта сохраните адрес, время, статус ответа, обнаруженные ссылки и проблемный шаг. Например: «страница 4 доступна напрямую, но в отрисованном документе нет ссылки на страницу 5». Такое описание даёт разработчику проверяемую задачу.

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

Согласуйте критерии приёмки каталога

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

  • Все части имеют самостоятельные адреса и корректно открываются после перезагрузки.
  • Между ними есть обычные ссылки, а карточки товаров также содержат доступные URL.
  • Подгрузка улучшает интерфейс и сохраняет путь к содержимому при отказе сценария.
  • Canonical соответствует выбранной странице; случайные noindex и запреты не закрывают нужный путь.
  • Последняя часть, неверный номер и временная ошибка данных обрабатываются раздельно.
  • Сверка уникальных товаров подтверждает ожидаемый охват на тестовом наборе.
  • Проверка отрисованной страницы подтверждает наличие контрольных ссылок.

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

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