Any listing that doesn't fit on a single page (internal search results, blog articles, category products) needs some pagination mechanism, and that mechanism carries technical SEO implications that go beyond the visible user experience: it determines what content Google can crawl and index, and how authority gets distributed across the series' different pages.
rel=next/prev: the signal Google stopped using
For years, Google recommended marking pages in a paginated series with <link rel="next"> and <link rel="prev"> in the <head>, indicating the sequential relationship between them. Google officially confirmed in 2019 that it no longer uses this signal for anything related to crawling or indexing; it's still valid as metadata (having it generates no error) but keeping it today provides zero SEO benefit. It's a clear example of why it's worth periodically checking whether legacy technical practices still have any effect, instead of assuming what was true a few years ago still is.
Real pagination: every page with its own indexable URL
The technically most robust way to paginate remains the simplest one: every page in the series with its own URL (/blog/page/2, /blog/page/3) that Google can crawl and index independently, with clear navigation links ("previous" and "next," or page numbers) letting both users and crawlers move between them. This form guarantees content on page 2 onward is discoverable and crawlable, something not guaranteed at all with JavaScript-based alternatives.
Infinite scroll: the pattern that hides the most content without anyone noticing
Infinite scroll loads additional content dynamically as the user scrolls down the page, with no full reload nor, in many implementations, any URL change. The SEO problem is that Googlebot doesn't scroll indefinitely the way a curious user exploring a long listing would; in practice, it only processes content present in the initial load and, at best, a limited amount of additional scroll during rendering, as explained in the JavaScript and SEO guide. All content that only appears after several successive scrolls carries a real risk of never getting crawled.
The correct pattern: infinite scroll for the user, real pagination underneath
The standard technical solution isn't choosing between infinite scroll and pagination, but implementing both at once, in separate layers: for the user, the visual experience is uninterrupted continuous scroll; for the crawler, real pagination exists with its own URL for each content chunk, updating the browser's URL via JavaScript's History API as the user scrolls further (without that implying a page reload), so each chunk has its own independently indexable and shareable URL.
// When loading the next batch of content in infinite scroll,
// update the URL without reloading the page
history.pushState({}, '', '/blog/page/3');Canonical in pagination: when to consolidate and when not to
As explained in more detail in the canonicalization guide, a frequent mistake is pointing every page in a series' canonical toward page 1, which tells Google to ignore the specific content of pages 2 onward. This is only appropriate if those pages contain no unique relevant content (for example, comment pagination where the real value is in the main article, not in each comment page). If pages 2 onward index products or articles that don't appear anywhere else, each one should be self-referential in its canonical, because consolidating them would remove content that does provide independent search value from the index.
Pagination parameters and duplication with combined filters
On ecommerce sites, pagination is usually combined with filters (?page=2&color=blue&size=m), generating a volume of URL combinations that can grow exponentially. Managing these parameters is the same as described in the crawling and indexing guide for faceted navigation: deciding which combinations deserve to be indexable (usually very few, the ones with real search volume) and canonicalizing or blocking the rest so as not to waste crawl budget on combinations that will never rank on their own.
Click-based "load more": the middle ground between pagination and infinite scroll
A common intermediate pattern is a "load more" button that adds content to the current page without changing the URL until the user explicitly clicks. It carries the same technical risk as pure infinite scroll (Googlebot doesn't click buttons exploratorily) and requires the same fix: real pagination underneath, with its own URLs, even though visually the user only sees a button expanding the same listing.
Frequently asked questions
Should I remove rel=next/prev if I already have it implemented?
There's no need to remove it (having it causes no problem), but it's also not worth spending time adding it if you don't have it, since Google confirmed it has had zero effect on crawling or indexing since 2019.
Is infinite scroll always bad for SEO?
No, it's perfectly compatible with SEO if implemented alongside real underlying pagination (its own URL per content chunk, updated via the History API). The problem only shows up when infinite scroll is the only way to access that content, with no alternative URL.
How many products or articles should I show per page?
There's no universal optimal number; it depends on each item's weight and the resulting performance. As a practical reference, listings of 20 to 50 items per page usually balance browsing experience well against reasonable load time.
Should I index every page of a very long paginated series?
It depends on each page's real value: if page 47 of a listing barely gets any traffic and its content isn't substantially different from nearby pages, it may make sense to mark it noindex, follow to avoid diluting the set's relevance, keeping its links crawled but removing it from the index.
Should an ecommerce site's filters generate independent paginated pages?
Only combinations with real search volume and enough content differentiation deserve to be independent indexable pages; the rest should be managed with canonical toward the unfiltered view or via crawl blocking, as explained in the crawling and indexing guide.