Canonical в пагинации блога: что проверять
Как проверить canonical второй и следующих страниц блога: самостоятельные URL, ссылки пагинации, состав списка и отсутствие подмены первой страницей.
Вторая страница блога обычно показывает другие статьи. Указав для неё canonical первой страницы, можно сообщить поиску, что эти разные списки следует считать одной версией. Проверять нужно и тег, и фактическое содержимое.
Общий разбор SEO помогает собрать план аудита. Здесь задача конкретная: пройти последовательность списка и убедиться, что новые и старые материалы доступны по устойчивым адресам. Я бы начинал с первой, второй и последней страниц, затем проверял всю цепочку автоматизированно.
Отдельный адрес для каждого участка
Google рекомендует давать каждой странице пагинации уникальный URL и собственный canonical. В этой же документации говорится о последовательных ссылках через href. Кнопка, которая только выполняет JavaScript, не равнозначна обычной ссылке на следующий адрес для обхода.
Параметр page=2 подходит, если сервер действительно возвращает соответствующий список. Фрагмент после решётки не стоит использовать как единственное различие страниц. Проверьте прямое открытие адреса в новой сессии: посетитель должен попасть на тот же участок без предварительного нажатия «ещё».
| URL | Содержание | Canonical | Навигация |
|---|---|---|---|
| /blog | Первый набор статей | На выбранную первую версию | Ссылка на вторую |
| /blog?page=2 | Следующий набор | На вторую страницу | На первую и третью |
| /blog?page=3 | Следующий набор | На третью страницу | На соседние страницы |
| Номер за пределами списка | Предусмотренное поведение без ложного пустого материала | Согласован с ответом | Понятный путь к существующему списку |
Проверьте варианты первой страницы
Адреса /blog и /blog?page=1 могут показывать одно и то же. Выберите предпочтительную версию и согласуйте перенаправление либо canonical. Важно, чтобы внутренние ссылки, sitemap и метаданные не спорили между собой. Для страниц с разными статьями это решение нельзя механически копировать.
Отдельно проверьте недопустимые значения: текст вместо номера, отрицательное значение, пустой параметр, слишком большой номер. Приложение должно отвечать предсказуемо. Бесконечное число пустых страниц с кодом 200 затрудняет диагностику и может создавать ненужные адреса.
Тег не исправит повторяющийся список
Сравните ссылки на статьи на соседних страницах. Если параметры изменяются, но сервер всегда отдаёт первый набор, собственный canonical только размножит технически разные адреса одного списка. Найдите причину: чтение параметра, кеширование или сборка страницы.
Проверьте серверный HTML: ссылки и нужные заголовки должны быть доступны предусмотренному способу обхода. Не делайте вывод только по URL в адресной строке после клиентского переключения. Человек может видеть обновлённый список, а прямой ответ сервера — другую версию.
Сортировку и теги проверяют по другой логике
Список «по популярности», фильтр категории и последовательность дат могут пересекаться по содержимому. Для них нужен отдельный план индексирования и canonical. Удобная навигация для посетителя не обязывает открывать каждую комбинацию параметров для поиска.
Состояние страниц тегов оценивайте по самостоятельной пользе, а контент-хаб — по пути читателя между материалами. После исправления проверьте все реальные адреса и затем статус в поисковом инструменте. Правильная пагинация облегчает обнаружение; включение каждой страницы в выдачу остаётся отдельным результатом.