What actually works for pagination and infinite scroll now
Pagination is one of those unglamorous corners of technical SEO where the most fossilized advice survives. Sites in 2026 are still shipping rel=prev/next tags that Google admitted back in 2019 it had stopped using. Others canonical every page in a series to page one and then wonder why products deep in the catalog never get indexed.
What actually matters now comes down to three things: crawlable URLs, sane canonicals, and infinite scroll that does not amputate half your site from Google's view.
rel=prev/next is long dead, stop shipping it
Google confirmed in 2019 that it had not used rel=prev/next as an indexing signal for a long time before anyone noticed. The mechanism was so inert its removal was invisible. The tags are harmless if your CMS emits them, but harmless is the ceiling. Do not spend engineering time on them, and do not let an audit tool scare you when they are missing.
What replaced them? Nothing, and that is the point. Google treats each paginated page as an ordinary URL. Your job is to make each of those URLs discoverable, crawlable, and honest about its own content.
Paginated pages need real, crawlable URLs
The foundation is boring and non-negotiable: every page in a series gets a unique URL, reachable through plain anchor links with href attributes. Query parameters like ?page=3 or paths like /category/page/3 both work fine. What does not work:
Buttons that fetch the next page via JavaScript with no link element at all.
Links that only exist after a click handler runs.
Fragment URLs like #page=3, which Googlebot ignores entirely.
Load-more buttons as the only path deeper into the catalog.
The blunt test works best: curl the page, or crawl it with Screaming Frog with JavaScript rendering off, and check whether page two is reachable. If a plain HTTP client cannot find the next page, deep pages get crawled late or never.
Canonicals should be self-referencing, not pointing at page one
This is the most common pagination mistake in audits. Someone decides page two is a duplicate of page one and canonicals the whole series to the first page. It is not a duplicate. Page two contains different items, and when you canonical it away, you are telling Google to ignore the only page that links to those items.
The correct pattern is simple: every page in the series canonicals to itself, cleaned of any tracking or sort parameters. Keep titles distinguishable, something like appending the page number, and do not noindex deep pages either. A long-standing noindex eventually leads Google to crawl those pages less and follow their links less, which quietly starves everything they link to.
Infinite scroll needs a paginated skeleton underneath
Infinite scroll is a UX decision, and often a good one. The SEO failure mode is building it as the only access path. Googlebot does not scroll like a human. It renders in a tall viewport, which may trigger a lazy-load batch or two, but it will not patiently thumb through forty batches of your catalog.
The fix has been the same for a decade and still works: pair infinite scroll with a paginated fallback using the History API. As the user scrolls and new items load, pushState updates the URL to the corresponding page, so /category?page=4 is a real address. Each of those URLs must also load directly as a page showing that page's items, with plain links to the previous and next pages in the initial HTML. Users get the endless feed, crawlers get a clean chain of ordinary pages. Verify with the URL Inspection tool in Search Console: fetch a deep URL and confirm the rendered HTML contains that page's items and its next link.
View-all pages are nice in theory, heavy in practice
A view-all page can be a legitimate consolidation target: if the whole series fits on one page that loads acceptably, you can canonical the paginated pages to it and let it collect all the signals. The catch is the loading part. A view-all page with two thousand products is a Core Web Vitals disaster on mobile. View-all only makes sense for small series, a few pages worth at most. Beyond that, self-canonicalized pagination wins.
Where pagination meets faceted navigation and crawl budget
Pagination rarely causes crawl problems alone. Pagination multiplied by facets does. Two hundred category pages times ten sort orders times fifty filter combinations times twenty pages each is how you manufacture millions of URLs overnight, and Googlebot will happily wander that maze at the expense of pages you care about.
The working rules: paginate only the canonical version of a listing. Sort orders and most filter combinations should not generate their own indexable paginated series; canonical them back to the default listing, and consider robots.txt disallows for facet patterns you never want crawled. Then watch the Crawl Stats report in Search Console and, on large sites, server logs. If a big share of Googlebot hits land on parameterized page-47 URLs, the maze is winning.
A checklist that holds up
Every page in a series has a unique, crawlable URL linked via real anchor tags.
Every page canonicals to itself, stripped of junk parameters.
No noindex on deep pages, no canonical to page one.
Infinite scroll is backed by History API pagination and direct-loading page URLs.
View-all only when the full list is genuinely small and fast.
Facet and sort combinations do not spawn their own crawlable paginated series.
Spot-check deep pages with URL Inspection and a non-rendering crawl.
None of this is clever, and that is the point. Pagination done right is invisible plumbing: crawlers walk it, users never notice it, and your deep inventory stays reachable. Fix the canonicals and give your infinite scroll a spine of real URLs.