Какой атрибут в представлении позволяет настроить пагинацию

Пагинация¶

Django предоставляет несколько классов, которые помогут вам управлять постраничными данными — то есть данными, разделенными на несколько страниц, со ссылками «Предыдущая/Следующая».

‒ Django documentation

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

API пагинации может поддерживать любую из этих функций:

• Ссылки пагинации, которые предоставляются как часть содержания ответа.
• Ссылки пагинации, включенные в заголовки ответов, такие как Content-Range или Link .

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

Пагинация выполняется автоматически, только если вы используете общие представления или наборы представлений. Если вы используете обычные APIView , вам нужно будет самостоятельно обратиться к API пагинации, чтобы убедиться, что вы возвращаете ответ с пагинацией. Пример смотрите в исходном коде классов mixins.ListModelMixin и generics.GenericAPIView .

Пагинацию можно отключить, установив для класса пагинации значение None .

Установка стиля пагинации¶

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

REST_FRAMEWORK =  'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.LimitOffsetPagination', 'PAGE_SIZE': 100 > 

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

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

Изменение стиля пагинации¶

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

class LargeResultsSetPagination(PageNumberPagination): page_size = 1000 page_size_query_param = 'page_size' max_page_size = 10000 class StandardResultsSetPagination(PageNumberPagination): page_size = 100 page_size_query_param = 'page_size' max_page_size = 1000 

Затем вы можете применить новый стиль к представлению с помощью атрибута pagination_class :

class BillingRecordsView(generics.ListAPIView): queryset = Billing.objects.all() serializer_class = BillingRecordsSerializer pagination_class = LargeResultsSetPagination 

Или примените стиль глобально, используя клавишу настройки DEFAULT_PAGINATION_CLASS . Например:

REST_FRAMEWORK =  'DEFAULT_PAGINATION_CLASS': 'apps.core.pagination.StandardResultsSetPagination' > 

Справочник по API¶

PageNumberPagination¶

Этот стиль пагинации принимает номер страницы с одним номером в параметрах запроса.

Запрос :

GET https://api.example.org/accounts/?page=4

Ответ:

HTTP 200 OK < "count": 1023 "next": "https://api.example.org/accounts/?page=5", "previous": "https://api.example.org/accounts/?page=3", "results": [ … ] >

Настройка¶

Чтобы включить стиль PageNumberPagination глобально, используйте следующую конфигурацию и установите PAGE_SIZE по желанию:

REST_FRAMEWORK =  'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination', 'PAGE_SIZE': 100 > 

В подклассах GenericAPIView вы также можете установить атрибут pagination_class для выбора PageNumberPagination на основе каждого просмотра.

Конфигурация¶

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

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

• django_paginator_class — Используемый класс Django Paginator. По умолчанию django.core.paginator.Paginator , что должно быть хорошо для большинства случаев использования.
• page_size — Числовое значение, указывающее размер страницы. Если установлено, оно отменяет настройку PAGE_SIZE . По умолчанию имеет то же значение, что и клавиша настройки PAGE_SIZE .
• page_query_param — Строковое значение, указывающее имя параметра запроса, который будет использоваться для элемента управления пагинацией.
• page_size_query_param — Если установлено, это строковое значение, указывающее на имя параметра запроса, который позволяет клиенту устанавливать размер страницы на основе каждого запроса. По умолчанию None , что означает, что клиент не может контролировать размер запрашиваемой страницы.
• max_page_size — Если установлен, это числовое значение, указывающее на максимально допустимый размер запрашиваемой страницы. Этот атрибут действителен только в том случае, если также установлено значение page_size_query_param .
• last_page_strings — Список или кортеж строковых значений, указывающих на значения, которые могут быть использованы вместе с page_query_param для запроса последней страницы в наборе. По умолчанию (‘last’,)
• template — Имя шаблона, который будет использоваться при отображении элементов управления пагинацией в просматриваемом API. Может быть переопределено для изменения стиля рендеринга или установлено в None для полного отключения элементов управления пагинацией HTML. По умолчанию установлено значение «rest_framework/pagination/numbers.html» .

LimitOffsetPagination¶

Этот стиль пагинации отражает синтаксис, используемый при поиске нескольких записей в базе данных. Клиент включает параметры запроса «limit» и «offset». Ограничение указывает на максимальное количество возвращаемых элементов и эквивалентно page_size в других стилях. Смещение указывает начальную позицию запроса по отношению к полному набору непагинированных элементов.

Запрос :

GET https://api.example.org/accounts/?limit=100&offset=400

Ответ:

HTTP 200 OK < "count": 1023 "next": "https://api.example.org/accounts/?limit=100&offset=500", "previous": "https://api.example.org/accounts/?limit=100&offset=300", "results": [ … ] >

Настройка¶

Чтобы включить стиль LimitOffsetPagination глобально, используйте следующую конфигурацию:

REST_FRAMEWORK =  'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.LimitOffsetPagination' > 

Опционально можно также задать ключ PAGE_SIZE . Если также используется параметр PAGE_SIZE , то параметр запроса limit будет необязательным и может быть опущен клиентом.

В подклассах GenericAPIView вы также можете установить атрибут pagination_class для выбора LimitOffsetPagination на основе каждого просмотра.

Конфигурация¶

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

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

• default_limit — Числовое значение, указывающее предел, который следует использовать, если он не указан клиентом в параметре запроса. По умолчанию имеет то же значение, что и ключ настройки PAGE_SIZE .
• limit_query_param — Строковое значение, указывающее имя параметра запроса «limit». По умолчанию имеет значение ‘limit’ .
• offset_query_param — Строковое значение, указывающее имя параметра запроса «offset». По умолчанию ‘offset’ .
• max_limit — Если установлено, это числовое значение, указывающее на максимально допустимый предел, который может быть запрошен клиентом. По умолчанию установлено значение None .
• template — Имя шаблона, который будет использоваться при отображении элементов управления пагинацией в просматриваемом API. Может быть переопределено для изменения стиля рендеринга или установлено в None для полного отключения элементов управления пагинацией HTML. По умолчанию установлено значение «rest_framework/pagination/numbers.html» .

CursorPagination¶

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

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

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

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

Детали и ограничения¶

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

Вы можете изменить порядок, переопределив атрибут ‘ordering’ в классе pagination, или используя класс фильтра OrderingFilter вместе с CursorPagination . При использовании с OrderingFilter следует тщательно продумать ограничение полей, по которым пользователь может упорядочивать данные.

Правильное использование пагинации курсора должно иметь поле упорядочивания, которое удовлетворяет следующим требованиям:

• Должно быть неизменным значением, таким как временная метка, slug или другое поле, которое устанавливается только один раз, при создании.
• Должны быть уникальными или почти уникальными. Хорошим примером являются временные метки с точностью до миллисекунды. Эта реализация пагинации курсора использует интеллектуальный стиль «позиция плюс смещение», что позволяет ей правильно поддерживать не строго уникальные значения в качестве упорядочивания.
• Должно быть ненулевым значением, которое можно принудительно преобразовать в строку.
• Не должно быть поплавком. Ошибки точности легко приводят к неправильным результатам. Подсказка: вместо этого используйте десятичные дроби. (Если у вас уже есть поле float и вам нужно сделать постраничную обработку, используйте example «CursorPagination :doc:` subclass that uses decimals to limit precision is available here `).
• Поле должно иметь индекс базы данных.

Использование поля упорядочивания, которое не удовлетворяет этим ограничениям, как правило, будет работать, но вы потеряете некоторые преимущества пагинации курсора.

Для получения более подробной технической информации о реализации, которую мы используем для пагинации курсора, в статье блога «Building cursors for the Disqus API» дается хороший обзор основного подхода.

Настройка¶

Чтобы включить стиль CursorPagination глобально, используйте следующую конфигурацию, изменяя PAGE_SIZE по желанию:

REST_FRAMEWORK =  'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.CursorPagination', 'PAGE_SIZE': 100 > 

В подклассах GenericAPIView вы также можете установить атрибут pagination_class для выбора CursorPagination на основе каждого просмотра.

Конфигурация¶

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

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

• page_size = Числовое значение, указывающее размер страницы. Если установлено, оно отменяет настройку PAGE_SIZE . По умолчанию имеет то же значение, что и клавиша настройки PAGE_SIZE .
• cursor_query_param = Строковое значение, указывающее имя параметра запроса «cursor». По умолчанию имеет значение ‘cursor’ .
• ordering = Это должна быть строка или список строк, указывающих на поле, к которому будет применяться пагинация на основе курсора. Например: ordering = ‘slug’ . По умолчанию -created . Это значение также может быть переопределено с помощью OrderingFilter в представлении.
• template = Имя шаблона, используемого при отображении элементов управления пагинацией в просматриваемом API. Может быть переопределено для изменения стиля рендеринга или установлено в None для полного отключения элементов управления пагинацией HTML. По умолчанию установлено значение «rest_framework/pagination/previous_and_next.html» .

Пользовательские стили пагинации¶

Чтобы создать собственный класс сериализатора пагинации, необходимо унаследовать подкласс pagination.BasePagination , переопределить методы paginate_queryset(self, queryset, request, view=None) , и get_paginated_response(self, data) :

• Метод paginate_queryset передается начальному набору запросов и должен возвращать итерируемый объект. Этот объект содержит только данные запрашиваемой страницы.
• Методу get_paginated_response передаются сериализованные данные страницы, и он должен возвращать экземпляр Response .

Обратите внимание, что метод paginate_queryset может установить состояние экземпляра пагинации, которое впоследствии может быть использовано методом get_paginated_response .

Пример¶

Предположим, мы хотим заменить стандартный стиль вывода пагинации на модифицированный формат, который включает следующую и предыдущую ссылки во вложенном ключе „links“. Мы можем указать пользовательский класс пагинации следующим образом:

class CustomPagination(pagination.PageNumberPagination): def get_paginated_response(self, data): return Response( 'links':  'next': self.get_next_link(), 'previous': self.get_previous_link() >, 'count': self.page.paginator.count, 'results': data >) 

Затем нам нужно будет установить пользовательский класс в нашей конфигурации:

REST_FRAMEWORK =  'DEFAULT_PAGINATION_CLASS': 'my_project.apps.core.pagination.CustomPagination', 'PAGE_SIZE': 100 > 

Обратите внимание, что если вам важно, как порядок ключей отображается в ответах в просматриваемом API, вы можете использовать OrderedDict при построении тела постраничных ответов, но это необязательно.

Использование пользовательского класса пагинации¶

Чтобы ваш пользовательский класс пагинации использовался по умолчанию, используйте параметр DEFAULT_PAGINATION_CLASS :

REST_FRAMEWORK =  'DEFAULT_PAGINATION_CLASS': 'my_project.apps.core.pagination.LinkHeaderPagination', 'PAGE_SIZE': 100 > 

Ответы API для конечных точек списка теперь будут включать заголовок Link , вместо того чтобы, например, включать ссылки на пагинацию как часть тела ответа:

* Настраиваемый стиль пагинации, использующий заголовок «Ссылка».

Пагинация и схемы¶

Вы также можете сделать элементы управления пагинацией доступными для автогенерации схемы, которую обеспечивает фреймворк REST, реализовав метод get_schema_fields() . Этот метод должен иметь следующую сигнатуру:

Метод должен возвращать список экземпляров coreapi.Field .

Элементы управления пагинацией HTML¶

По умолчанию использование классов пагинации приводит к отображению элементов управления пагинацией HTML в просматриваемом API. Существует два встроенных стиля отображения. Классы PageNumberPagination и LimitOffsetPagination отображают список номеров страниц с предыдущим и следующим элементами управления. Класс CursorPagination отображает более простой стиль, в котором отображаются только предыдущий и следующий элементы управления.

Настройка элементов управления¶

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

• rest_framework/pagination/numbers.html
• rest_framework/pagination/previous_and_next.html

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

В качестве альтернативы вы можете полностью отключить элементы управления HTML-пагинацией, создав подкласс одного из существующих классов и установив template = None в качестве атрибута класса. Затем вам нужно будет настроить ключ настроек DEFAULT_PAGINATION_CLASS , чтобы использовать ваш пользовательский класс в качестве стиля пагинации по умолчанию.

Низкоуровневый API¶

Низкоуровневый API для определения того, должен ли класс пагинации отображать элементы управления или нет, раскрывается как атрибут display_page_controls на экземпляре пагинации. Пользовательские классы пагинации должны быть установлены в значение True в методе paginate_queryset , если они требуют отображения элементов управления пагинацией HTML.

Методы .to_html() и .get_html_context() также могут быть переопределены в пользовательском классе пагинации для дальнейшей настройки отображения элементов управления.

Пакеты сторонних производителей¶

Также доступны следующие пакеты сторонних производителей.

Pagination

Pagination – это компонент, используемый для загрузки данных по страницам. Это позволяет пользователям осуществлять навигацию по большому объему данных с предсказуемой производительностью.

См. также компонент SimplePagination, который имеет другое визуальное представление и может использоваться внутри Table , DataGrid и других компонентов-списков.

XML-имя компонента: pagination .

Основы

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

Чтобы использовать разбивку на страницы вместе с компонентом-списком, необходимо привязать компонент Pagination и компонент-список к одному и тому же источнику данных.

Привязка к данным

Чтобы создать Pagination , связанный с данными, используйте вложенный элемент containerProvider или loaderProvider .

У Pagination должен быть только один провайдер.

containerProvider

  (1)    (2)  

1	CollectionContainer для сущности Customer .
2	Компонент Pagination связан с источником данных с помощью атрибута dataContainer вложенного элемента containerProvider .

loaderProvider

     (1)     (2)  

1	citiesDl CollectionLoader загружает коллекцию сущностей по JPQL-запросу.
2	Компонент Pagination связан с источником данных с помощью атрибута loaderId вложенного элемента loaderProvider .

Количество элементов на странице

У Pagination есть специальный ComboBox со списком параметров для ограничения количества элементов на одной странице. Чтобы сделать его видимым, установите для атрибута itemsPerPageVisible значение true . Значение по умолчанию – false .

Значение по умолчанию для этого списка указано в свойстве jmix.ui.component.pagination-items-per-page-options.

Можете настроить свой список параметров, используя атрибут itemsPerPageOptions . Значением атрибута должен быть список параметров, разделенных запятыми:

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

Используйте атрибут itemsPerPageDefaultValue чтобы задать значение по умолчанию из списка параметров:

Атрибут itemsPerPageUnlimitedOptionVisible задает видимость неограниченного (null) значения параметра в списке ComboBox . Значение по умолчанию – true .

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

Максимальное количество загружаемых записей для всех сущностей определено с помощью свойства jmix.ui.default-max-fetch-size. Значение по умолчанию для этого свойства — 10000 . У конкретной сущности может быть другое значение максимального количество загружаемых записей, заданное с помощью свойства jmix.ui.entity-max-fetch-size.

Количество видимых страниц

Компонент Pagination позволяет изменять количество максимально видимых страниц с помощью атрибута maxVisiblePages . Страниц в компонент может быть много, но пользователи будут видеть сразу несколько страниц, в соответствии с атрибутом maxVisiblePages . Значение по умолчанию – 5 . Например, если установить maxVisiblePages=»3″ , будет видно только три страницы одновременно:

События и слушатели

Чтобы сгенерировать заглушку слушателя в Jmix Studio, выберите компонент в XML-дескрипторе экрана или на панели иерархии Jmix UI и используйте вкладку Handlers на панели инспектора Jmix UI.

В качестве альтернативы вы можете воспользоваться кнопкой Generate Handler на верхней панели контроллера экрана.

PageChangeEvent

PageChangeEvent отправляется, когда пользователь выбирает другую страницу или нажимает на кнопки навигации (следующая, предыдущая и т.д.).

Пример подписки на событие компонента Pagination , объявленного в XML с идентификатором pagination id:

@Subscribe("pagination") public void onPaginationPageChange(Pagination.PageChangeEvent event)

Чтобы создать слушателя события программно, используйте метод компонента addPageChangeListener() .

BeforeRefreshEvent

BeforeRefreshEvent отправляется перед обновлением данных, когда пользователь нажимает «следующая», «предыдущая» и т.д. Можно предотвратить обновление контейнера данных, вызвав метод preventRefresh() , например:

@Subscribe("paginationWithDefault") public void onPaginationWithDefaultBeforeRefresh(PaginationComponent.BeforeRefreshEvent event) < if (event.getSource().getDataBinder().getCount() >10) (1) event.preventRefresh(); (2) >

1	Проверьте количество экземпляров в хранилище данных.
2	Предотвратите обновление данных.

Чтобы создать слушателя события программно, используйте метод компонента addBeforeRefreshListener() .

AfterRefreshEvent

AfterRefreshEvent вызывается при обновлении данных.

Пример подписки на событие компонента Pagination , объявленного в XML с идентификатором paginationWithDefault :

@Subscribe("paginationWithDefault") public void onPaginationWithDefaultAfterRefresh(PaginationComponent.AfterRefreshEvent event)

Чтобы создать слушателя события программно, используйте метод компонента addAfterRefreshListener() .

TotalCountDelegate

TotalCountDelegate – это слушатель, который используется для получения общего количества элементов. Например:

@Install(to = "pagination", subject = "totalCountDelegate") private Integer paginationTotalCountDelegate()

Чтобы создать слушателя TotalCountDelegate программно, используйте метод setTotalCountDelegate() .

Все XML-атрибуты

Просматривать и редактировать атрибуты, применимые к компоненту, можно с помощью панели инспектора Jmix UI в конструкторе экранов Studio.

This page was built using the Antora default UI.

The source code for this UI is licensed under the terms of the MPL-2.0 license.

Правильная индексация страниц пагинации

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

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

Нужно ли закрывать ее от индексации

Однозначно — не нужно. Но для того чтобы пагинация не вредила продвижению сайта, необходимо выполнить определенные настройки. К сожалению, на данный момент ни в одной CMS данный функционал не реализован полноценно, что заставляет проводить доработки и вносить правки в логику работы. Если этого не сделать, то страницы-пагинации будут дублировать контент, заголовки и мета-теги первой страницы, а поисковые системы, как известно, негативно относятся к дублям на сайте.

Отношение к пагинации у Яндекса и Google

В своем блоге Яндекс советует использовать атрибут rel=»canonical» тега , в котором в качестве канонического адреса необходимо указывать первую страницу. В поиске будет участвовать только она одна, но остальные страницы будут посещаться поисковым роботом, с которых он перейдет на страницы товаров.

Google же предлагает три варианта реализации:

• Ничего не делать и положиться на алгоритмы Google — он сам выберет страницу с наиболее релевантным содержимым.
• В атрибуте rel=»canonical» в качестве канонической указать страницу «Показать все», на которой выводились бы все товары категории.
• Указать логическую связь между страницами пагинации с помощью атрибутов rel=»next» и rel=»prev» для тега .

Первый вариант отметаем сразу, так как в Яндексе будет полный беспорядок.

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

Третий вариант отлично работает для Google, но, к сожалению, данные атрибуты не воспринимаются Яндексом, и без дополнительных настроек будет неразбериха, как и при первом варианте.

Как правильно реализовать индексацию пагинации

Чтобы найти компромисс между рекомендациями Яндекса и Google, мы в своей работе придерживаемся следующих правил:

• Страницы пагинации открыты для индексации (исключение составляют страницы вида пагинация+сортировка и пагинация+фильтрация, если для фильтрации не предусмотрен корректно реализованный функционал
  смарт-фильтра).
• Текст с описанием категории выводится только на первой странице. На второй, третьей и так далее страницах он не выводится (не скрывается в display:none, а именно не выводится). Это актуально для интернет-магазинов и неактуально, например, для раздела статей или новостей — в этом случае у разделов не бывает описаний, а в качестве контента выступают превью статей/новостей.
• Первая страница должна быть доступна только по адресу без префикса пагинации. Например, в Bitrix пагинация по умолчанию строится с помощью GET-параметров, которые имеют вид PAGEN_1=N, где N — номер страницы пагинации.
  Допустим, первая страница категории имеет вид /catalog/category/, вторая — /catalog/category/?PAGEN_1=2, третья — /catalog/category/?PAGEN_1=3 и так далее. В этом случае важно, чтобы первая страница НЕ была доступна по адресу /catalog/category/?PAGEN_1=1 (это можно настроить с помощью 301-редиректов и правильного построения ссылок в навигационной цепочке).
• Мета-теги и заголовок Title не должны дублироваться. Например, если для первой страницы задан оптимизированный title, то для страниц пагинации его можно строить по шаблону «%name% — страница N», где %name% — название категории, а N — номер страницы пагинации.
• Используем атрибуты rel=»next» и rel=»prev» тега — для Google это будет плюсом, для Яндекса вреда не принесет.
• Несуществующие страницы пагинации должны отдавать 404 ошибку, либо перенаправлять на главную страницу раздела. Под несуществующими страницами имеются в виду страницы вида /catalog/category/?PAGEN_1=N, где N — больше реально существующего количества страниц в пагинации.

Можно заметить, что мы не во всем следуем официальным рекомендациям поисковиков, и вот почему:

• Указание в качестве канонической страницы вида «Показать все» для больших каталогов неприемлемо, как описывалось выше.
• Указание в качестве канонической первой страницы категории создаст трудности для Google — это не вписывается ни в одну рекомендацию и может создать проблемы при индексации и верном восприятии сайта.
• Задание уникальных мета-тегов и заголовков в совокупности с различными выводимыми товарами делает страницы пагинации уже не дубликатами — на каждой из них свой контент. По этой же причине связывать их через rel=»canonical» становится нелогично.
• Благодаря оптимизированным мета-тегам, заголовкам и описанию, в поиске приоритет всегда будет отдаваться первой странице категории. Однако если возникнет ситуация, что в выдаче Яндекса ее место займет какая-либо страница пагинации, это можно расценивать как сигнал о переоптимизации страницы, что упрощает обнаружение данного фильтра.

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

Руководство по использованию атрибута rel=canonical для канонических URL

При работе сайта часто возникает проблема дублирования контента. Если рассматривать на примере интернет-магазина, частым случаем является создание одинаковых товаров в разных категориях. Эти товары доступны по разным URL-адресам и, как уже понятно, содержат идентичный контент. Решение было представлено в феврале 2009 года. Ведущие компании в интернет сфере (google, bing, Yahoo) представили тег link с атрибутом rel=”canonical”. Данный элемент предназначен для обозначения канонической ссылки, которая указывает роботу на приоритетную страницу для индексирования, что позволяет избежать появления дублированного контента в индексе поисковой системы.

• Что такое rel=canonical
• Использование canonical
  • Размещение rel=canonical в исходном коде
  • Применение canonical на практике
    • Страницы пагинации
    • Товары в интернет-магазине
    • Canonical для статейных сайтов и блогов
    • Страницы с GET-параметром
    • Переезд сайта с http на https и другие зеркала сайта
• Как выбрать канонический урл
• Правила и некоторые особенности настройки canonical
• Основные ошибки использования rel canonical
• 301 редирект или rel=”canonical”
• Настройка canonical в разных CMS
  • WordPress
  • Joomla и Opencart
  • Bitrix
• Как проверить правильное написание канонической ссылки?
• Заключение: rel=canonical мощный инструмент для представления сайта в поиске

Что такое rel=canonical

Тег link с атрибутом rel=”canonical” является элементом html-кода. Его часто называют канонической ссылкой. Как и говорилось ранее, данный тег позволяет быстро и просто разрешить проблему дублирования контента. Суть такова, что имея два и более URL-адреса по которым доступен один и тот же контент с помощью каноникла мы указываем “главную” (каноническую) страницу. Это позволяет ПС “не обращать” внимание на множество дублей, а индексировать только один указанный документ. Грамотное использование данного атрибута положительно сказывается на SEO сайта.

Использование canonical

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

Размещение rel=canonical в исходном коде

Данный атрибут прописывается в исходном коде, внутри контейнера , пример представлен выше. Тег устанавливает связь со сторонним документом, будь то файл или страница. Для указания канонического урла нужно разместить внутри тега атрибуты “rel” и “href” со значениями “canonical” и URL-адресом канонической страницы соответственно.

Атрибут rel — показывает отношение текущего документа к файлу на который делается ссылка, в нашем случае выражает зависимость текущей страницы перед ссылаемой, href — указывает путь к файлу.

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

Применение canonical на практике

Страницы пагинации

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

Товары в интернет-магазине

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

• example.ru/odezda/shapka/
• example.ru/brand/shapka/

Видим, что один и тот же материал имеет разный ЧПУ. С точки зрения рядового посетителя это будет одна и та же страница, но для робота поисковой машины это не так. Canonical приходит к нам на помощь. Он позволяет указать роботу, что контент одинаков и нет смысла держать обе страницы в индексе. Завершающим шагом остается правильно выбрать каноническую страницу, об этом поговорим позже.

Canonical для статейных сайтов и блогов

При ведении блога или статейного сайта часто получается, что одна статья закреплена за разными рубриками. При этом, если на вашем сайте настроен вывод рубрики в ЧПУ, то возникает уже известная нам проблема, которая решается с помощью canonical:

• articles.com/seo-optimization/canonical/
• articles.com/html-tegy/canonical/

Страницы с GET-параметром

Часто на интернет ресурсах используется get-параметр для разных нужд. Этот параметр изменяет URL фактически не изменяя контента. Настройка canonical для таких страниц не всегда обязательна, порой проще закрыть от индексации. Однако, существуют исключения. Рассмотрим на примере версии для печати. Обычно данная версия отдается в адресной строке браузера путем приписывания к URL параметра ?print=Y или других его вариаций. Получаются следующие страницы:

• http://site.ru/product/
• http://site.ru/product/?print=Y

Нет смысла держать в поиске данную версию. В таком случае следует настроить каноникал со ссылкой на страницу http://site.ru/product/, являющуюся оригинальным документом.

Переезд сайта с http на https и другие зеркала сайта

Canonical можно настраивать и при смене протокола безопасности. При этом на каждой странице с http протоколом нужно разместить каноникал со ссылкой на ту же страницу, но с протоколом https. Рел каноникал можно использовать и при обозначении главного зеркала сайта. Но о целесообразности подхода представленного в этом пункте будем рассуждать ниже.

Как выбрать канонический урл

Вернемся к теме выбора канонической страницы, это является немаловажным фактором при настройке canonical. Правильное выделении документа куда будут ссылаться наши дубли очень важно. Рассмотрим основные пункты на которые стоит выделить особое внимание при выборе канонического URL:

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

Правила и некоторые особенности настройки canonical

1. Тег rel=”canonical” не является строгим правилом для роботов поисковых систем, а только лишь советует страницу в качестве каноничной.
2. Для настройки атрибута не обязательно стопроцентное совпадение контента. Подтверждения тому страницы пагинации. Однако, не стоит злоупотреблять. Если ПС уличит вас в использовании canonical для материалов с совершенно разным контентом, то впредь на данный атрибут внимания обращать не будет.
3. При написании canonical допускается использование как относительных, так и абсолютных ссылок. Но нужно быть аккуратным, могут возникнуть проблемы связанные с зеркалами сайтов. Пример написания в исходном коде таких ссылок выглядит следующим образом:
4. В размещении canonical самого на себя нет ничего страшного. Данное применение никак не сказывается на продвижении страницы. Даже существует версия, что так делать даже нужно. Утверждений по этому поводу делать не будем.
5. Размещение нескольких канонических ссылок на странице создают хаос. Надо быть аккуратными с установленными плагинами на WordPress и тому подобное.
   В случае если каноническая ссылка указана на разные страницы, скорее всего будет учтена только первая ссылка. если вообще будет учтена.
6. Ну и самое главное. Страница указанная в canonical должна быть открыта для индексации.

Основные ошибки использования rel canonical

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

1. Каноническая страница должна отдавать ответ сервера 200 OK. Страница не станет канонической, если при переходе на нее сервер будет отдавать ответ 404.
2. Часто каноническая страница закрыта от роботов ПС. Надо следить, чтобы страница была доступна для обхода роботами соответствующего поисковика.
3. Canonical указывается внутри HTML-тега head.

301 редирект или rel=»canonical»

Если возникают сомнения между использованием 301 редиректа и настройки canonical, что тогда? Если 301 редирект не будет нарушать логику образования ЧПУ, а также структуру сайта, то стоит отдавать предпочтение редиректу. К этому же относится и переезд сайта с http на https, о чем мы говорили ранее.

Настройка canonical в разных CMS

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

WordPress

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

• All in SEO Pack;
• Yoast SEO;
• Canonical SEO Content Syndication WordPress Plugin;

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

Joomla и Opencart

В данных движках сайта имеются проблемы с настройками rel=”canonical”, которые тянутся еще со старых версиях. Проблема выражается в записи некорректного URL адреса и криво настроенной адресации в CMS. Существует множество вариантов решения данной проблемы. Для обозревания каждого, можно написать не одну статью, но все они уже предложены умельцами на различных форумах и справочных ресурсах. На каком варианте остановиться выбирать только вам, каждый из них имеет плюсы и минусы.

Bitrix

Битрикс одна из самых гибких и передовых cms. Ее функционал поражает воображение, а в умелых руках сайт на bitrix становится произведением искусства. Для настройки canonical потребуется небольшие знания php и понимания работы самой CMS. А количество вариантов размещения ограничивается только вашим воображением. Каждый случай уникальный, зависит от настроенной адресацией на сайте. Приведем несколько незамысловатых примеров. Самый простой способ написания канонической ссылки самой на себя это в теге написать следующую строчку:

Наверное, один из самых “деревянных” и топорных методов. Для страниц пагинации нужно применять более изящные и сложные конструкции. Пусть на вашем сайте задана адресация для страниц пагинации следующим образом: http://site.ru/catalog/?PAGEN_1=2.

Тогда для настройки rel=”canonical” нужно воспользоваться знанием регулярных языков и также, как в примере выше, прописать функциональную часть кода:

Битрикс при генерировании страницы подставит данную строчку в тело тега head.

Как проверить правильное написание канонической ссылки?

Проверить правильность написания канонической ссылки конкретной страницы легко! Стоит открыть исходный код и путем поиска по странице ввести: rel=»canonical». На странице сразу отобразится ссылка, если она присутствует.

Но встает логичный вопрос. Как проверить наличие каноникалов на всех страницах сайта?

На помощь придут полезные, а порой, и незаменимые инструменты вебмастера: Screaming Frog SEO Spider, Xenu’s Link Sleuth и другие аналогичные инструменты. Данные программы позволяют посмотреть на какой странице размещена каноническая ссылка, куда она ведет и т.д.

Заключение: rel=canonical мощный инструмент для представления сайта в поиске

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