Куда-то ушли времена, когда пагинация настраивалась парой строк: проставил rel next и rel prev в head, и поисковик понимал, что страницы под номерами один, два и три - одна серия. В марте 2019 года Google перестал опираться на эти атрибуты, позже убрал их из документации. Но пагинация никуда не делась: категории магазинов, архивы блогов и ленты отзывов по-прежнему разбиты на страницы, и вопрос, как отдать их роботу, не устаревает. Разберём, что Google реально поддерживает в 2026 году, что показал живой эксперимент с обходом цепочек и когда архиву выгоднее переехать на единую страницу. Отдельно пройдёмся по ошибкам, которые кочуют из старых руководств и обходятся сайтам потерянными страницами.
Март 2019 года и что осталось от rel prev next в поиске
Отказ Google был тихим: система объявила, что больше не использует rel prev и rel next для целей индексации, потому что научилась понимать серии страниц сама - по обычным ссылкам, каноникам и структуре адресов. Страницы документации, описывавшие связку атрибутов, позже исчезли совсем, а свежий свод рекомендаций по пагинации и поэтапной загрузке контента не упоминает rel-атрибуты ни словом. Для вебмастера это значит простое: держать разметку ради Google смысла нет.
История у атрибутов длинная: Google представил поддержку rel prev next в 2011 году, и почти восемь лет они связывали серии страниц, позволяя системе собирать сигналы со всей цепочки. После отказа страницы серии индексируются каждая по себе: ссылки внутри работают, контент читается, но старой консолидации на первую страницу больше нет.
Не спешите выбрасывать теги из шаблонов ради остальных систем. Бинг публично признавался, что использует rel prev next как подсказку для обнаружения страниц и понимания структуры сайта, а в свежих разборах пагинации для Яндекса эти атрибуты тоже не считаются рабочим сигналом - упор там делается на обычные обходные ссылки и чистые адреса. Итог честный: теги безвредны, для Бинга отчасти полезны, но строить на них обнаружение контента в 2026 году нельзя.
Отказ почти никто не заметил на практике: система уже давно разбирала серии без атрибутов, и трафик большинства проектов не дрогнул. Новости разнесли рассылки и форумы быстрее, чем смена успела повлиять на выдачу. Для истории остаётся ирония: атрибуты прожили в документации восемь лет и исчезли так же тихо, как появились, без предупреждений и планов миграции.
Живой эксперимент 2025 года и выводы про обход цепочек страниц
В апреле 2025 года команда проверила на практике, как Google находит продолжение списка. На свежем слабом домене выложили страницы и связали их двумя способами: обычными видимыми ссылками в тегах a и атрибутами link rel next в head. Дальше наблюдали логи.
Результат красноречив. Страницу, на которую вела только ссылка rel next, Googlebot за все месяцы наблюдения не запросил ни разу. Адреса, на которые стояли обычные видимые ссылки, робот в итоге обошёл - но на слабом домене это заняло больше шести недель и несколько дополнительных вмешательств вроде добавления sitemap. Заодно эксперимент показал, что страницу с метой noindex и атрибутом nofollow робот продолжал запрашивать неделями, и что favicon робот-картинок запрашивает десятки раз чаще любого другого файла. Вывод для практики: робота двигают по каталогу обычные ссылки, а разметка в head с этой задачей больше не справляется. Для сильных доменов цифры мягче: страницы находят быстрее, очередь обхода живее, но порядок приоритетов тот же. Заодно эксперимент напомнил, что favicon робот-картинок запрашивает десятки раз чаще других файлов - нормальное поведение, а не признак утечки бюджета.
Требования Google к постраничным адресам и каноникам без старых мифов
Свежие рекомендации системы сводятся к нескольким правилам. У каждой страницы серии - свой уникальный адрес с параметром вида page, потому что последовательность трактуется как набор отдельных страниц. Каноник каждая страница держит на саму себя, и направлять его на первую страницу серии прямо запрещено - это самая живучая ошибка из старых времён:
<!-- страница 2 категории с самоканоником -->
<link rel="canonical" href="https://www.example.com/catalog/boots/?page=2" />Между страницами должны стоять обычные ссылки в тегах a с честным href. Полезно и обратное правило: со всех страниц серии - ссылка на первую, это подсказка системе, что начало коллекции лучше подходит на роль целевой страницы. Фрагменты после решётки для номеров страниц не годятся: робот считает адрес без изменений уже знакомым и не идёт по ссылке. Фильтры и альтернативные сортировки система советует закрывать от индексации метой noindex или шаблонами robots.txt:
user-agent: *
disallow: /*?*order=
disallow: /*?*filter=Заголовки страниц серии стоит различать хотя бы номером в конце - посетителю проще вернуться на нужную страницу из истории браузера, а система точнее выбирает страницу под запрос.
Адреса серии можно строить и параметром, и сегментом пути - роботу понятны оба варианта, если ссылки честные. Первая страница серии заслуживает отдельного внимания: если у категории открыт и чистый адрес, и версия с параметром page=1, рождается дубль, который закрывают каноником либо редиректом на чистый адрес. При переезде структуры старые адреса пагинации уводят редиректами на новые страницы той же глубины, а не на первую страницу серии - иначе робот теряет хвост.
Частые ошибки пагинации которые находят почти в каждом аудите
Первая ошибка - каноник всех страниц серии на первую. Робот честно следует подсказке, хвост выпадает из индекса, а вместе с ним теряются товары и статьи, до которых нельзя было добраться иначе. Вторая - мета noindex на всех страницах кроме первой: приём из старых руководств, который сегодня просто удаляет хвост из выдачи и не даёт ссылкам внутри него работать. Третья - закрытие всей пагинации в robots.txt: путь к глубоким карточкам рвётся, и sitemap с товарами остаётся единственной ниточкой, о которой робот забывает медленно.
Четвёртая ошибка - пагинация только на JavaScript: кнопка, обработчик клика, новый контент без нового адреса. Робот не нажимает кнопки и не вызывает функции, привязанные к действиям пользователя, поэтому хвост для него не существует. Пятая - одинаковые метатеги на всей серии: сорок страниц с одним title конкурируют друг с другом в выдаче и портят сниппеты.
Шестая ошибка - смешивание параметров: сортировка и фильтры цепляются к адресам страниц серии, и пул URL множится быстрее, чем система успевает их обходить. У седьмой вариации тот же корень - динамические идентификаторы сессии в адресах пагинации, из-за которых робот каждый раз видит новую серию. Восьмая - вечная пагинация без последней страницы: адреса генерируются из ничего, и робот уходит в глубину, где нет ни контента, ни смысла. Честный финал за пределами серии - ответ 404.
Девятая ошибка - выбор страницы в выпадающем списке без честных ссылок: аккуратный select на JavaScript без адресов в href для робота пуст, и хвост снова невидим.
Единая страница архива вместо цепочки и её настоящие границы
Если архив помещается в одну страницу разумного веса, единая страница часто сильнее цепочки: весь контент живёт на одном адресе, все внутренние ссылки собраны в одном месте, нет риска, что робот бросит серию на середине, и нет мягких ошибок в хвосте. Старый приём с канониками со страниц серии на общую страницу view all в свежих рекомендациях не упоминается - система научилась выбирать сама, и странице серии достаточно самоканоника.
Для архивов блогов и страниц тегов единая страница - часто лучший ответ: несколько десятков заметок ложатся в разумный вес, поведенческие сигналы собираются в одну точку, и позиции не размазываются по цепочке похожих страниц. Для категорий с тысячами позиций правила другие, и там выручает только серия.
В руководствах начала десятых система прямо советовала держать единую страницу со всем контентом и канониковать на неё страницы серии. Идея view all Google нравилась всегда - изменились лишь механика и правила каноников.
Границы у подхода честные. Единой странице тяжело держаться в порогах LCP на мобильных, когда архив разрастается в тысячи позиций; вес страницы растёт, время до первого байта и отрисовки - тоже. Практичный компромисс - гибрид: архив бьётся на крупные секции, каждая со своим адресом и самоканоником, а внутри секции контент лежит цельным куском с якорями. Внутренние ссылки на якоря ставятся обычными тегами a, и робот видит всё с первого прохода. Границу подсказывают полевые метрики: если полная версия не держит пороги LCP на мобильных в реальном трафике, архив режется на секции без сожалений.
Бесконечная лента и кнопка Load more глазами робота
Для пользователей лента и кнопка удобны, и Google это признаёт: в сравнении паттернов пагинация показывает объём выдачи и текущую позицию, кнопка держит один адрес и честно сообщает остаток, лента интуитивна, но без ощущения конца утомляет. Робот смотрит на то же самое иначе. Он не прокручивает и не нажимает: порции, подгружаемые скриптом после действий пользователя, для него не существуют.
Рабочая схема для ленты прописана в рекомендациях по поэтапной загрузке: у каждой порции контента - настоящий адрес, прокрутка меняет его через History API, а в разметке стоят обычные ссылки на порции, по которым робот проходит без скролла. Продублировать адреса стоит и в sitemap.
Дублировать порции списком обычных ссылок внизу страницы - приём из той же серии: посетителю список почти не мешает, а робот получает карту всей ленты без единого клика. Выбор паттерна по объёму списка: пагинация держит большие каталоги, кнопка выручает средние списки, лента уместна для потоков обновлений, где порядок важнее полноты. Для переходов между страницами пагинации людям помогают resource hints: preconnect и preload к следующей странице ускоряют смену страниц, не влияя на обход.
Страховка обнаружения через sitemap товарный фид и контроль в отчётах
Даже идеальная цепочка ссылок - не страховка. Все страницы серии стоит добавить в sitemap, не забывая про лимит в 50 000 URL и 50 МБ на файл и про разбивку длинных серий через sitemap index. Для товарных каталогов второй страховкой служит фид Merchant Center: новые карточки через фид обнаруживаются быстрее, чем через цепочки, и спрос на страницы из фида у роботов Google формируется отдельно.
Контроль после настройки держится на трёх источниках: статистика обхода в Search Console показывает, доходит ли робот до последних страниц серии и как быстро, отчёт индексирования подсвечивает хвост со статусом "Обнаружено, сейчас не индексируется", а логи сервера отвечают на вопрос точно и по дням. Повторять проверку стоит после каждого релиза шаблона: пагинация ломается тихо, чаще всего правкой фронтенда, а всплывает в отчётах только через месяц. Фид Merchant Center полезен и для контроля: остатки, цены и свежесть карточек видны в нём раньше, чем в обходе, а ошибки разметки всплывают до того, как их принесут отчёты.
Здоровая пагинация в логах выглядит скучно и предсказуемо: робот проходит серию до конца, хвост перевешивается со стабильной частотой, а доля адресов фильтров и сортировок в обходе минимальна. Любое отклонение от этой картины - повод открыть шаблон и разобраться до того, как метрики испортятся окончательно.
План перехода архива на новую схему выглядит так:
- измерить объём полной выдачи и время LCP целой страницы на среднем мобильном устройстве;
- при тяжёлом весе сохранить серию с уникальными адресами и самоканониками на каждой странице;
- проставить видимые ссылки на соседние страницы и на первую страницу серии из любой точки;
- перевести фильтры и сортировки в noindex либо закрыть их шаблонами в robots.txt;
- добавить все страницы серии в sitemap и проверить по логам, добирается ли робот до хвоста.
Итог не изменился за семь лет и вряд ли изменится: роботу нужны честные адреса, обычные ссылки и собственный каноник у каждой страницы. Атрибуты rel next и rel prev остались в истории как удобный пример того, что даже официальные механизмы имеют срок годности - и что проверять стоит не разметку, а логи своего сервера.