Поисковая оптимизация обратной выборки, разбитой на части

Обратный порядок с разбивкой на части в терминах Blox CMS означает, что в дескрипторе действуют одновременно два параметра: обратная выборка $params['backward'] и ограничение на число записей $params['part']['limit']. Типичный пример вывода записей в обратном порядке с одновременной разбивкой на части – это шаблон новостей. При выводе таких записей возникают две проблемы.

Проблема нумерации частей при обратной выборке и параметр numbering

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

Однако, в этом случае старые записи будут постепенно менять номера частей, на которых они находились (а следовательно и свой URL), но это неприемлемо с точки зрения SEO-оптимизации, поэтому такие данные обычно закрывают от индексации роботами.

Но есть простое решение проблемы – нумеровать части не с конца, а с начала. То есть, самые ранние записи должны находиться в первой части, а последние записи – в части с максимальным номером. В этом случае ссылки на эти части станут "вечными".

Номера частей логично выводить в убывающем порядке (см. пример нумерации). Для включения такого режима достаточно в дескриптор добавить параметр numbering:

Задать убывающую нумерацию частей (.tdd)
$params['part']['numbering'] = 'desc'

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

Проблема незаполненной последней части и параметр redistribution

Как только мы вводим описанный выше параметр numbering для оптимизированной нумерации частей, возникает новая проблема – на этот раз проблема юзабилити. Дело в том, что нарезка данных на части теперь начинается с более ранних записей, и в последней части (самой интересной для пользователя) может оказаться всего одна запись. Но это неприемлимо с точки зрения юзабилити.

Наша задача – укомплектовать последнюю часть. Для этого в дескриптор нужно ввести параметр redistribution.

Суть метода заключается в следующем. Если последняя часть укомплектована не полностью, то есть число записей в ней меньше величины, заданной параметром $params['part']['limit'], то эта часть не отображается вовсе, а все ее записи перераспределяются в нескольких предыдущих частях. Параметр redistribution как раз и задает число частей, предназначенных для размещения записей последней части:

Перераспределить записи из последней части в предшествующих трех частях (.tdd)
$params['part']['redistribution'] = 3;

Примеры различных значений параметра redistribution
$params['part']['redistribution'] = 0;
(по умолчанию)
Последняя часть отображается недоукомплектованной.
$params['part']['redistribution'] = 1;Последняя часть не отображается. Все записи из последней части переносятся в предпоследнюю часть.
$params['part']['redistribution'] = 2;Последняя часть не отображается. Записи из последней части распределяются равномерно в предшествующих двух частях.
$params['part']['redistribution'] = 3;Последняя часть не отображается. Записи из последней части распределяются равномерно в предшествующих трех частях.

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

Заключение

Если необходимо вывести большое число записей в обратном порядке с разбивкой на части (reverse order pagination), оптимальным решением будет нумерация частей в обратном порядке и перераспределение записей из последней части в предшествующих частях (например в двух частях):

.tdd
$params['backward'] = true;
$params['part']['limit'] = 10;
$params['part']['numbering'] = 'desc';
$params['part']['redistribution'] = 2;

 

   



Особых технических проблем для постраничного вывода данных в обратнои порядке (реверсивная пагинация) нет.

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

В англоязычной литературе эту проблему называют "reverse order pagination" или "backward pagination".