A hub that lists everything on one page rarely stays that way. Once a guides library, a catalogue or a blog passes a few dozen items, it is split over several pages, and each split creates choices that decide whether Google can find and index what sits on page two and beyond.
This article sets out what Google documents about pagination, “load more” and infinite scroll, and how to check a paginated hub. Where we give our own reading, we say so. It was prompted by a recent build, Letters in Linen, whose library of 55 guides is split across numbered hub pages.
When one list becomes several pages, and what Google can follow
Google’s pagination documentation gives the reasons sites show a subset of a list: a faster first load, less network traffic, less load on the backend, and fewer resource problems from very long lists. Its examples include category pages, blog posts, user reviews and comments.
It compares three patterns. Pagination uses next, previous and page-number links, and gives users a sense of result size and position. “Load more” buttons keep everything on one page but cannot handle very large numbers of results. Infinite scroll is intuitive, but the page says it can cause scrolling fatigue because the result size is unclear, and it too cannot handle very large numbers of results.
The documentation says Google generally crawls URLs found in the href attribute of <a> elements, and that its crawlers do not click buttons and generally do not trigger JavaScript functions that need a user action to change the page. “Load more” and infinite scroll are generally built with JavaScript. Our reading: any content that only appears after a click or a scroll needs a plain link route to the same content as well.
It also suggests a sitemap file, or a Merchant Center feed for products, to help Google find everything.
Include links from each page to the following page using anchor elements with an href, which helps Googlebot find later pages. Google also suggests considering links from every page in a collection back to the first page, as a hint that the first page may be a better landing page than the others.
Link the pages in sequence and give each one its own URL
The page is direct about URLs. Give each page a unique URL, for example with a ?page=n query parameter, because URLs in a paginated sequence are treated as separate pages. Do not use the first page as the canonical for the whole sequence; give each page its own canonical URL. Do not use a URL fragment, the text after a #, for page numbers, because Google ignores fragments and may not follow a link that differs only by one.
Titles, descriptions and the old next and previous tags
Google normally recommends distinct titles, but says pages in a paginated sequence do not need to follow that: they can share the same titles and descriptions, and Google tries to recognise pages in a sequence and index them accordingly. Our reading: numbering the titles is a choice for readers and for tidiness, not a requirement.
The page also says Google used to use rel="next" and rel="prev" links to identify page relationships, and no longer does, although other search engines may still use them. Our reading: a missing next or previous tag is not a fault to report for Google.
Infinite scroll needs real pages underneath
Google’s guidance on lazy-loaded content says an indexable infinite scroll gives each chunk its own persistent, unique URL, with the same content every time it loads. It recommends absolute page numbers, such as ?page=12, and warns against relative values such as ?date=yesterday. The chunks should be linked sequentially so they can be discovered, and the displayed URL should be updated with the History API as a new chunk becomes the main one on screen.
Keep sort orders and filters out of the index
If a list can be re-sorted or filtered, for example with ?order=price, each variant returns the same items in a different order. Google’s recommendation is to keep those variants from being indexed, using the noindex robots meta tag, or to discourage crawling of the URL patterns with robots.txt.
Common traps in a paginated hub
- Page numbers that exist only as buttons or fragments, so no crawlable link leads to page two.
- Every page canonicalised to page one, which tells Google the later pages are not worth indexing separately.
- Sort and filter parameters that multiply the same list into many crawlable URLs.
- A page number beyond the last page that returns an empty page with a 200 status. Google’s documentation on pagination does not cover this case. Its JavaScript SEO page says a missing page should return a 404 status, and our reading is that the same applies here.
Checking a paginated hub
A routine we would use, as our reading rather than a Google procedure: open page one, page two and the last page, and view the source of each. Check that the links to the other pages are real anchors with an href, that each page’s canonical points to itself, and that the items shown differ from page to page. Then request a page number past the end and check what comes back. Finally, inspect page two with the Search Console URL Inspection tool and compare the Google-selected canonical with the one you declared; that field appears only in the indexed data.
Where this fits at Cultured Digital: site architecture
Pagination belongs to information architecture and internal linking, which our architecture guide covers along with faceted navigation and parameters and large website analysis, and which our guide on shaping the site covers from the strategy side. We have also written about site structure as a strategy decision. The URLs we aim for on a build are logical, stable and human-readable.
The Letters in Linen project applied this to its guides hub, where each numbered page has its own canonical URL.