SEO-Friendly Pagination in 2026: Handling Page 2+, Load More, and Infinite Scroll After rel=next Died

Google stopped using rel="next" and rel="prev" for indexing years ago, and the replacement isn't a new tag — it's a different mental model. Pagination SEO is now about making sure deep items stay crawlable and that each paginated URL earns its own right to exist. Here's how to architect paginated series, view-all pages, and JavaScript "load more" so nothing past page 1 disappears from the index.

What actually changed with rel=next/prev

Google confirmed it had not used rel="next"/"prev" as an indexing signal for some time before formally announcing it. The tags weren't replaced by an equivalent. Google's guidance became blunt: treat each page in a sequence as a standalone URL, make sure they link to each other with real anchor tags, and let normal crawling discover the contents.

Two consequences follow:

• Page 2+ is not "duplicate" of page 1. Each paginated URL has a distinct set of items, so it should be indexable, self-canonical, and reachable by a crawler that doesn't run JavaScript.
• The real job is link equity routing and discoverability, not signaling a sequence. The question is no longer "how do I tell Google these pages relate?" but "can Googlebot reach item #847 in a category, and does it have enough internal links to get crawled?"

You can still keep rel="next"/"prev" in your markup — Bing and other tools use them, and they cost nothing — but do not rely on them for Google.

The core pattern: crawlable, self-referencing page URLs

For any paginated set (blog archives, category listings, multi-part articles), the durable pattern is:

1. Use real, unique URLs for each page — /blog/?page=2 or /blog/page/2/. Both work; pick one and be consistent. Avoid fragment-only URLs (#page=2) because Google ignores the fragment.
2. Each paginated URL self-canonicalizes. Page 2 points <link rel="canonical"> at itself, not at page 1. Canonicalizing every page to page 1 is the single most common way to make deep items vanish — you're telling Google pages 2–N are duplicates, so it drops their unique links.
3. Let every paginated page be indexable (no noindex) unless you have a specific thin-content reason. Even then, prefer letting them be indexed but not heavily promoted.
4. Link pages with crawlable anchors. The pagination control must render real <a href> links in the initial HTML, not <button> elements or onclick handlers. This is the part most JS frameworks get wrong.

"Load more" and infinite scroll: the discoverability trap

Infinite scroll and "Load More" buttons are UX patterns, not crawl patterns. Googlebot does not scroll, and it does not reliably click buttons. If your only path to item #50 is a scroll event or a click that fires a fetch, those items may never be discovered. The fix is the same in both cases: back the JS experience with paginated URLs.

The pattern that works (sometimes called progressive enhancement or "paginated infinite scroll"):

• Render the first page server-side at a clean URL.
• Each subsequent "chunk" of items must correspond to a real, crawlable URL (?page=2, ?page=3).
• Include those page URLs as actual <a href> links in the DOM — even if you visually hide them or render them inside a <noscript> fallback. The "Load More" button can hijack those same links with JavaScript for users while leaving the href intact for crawlers.
• Optionally use the History API (history.pushState) to update the URL as the user scrolls, so a user who lands on a scrolled position can share/bookmark a real page URL.

A "Load More" button done correctly is just a paginated link wearing a button costume:

<a href="/blog/page/2/" class="load-more" data-page="2">Load more</a>

JavaScript intercepts the click, fetches and appends items, and updates the href to page 3. Disable JS and the same element is a working link to page 2. That dual nature is the whole trick.

View-all pages: when they help and when they hurt

A "view-all" page consolidates every item onto one URL. Google has historically liked these because users often prefer them and they concentrate signals on a single URL. But they have hard limits:

• Use view-all when the full set loads fast — generally up to a few hundred items. If the page becomes multi-megabyte or slow on mobile, it fails Core Web Vitals and the consolidation benefit evaporates.
• If you offer both paginated pages and a view-all, you can canonicalize the paginated pages to the view-all page. This is the one case where canonicalizing pagination is correct — because the view-all genuinely contains every item the paginated pages do.
• Don't fake it. A view-all that lazy-loads items on scroll has the same crawl problem as infinite scroll. "View all" must mean all items are in the rendered HTML.

Routing crawl budget to deep items

Pagination is a weak way to get deep items indexed because page 30 of a category sits 30 clicks deep and accrues almost no internal links. Don't make pagination the only path. Layer in:

• XML sitemaps listing the canonical URL of every individual item (product, article, listing). This is your primary discovery channel for deep content — far more reliable than expecting a crawler to paginate 40 pages deep.
• Hub and facet pages that link directly to high-value items, shortening click depth.
• Related-item and "popular in this category" modules that create lateral internal links to items buried deep in pagination.
• Reasonable page sizes. Showing 20 items per page across 50 pages buries depth. Showing 100 items per page across 10 pages keeps everything within a few clicks. Balance against load time.

Handling parameters, sorting, and filters

Pagination rarely lives alone — it combines with sort and filter parameters, multiplying URLs. To keep crawl budget focused:

• Keep pagination parameters clean and consistent (?page=N), and keep them after filter parameters in a stable order.
• Canonicalize sorted variants (?sort=price&page=2) to the unsorted equivalent if the sort doesn't change which items appear — only their order.
• Use robots.txt to block crawling of low-value filter combinations, but never block paginated category pages themselves — that severs the path to deep items.
• Don't put pagination behind URL fragments or POST requests; both are invisible to crawlers.

Common mistakes

• Canonicalizing every paginated page to page 1. The classic killer. It de-indexes the unique items on pages 2–N. Each page should be self-canonical (unless a true view-all exists).
• noindex on all pagination. Over time, links on a noindex page are treated as nofollow, choking discovery of deep items. Let pages be indexable.
• Buttons instead of links. <button onclick> pagination renders zero crawlable paths. Use <a href>.
• Infinite scroll with no URL backbone. Beautiful for users, invisible past the first screen for crawlers.
• Relying on rel=next/prev for Google. Keep them for other engines if you like, but they do nothing for Google indexing.
• Treating sitemaps as optional. For large catalogs, item-level sitemaps are how deep content actually gets found.

A quick checklist

1. Every page has a unique, crawlable URL with a real <a href> link from the previous page.
2. Each paginated page is self-canonical and indexable (or canonical to a genuine view-all).
3. "Load more" / infinite scroll is backed by those same paginated URLs in the DOM.
4. Item-level XML sitemaps cover everything regardless of click depth.
5. Lateral internal links shorten the path to deep items.
6. Filter/sort parameter sprawl is canonicalized or controlled, but pagination itself is never blocked.

Get those six right and pagination stops being an indexing liability. The death of rel=next/prev didn't make pagination harder — it just removed the illusion that a tag could substitute for genuinely crawlable architecture.