Pagination, infinite scroll and "load more" for search engines

Every list that is too long for one screen gets split somehow: numbered pages, a "load more" button, or infinite scroll. For users the choice is about convenience. For crawlers it decides whether the 400th product in a category or a blog post from three years ago can be found at all. Crawlers do not scroll and do not click buttons. They follow links. If a page of items is only reachable through an interaction, it may as well not exist.

This guide covers how search engines treat paginated series today, how to build each pattern so it stays crawlable, and the mistakes that most often cut off deep content.

What changed, and what did not

For years the standard advice was to mark paginated series with rel="next" and rel="prev" link elements so Google would treat them as one unit. In 2019 Google said it had not used those hints for indexing for some time. Today Google treats each paginated page as a normal page: it crawls it, may index it, and follows the links on it.

What did not change is the underlying requirement. Each page in a series needs its own URL, those URLs need to be linked with ordinary anchor tags, and the content on each page must be in the HTML a crawler receives (or in the rendered DOM, for search engines that render JavaScript). The rel attributes were never what made pagination crawlable; the links were.

Keeping rel="next" and rel="prev" in place does no harm. Other search engines may still read them and they cost nothing. Just do not rely on them.

Numbered pagination done right

Classic numbered pagination is still the most robust choice for search engines. The checklist:

• One URL per page, ideally with a query parameter (?page=2) or a path segment (/page/2/). Avoid fragment-only page numbers such as #page=2, because crawlers ignore everything after #.
• Page 1 has one URL. /hiking-boots/ and /hiking-boots/?page=1 should not both exist. Redirect the second to the first, or at least never link to it.
• Plain links to the next page, the previous page, and a few nearby page numbers, plus first and last. A link only to "next" turns page 30 into a chain of 29 hops.
• Self-referencing canonicals on every page. Pointing page 2 onward to page 1 tells search engines those pages are duplicates of page 1, which they are not, and the items listed only on later pages lose their path to discovery.
• Distinct titles, such as "Hiking boots – page 3". Duplicate titles across a long series show up as noise in audits and give users no context in search results.
• Stable ordering. If the default sort is "newest" or "best selling", items move between pages constantly. That is fine for users but means a crawler may see a product on page 4 one week and page 7 the next. It is another reason to give important items paths that do not depend on pagination.
• Out-of-range pages return 404. ?page=999 on a 12-page list should not return 200 with an empty list, or crawlers will waste requests on endless empty pages.

Infinite scroll that crawlers can follow

Infinite scroll loads more items as the user nears the bottom of the page. It is pleasant on mobile and invisible to crawlers unless you build a paginated backbone underneath it. Google's long-standing recommendation is to make infinite scroll a progressive enhancement over paginated pages:

1. Build normal paginated URLs first (?page=2, ?page=3…) that work on their own when loaded directly.
2. Render pagination links in the HTML, even if you visually hide them once the script takes over.
3. As the user scrolls and a new chunk loads, update the address bar with the History API (history.pushState or replaceState) to the URL of the chunk in view.
4. Make sure loading ?page=3 directly shows the items from page 3, not page 1 followed by scrolling.

The test is simple: disable JavaScript and open the list. If you can still click through to the deepest items, crawlers can too.

Load-more buttons

A "Load more" button is infinite scroll with a click. The same rule applies: if the button is a <button> that fetches items with JavaScript, crawlers will not press it. Make it an <a href="?page=2"> that JavaScript intercepts for users. Crawlers follow the href; users get the smooth in-place loading.

This one change fixes a surprising number of "Google only indexes my first 24 products" complaints. The template looks the same, the user experience is identical, and the deep pages become reachable.

Comparing the patterns

Pattern	Crawlable by default?	What to add	Best for
Numbered pages	Yes, if links are plain anchors	Self canonicals, distinct titles, 404 for out-of-range	Categories, archives, search engines' favourite
Load more	No, if it is a script button	Make the button a real link to the next page URL	Product grids on mobile
Infinite scroll	No	Paginated backbone, History API URLs, hidden pagination links	Feeds, inspiration galleries
View all	Yes	Fast loading; canonical from series pages if used as the main version	Short lists up to a few dozen items

Sorting, filters and parameters on top of pagination

Pagination rarely travels alone. A category page usually also has sort options and filters, and each of them multiplies the paginated series. Page 3 sorted by price, page 3 sorted by rating and page 3 filtered to one brand are three more URLs, each with its own page 4, 5 and 6.

The cleanest arrangement is to give only one ordering a crawlable paginated series, usually the default sort, and keep the rest out of the crawl. Sort links can be script-driven, or they can be ordinary links to URLs disallowed in robots.txt. Filtered views follow the rules for facets: if a filter deserves to be indexed, its own paginated series gets the same treatment as the main category; if not, none of its pages should be linkable.

Also check how your pagination links are built when a filter is active. A common template bug keeps every active parameter in the "next" link and appends a new page parameter each time, producing URLs like ?page=2&page=3&page=4. Crawlers treat each as a new URL, and the series never ends.

Do not make pagination the only path

Even well-built pagination is a weak route to deep items. Page 25 of a category is 25 links away from the category page, and each hop carries less weight. Important items deserve shorter paths:

• Subcategories and indexable facet pages that split a long list into shorter ones. The faceted navigation guide explains which ones to make indexable.
• "Best sellers", "new arrivals" and editorial collection pages linked from the main navigation.
• Contextual links from guides and articles, as described in the internal linking guide.
• An accurate XML sitemap. A sitemap does not pass link value, but it ensures discovery; see XML sitemaps that work.

For blogs, the same applies to date and tag archives. Archives are useful as a backstop, but topic hubs that link to the twenty best posts on a subject do much more for those posts than their position on page 9 of the chronological archive.

Checking a paginated series

1. Crawl from the category page with a desktop crawler and check that the last page of the series is reached. If the crawl stops at page 1, links are missing or script-only.
2. View source (not the inspector) on page 1 and search for ?page=2 or your pagination pattern. If it is not in the HTML, crawlers that do not render may never find it; see JavaScript sites and crawlers.
3. Check canonicals on pages 2, 3 and the last page. Each should point to itself.
4. Request an out-of-range page and confirm a 404.
5. Inspect a deep item with URL Inspection in Search Console. If it was "Discovered" but never crawled, its path is too long or too weak.

A quick run of the SEO checker on a category page also confirms the basics around it: canonical, robots directives, response time and whether the page is blocked from indexing.