Search
Enter at least two characters without personal information.

    LibraryArticles & FAQ Your projectRequest a quote
    LanguageEN
    Practical guides

    Design pagination for long website lists

    A list that loads everything becomes slow; a list whose later items exist only after scrolling can leave content undiscoverable.

    Go to the method

    Illustration of website project planning: Design pagination for long website lists

    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.

    Frozen fictional list: 23 records, 10 per page
    Requested pageExpected positionsCheck
    11–1010 distinct identifiers
    211–2010 identifiers, none seen before
    321–233 identifiers; end of list
    4Out of rangeExplain 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

    Content updated on

    Documented reference points for this topic

    Documented reference points for this topic
    ReferenceValue or syntaxScope
    WordPress REST API
    per_page=1…100X-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.

    Acceptance matrix to adapt to your project

    These proposed checks use synthetic cases. Decide the required behaviour with the team, record the result and assign unresolved gaps before release.

    Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

    Test cases, expected outcomes and useful evidence
    CaseExpected outcomeEvidence to retain
    The next page resets a selected filter.The filter persists and the current state remains identifiable.Initial filter and sort, pagination links and identifiers returned on the next page.
    The last page contains only one record.The count, previous and next link states and record remain consistent.Sample total, page size and final record identifier.

    Frequently asked questions

    Why might a record appear twice when changing pages?

    Check ordering, tied values and catalogue changes between requests. Define stable ordering with a tie-breaker, then test additions and removals. Depending on the need, cursor pagination or a consistent results view may be considered; do not promise a snapshot when the list is changing.