Неработающая пагинация мешает просматривать каталог, статьи или заказы и может создавать дубли страниц для поисковых систем. Причина бывает на frontend, в параметрах URL, SQL-запросе, API или в конфликте с фильтрами.
Начните с одного списка без фильтров: сравните URL первой и второй страницы, сетевой запрос, набор ID в ответе и SQL-условия. После этого добавляйте сортировку и фильтры по одному.
Коротко: что сделать
- Проверить изменение page, offset или cursor в URL и запросе
- Сравнить ID элементов на соседних страницах
- Проверить общий count и размер страницы
- Проверить сохранение фильтров и сортировки
- Проверить canonical и ссылки next/prev при серверном рендеринге
Почему возникает проблема
Пагинация состоит минимум из интерфейса, параметров запроса и выборки данных. Ошибка в любом звене дает похожий внешний результат.
- Frontend меняет номер, но отправляет старое значение
- Backend считает offset с ошибкой на одну страницу
- ORDER BY не имеет стабильного дополнительного поля
- Фильтр сбрасывается при переходе
- Кэш не учитывает номер страницы
- Cursor строится по изменяемому или неуникальному полю
Пошаговая диагностика
Проверку лучше проводить на одном воспроизводимом примере и фиксировать результат каждого шага. Так можно быстро отделить первопричину от побочных ошибок и не менять несколько компонентов одновременно.
- Открыть Network и сравнить запросы page=1 и page=2
- Проверить limit и offset в серверном логе
- Выполнить SQL для двух страниц вручную
- Добавить вторичную сортировку по уникальному ID
- Отключить кэш и повторить проверку
- Проверить пустую, последнюю и несуществующую страницу
Как исправить
Исправление должно обеспечить стабильный порядок записей и единый источник параметров для интерфейса и backend.
- Нормализовать номер страницы и ограничить допустимый диапазон
- Использовать offset = (page - 1) * limit
- Добавить стабильный ORDER BY с уникальным полем
- Передавать фильтры и сортировку во всех ссылках
- Включить page или cursor в ключ кэша
- Возвращать корректный 404 или редирект для лишних страниц
Как проверить результат
- Пройти страницы вперед и назад
- Проверить отсутствие дублей и пропусков ID
- Изменить фильтр на второй странице
- Проверить каталог при одновременном добавлении записи
- Проверить мобильные кнопки и доступность с клавиатуры
Как не допустить повторения
Пагинацию стоит тестировать как контракт: одинаковые параметры должны давать предсказуемый набор записей.
- Добавить интеграционные тесты границ страниц
- Закрепить стабильную сортировку
- Логировать page, limit и фильтры при ошибке
- Проверять SEO-адреса после изменения каталога
Чего не стоит делать
- Не исправлять только цифры в интерфейсе
- Не использовать ORDER BY по неуникальному полю без ID
- Не отдавать бесконечно пустые страницы с кодом 200
- Не смешивать offset и cursor в одном сценарии
Что подготовить для диагностики
- URL проблемного списка
- Пример двух соседних страниц
- Параметры API или SQL
- Правила сортировки и фильтров
- Информация о кэше
Частые вопросы
Почему записи повторяются на разных страницах?
Обычно порядок нестабилен: несколько записей имеют одинаковую дату или цену, а уникальный ID в ORDER BY не добавлен.
Что лучше: offset или cursor?
Offset проще для небольших стабильных списков. Cursor надежнее для больших и часто изменяемых лент.
Нужен ли canonical на страницах пагинации?
Зависит от структуры и контента, но каждая полезная страница должна иметь последовательные индексируемые ссылки и корректный canonical.
Когда стоит обратиться за помощью
Стоит подключать разработчика, если пагинация связана с несколькими фильтрами, поиском, кэшем или большой таблицей и простая правка page не устраняет дубли и пропуски.
Итог
Рабочая пагинация опирается на корректные параметры, стабильную сортировку и проверяемый ответ backend. Для диагностики каталога, SQL и AJAX можно обратиться в @rabotator_support.