Поисковая оптимизация обратной выборки, разбитой на части
Обратный порядок с разбивкой на части в терминах 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;
| $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".