Estimated reading time : 4 min · Published
Define what each page contains
Choose a stable order, reasonable page size and explicit sort rule. Show result counts and active filters when relevant. An item should not vanish or appear twice as someone moves through the list.
Plan for new entries, removals and empty lists. The filter guide covers combinations of criteria.
Take a fictional, frozen list of 23 records, displayed 10 per page in a defined order. It has 3 pages: 10 + 10 + 3 = 23. Page 4 is out of range, rather than a valid fourth portion. Check the complete set of identifiers across the three pages: a correct total can still conceal a duplicate record and a missing one.
Repeat the test after inserting a new record at the beginning once page 1 has been read. The former tenth record becomes eleventh and can reappear on page 2 with OFFSET pagination. A tie-breaker stabilizes equal sort values but does not freeze the data between requests. Define whether the journey uses a live list or a consistent view; a sort order alone does not establish snapshot consistency.
- Predictable order and page size.
- Readable result count.
- No skipped or duplicated entry.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Requested page | Expected positions | Check |
|---|---|---|
| 1 | 1–10 | 10 distinct identifiers |
| 2 | 11–20 | 10 identifiers, none seen before |
| 3 | 21–23 | 3 identifiers; end of list |
| 4 | Out of range | Explain the state; no fabricated fourth batch |
- Google Search Central : Pagination
Google, consulted 22 October 2026: sequential HTML links, a distinct URL and a self-canonical for each page. These provisions do not guarantee indexing.
- PostgreSQL : LIMIT / OFFSET
PostgreSQL 18, consulted 22 October 2026: predictable subsets with LIMIT and OFFSET require a unique order through ORDER BY. The 23 records and insertion are fictional.
Provide accessible links
Give each results page a usable URL and HTML links to neighboring pages. Fictional example: someone opens page 3 of a filtered list directly; filters, sorting and position should be understandable without restarting. Identify the current page and check keyboard controls. A load-more button may complement this route without hiding its destinations.
Infinite loading may improve comfort, but keep a linked path to the content. Google pagination guidance explains how crawlers can discover all pages.
- Direct URL for each useful portion.
- Previous and next links usable.
- Current position announced.
Handle state and return journeys
Test back, refresh, filter changes and arrival from a shared link. People should recover their context rather than restart the list. On a phone, access to later pages should remain easy to find and activate.
Out-of-range pages and empty combinations need understandable messages. Automatically redirecting to page one can conceal a stale link and make diagnosis harder.
- Browser history tested.
- Filters and sort kept where appropriate.
- Empty states explained.
Check crawling and performance
Check links, subsequent page responses and canonical URL consistency. Fictional example: several records share a publication date; stable secondary ordering prevents arbitrary changes between requests. Also test an addition or removal between visits and explain limitations of a live list. A fast first page is insufficient if later pages lose records.
Measure on a representative catalogue, including its last page and mobile view. Repeat after adding entries: pagination that works today may break as volume or filters change.
- All entries reachable.
- URLs and canonicals coherent.
- Several pages checked for speed.
Reference documents
- Google pagination guidance · Source consulted
- PostgreSQL : LIMIT and OFFSET · Source consulted
Content updated on
Documented reference points for this topic
| Reference | Value or syntax | Scope |
|---|---|---|
| WordPress REST API | per_page=1…100 | X-WP-Total and X-WP-TotalPages provide totals needed for pagination. |
| Google Search · Canonical | rel="canonical" | A preference signal for Google; neither a redirect nor a selection guarantee. |
Dates indicate when references were consulted. These facts are neither a site audit nor an overall compliance statement.
