Pagination SEO After rel=next/prev: The Honest Playbook

Search “pagination SEO” and page one is a museum. Guides refreshed last quarter still walk you through rel="next" and rel="prev" — markup Google admitted in March 2019 it had not used as an indexing signal “for a number of years.” The top organic result for the query is Google’s own documentation, an AI Overview sits above it, and the advice underneath still hedges on a tag that has been dead longer than most of the sites reading about it. What none of it answers is the question the person searching actually has: with the markup shortcut gone, what do I actually do with page 2 through page 40?

This guide answers that question the honest way: pagination stopped being a markup problem and became an architecture problem. You pick one of three patterns — paginated series, infinite scroll, view-all — deliberately, you implement it so crawlers can reach every item without drowning in near-duplicate URLs, and then you do the part every other guide skips: you verify in Search Console that indexation actually improved. This is a spoke of our agentic SEO pillar, and it leans on the same find → fix → verify discipline as the sibling guide on the repo-first technical SEO audit — pagination is just the layer of that audit where folklore has aged worst.

The tag everyone still recommends died in 2019

The history matters because it explains why the advice out there is so confused. For years, rel="next"/rel="prev" was the official answer: annotate the series, and Google would treat the paginated set as a loose sequence, consolidating signals toward the first page. Then in March 2019, Google’s Search Central account announced — retroactively — that the annotation had not been used in indexing for years. Not “we are deprecating it.” It was already gone, and nobody outside Google had noticed, because the web kept working.

That non-event carries the real lesson. Pagination never worked because of the markup; it worked when the underlying architecture was sound — unique URLs, real links, sensible canonicals — and broke when it was not, tag or no tag. The retirement did not change what Google rewards. It removed the comfortable illusion that a <link> element in the head could paper over an architecture that traps crawlers or floods the index with thin variants. There is no shortcut to reinstall. There is only the architecture.

Google retired rel=next/prev years before it told anyone, and rankings did not flinch. The markup was never carrying the weight. The architecture was — and still is.

What Google actually asks for now

Google’s current pagination documentation — the page that outranks every SEO blog on this query — is short and unambiguous, and most of it contradicts the folklore that survived 2019. Each page in a series is treated as a separate page, full stop. From that one fact, the rules follow: every page needs its own crawlable URL, pages should link to each other sequentially so a crawler can walk the series, and — the rule most sites get backwards — page 2 and beyond should not canonicalize to page 1. Google explicitly recommends against it, because a canonical pointing at page 1 tells the crawler the deeper pages are duplicates, and the items listed only on those pages can quietly lose their crawl path.

Notice the shape of the failures in the left column: every one of them tries to make pagination disappear — hide the deep pages, collapse them into page 1, block them. The documented guidance goes the other way: make the series legible. Real URLs, real links, one honest address per page. Boring, and correct.

Three patterns, one deliberate choice

Every listing surface — blog archive, category page, search results, product grid — is one of three patterns. The mistake is not picking the wrong one; it is inheriting one from a theme or component library and never checking what it does to crawlers.

Paginated series — the boring default that works

Numbered pages, unique URLs, sequential links. This is the pattern Google’s documentation is written around, and the one to default to when in doubt. The implementation bar is low but specific: ?page=2 or /page/2 as a real server-rendered URL, a self-referencing canonical on every page, next/previous links in the HTML (not injected on click), and page 1 living at the clean URL — with ?page=1 canonicalized or redirected to it so the root does not compete with its own duplicate. Titles should disambiguate (“Page 3 of …”), which costs nothing and stops paginated pages cannibalizing each other for the head term.

Infinite scroll — invisible without real URLs

Googlebot does not scroll, and it does not click “load more.” Content that only exists after a scroll event fires is content that does not exist, as far as crawling is concerned. Google’s documented fix is paginated loading: as the user scrolls, update the URL with the History API so each content segment has an address (?page=4), and make those same addresses reachable as plain links for clients that do not run your scroll handler — which includes the crawler. If your infinite scroll cannot be walked page-by-page with JavaScript disabled, everything below the first viewport is decoration. On a site we audited, a category redesign swapped numbered pages for a load-more button; nothing else changed, and items deeper in the catalog gradually fell out of the index — not penalized, just unreachable.

View-all — great until it isn’t

One page, every item, no series to manage. For small sets this is genuinely the cleanest answer: no duplicate risk, no crawl-depth problem, one URL accumulating all the signals. The failure mode is physics. A view-all page with two thousand products is slow for users and heavy for rendering, and Core Web Vitals will say so. The honest rule: view-all when the full set renders fast enough that you would happily land on it from a search result yourself; a paginated series the moment it does not. If you run both, pick one as the canonical surface and be consistent about which one internal links point at — running two parallel routes to the same items is how you hand Google a duplication puzzle it will solve without consulting you.

The two failure modes: thin duplicates and crawl traps

Every pagination bug that matters cashes out as one of two problems. The first is thin duplication: the same items reachable at many addresses. Sorted variants (?page=2&sort=price), filtered variants, the ?page=1 duplicate of the root, session parameters riding along on every page link. Each variant is a page Google must fetch, render, and deduplicate — and when it picks canonicals at scale, it sometimes picks yours wrong. The fix is subtraction: canonicalize sort and filter variants to the default order, keep parameters out of pagination links, and let exactly one address per page of the series exist.

The second is the crawl trap: pagination multiplied by faceted navigation. Twenty filters times fifty pages times four sort orders is four thousand URLs for one category — a space a crawler can wander for weeks without discovering a single new item. This is the pattern behind most “Discovered — currently not indexed” pileups on large sites: not a quality judgment, just a crawler with finite patience meeting a URL space with no bottom. The deep pages of your honest series then compete for crawl attention with thousands of junk permutations, and lose.

The repo-first pagination checklist

As with the broader technical audit, the fastest way to audit pagination is not a crawl export — it is reading the source. Pagination logic lives in a handful of files: the route that takes the page parameter, the metadata function that emits the canonical, the component that renders the page links. A bug there is a bug on every page the template renders, and you can know it from one file read. The crawl remains the fallback for sites you cannot read, and the check that what the code intends is what the server serves.

Verifying indexation actually improved

Here is the half no pagination guide ships. Pagination fixes are unusually easy to declare done — the code merged, the canonical looks right in view-source — and unusually hard to eyeball, because the payoff is distributional: items that were unreachable start earning impressions, weeks later, across hundreds of long-tail queries no one is watching. If you do not commit to a metric before the fix ships, you will never know whether it worked, and “done” will stand forever unexamined.

The discipline is the same proof contract that runs through our closed-loop method. Before the fix: record the finding as a task, name the metric that will judge it — for pagination that is almost always impressions on the affected URLs, because reachability shows up as being shown at all before it shows up as clicks — and set a target. Ship with a timestamp and the PR. Then wait roughly three weeks: Google has to recrawl the series, re-discover the items, and accumulate enough query data on both sides of the change for a comparison to mean anything. Re-read the metric, filtered to the deep-page item URLs, and write down the verdict: confirmed, regressed, or inconclusive. Page-indexing counts in Search Console give a supporting read — “Discovered — currently not indexed” draining down is what an unwound crawl trap looks like — but the impressions on the pages you freed are the number that proves items are not just indexed but shown.

Run it this way and pagination stops being a folklore debate and becomes an entry in your site’s measured history: on this site, unwinding the faceted crawl trap confirmed; the ?page=1 consolidation read inconclusive. Which numbers can carry that kind of weight — and which are vanity — is the subject of the sibling guide on SEO KPIs.

Pagination in a zero-click results page

One more reason to care in 2026: the query this article targets — 260 searches a month, modest difficulty — already carries an AI Overview, and so does a growing share of the long-tail queries your deep-catalog items answer. AI answers are assembled from pages that engines could crawl, index, and classify with confidence. An item stranded behind a scroll event or orphaned by a canonical-to-page-1 is not just unranked — it is uncitable, in every answer engine at once. The unglamorous crawl-path work in this checklist is the entry fee for the territory covered in our guide to zero-click SEO: you cannot be quoted from a page no engine ever reached.

If you want the find half run against your own property, the free SEO report connects your Search Console and surfaces where reachability is costing you — the sections earning impressions on page 1 of a series and silence underneath. And if you would rather the whole loop ran as a system — findings filed, fixes shipped, indexation verdicts read three weeks later — book a call.