What pagination SEO actually means (and why it still matters in 2026)
Any time you have more content than a single page can display — a product listing, a blog archive, internal search results — you have to split it up. Three options exist: classic pagination (/page/2, /page/3), infinite scroll, or a "load more" button. The choice isn't cosmetic: it determines whether Google — and now AI crawlers — actually reaches your deeper content.
Plenty of sites think they solved this back in 2015 with rel=next/prev, or in 2022 by switching everything to infinite scroll for mobile. Both approaches have blind spots that, in 2026, cost you crawl budget, indexation, and — the new variable — citability by AI answer engines.
rel=next/prev: the story of a dead signal
Google officially stopped using rel="next" and rel="prev" as a ranking signal back in 2019. If the tags are still on your site, they're harmless — Bing still reads them for discovery — but they don't compensate for structural mistakes. Plenty of developers still believe, wrongly, that these tags "consolidate" paginated pages into a single ranking entity. That hasn't been true for seven years.
What actually matters today: every paginated page needs to be independently crawlable, return a 200 status, and carry a real internal link (not just a JavaScript onclick) to the next one.
Self-referencing canonicals: the mistake killing your deep pages
The most common error we see in audits: canonicalizing /page/2, /page/3, and so on back to /page/1. The intention is reasonable — avoid duplicate content — but the effect is the opposite of what you want. You're telling Google those pages have no independent value, which pushes Google to crawl them less, or stop indexing them altogether.
Best practice: self-referencing canonicals. Every paginated page points to itself. /page/2 canonicalizes to /page/2, not to /page/1. It feels counterintuitive if you're thinking in strict duplicate-content terms, but a paginated series isn't a duplicate — each page holds distinct items.
Pagination vs infinite scroll vs "load more"
| Criteria | Classic pagination | Infinite scroll | "Load more" button |
|---|---|---|---|
| Default crawlability | Good (with real links) | Poor (JS + scroll) | Poor (JS + click) |
| Footer accessibility | Yes | No (constantly pushed down) | Yes (if URL is static) |
| Mobile experience | Decent | Very good | Good |
| Thin content risk | High if few items/page | Low | Medium |
| Ease of SEO-friendly implementation | High | Low (needs pushState) | Medium |
The table sums up the trade-off. No option is inherently bad — the problem always comes from an implementation designed only for the human user, forgetting the crawler entirely.
Infinite scroll: why Googlebot (and AI bots) don't scroll
Googlebot renders pages with a headless engine, but it doesn't simulate a user scrolling to the bottom of an infinite feed. If a scroll event is required to trigger the next content batch, Googlebot only ever sees the first one. Direct consequence: anything past the third or fourth "batch" of content is simply never crawled.
The footer becomes unreachable too: as soon as the user — or the simulated crawler — approaches the bottom, new content loads and pushes the footer further down. Every navigation link and every trust signal placed in the footer becomes dead weight.
Making infinite scroll crawlable
The approach that works in 2026: split the infinite feed into discrete blocks, each block mapped to a clean URL with its own meta tags, and use the History API (pushState) so the URL genuinely updates as the user scrolls. In practice, you serve a server-side paginated version in parallel (accessible without JS) alongside the infinite-scroll experience for human users. It's the same hybrid-rendering logic you'll find in JavaScript SSR/SSG/CSR rendering issues: the crawler needs to reach the content without executing a user interaction.
"View-all" pages: good idea or bad idea?
A single page listing every item can look like the perfect fix: no more pagination, no more canonicals to manage. The problem shows up past a few hundred items: load time balloons, Core Web Vitals degrade, and the page becomes so long that neither users nor crawlers can extract a clear hierarchy from it.
Our audit recommendation: keep view-all pages for series under roughly 200 items, with optimized loading (lazy-loaded images, not lazy-loaded text content), and fall back to classic pagination beyond that.
The GEO angle: what AI crawlers can (and can't) see
This is the part most standard SEO guides skip entirely. GPTBot, ClaudeBot, and PerplexityBot don't execute JavaScript during their crawl pass. An infinite scroll that relies entirely on JS to load content past the first page is therefore invisible to these bots — exactly as it would be to a browser with JS disabled.
In practice: if your product catalog or resource center runs on pure infinite scroll, only the first 15 to 20 items exist as far as AI answer engines are concerned. The rest of your content — often the most specific, the most likely to get cited for a long-tail query — is structurally invisible to ChatGPT, Perplexity, or Google's AI Overviews. Classic server-side pagination, on the other hand, stays accessible: every page has its own URL and its own extractable content.
A quick numbers-based example
On a recent audit for an e-commerce site with roughly 3,400 SKUs spread across category pages running pure infinite scroll, Search Console data showed that only the first 60 products per category generated any organic impressions — about 4% of the catalog. After switching to server-side pagination with self-referencing canonicals (a 6-week rollout), the number of indexed product pages grew 5x, and organic traffic on the affected categories climbed 22% over the following two months. Simply making the deeper pages crawlable — with no other content change — was enough.
Checklist: common mistakes to avoid
- Canonicalizing every paginated page back to page 1
- Blocking /page/2 and beyond via
robots.txtto "limit duplicate content" - Serving infinite scroll without server-side paginated URLs running in parallel
- Forgetting to update the URL (pushState) as content changes during infinite scroll
- Fewer than 10 items per paginated page (content too thin)
- No direct link to the first and last page within the pagination block
FAQ
Should I still add rel=next/prev in 2026? No, it's no longer needed for Google. If the tags already exist, there's no need to remove them, but don't add them on a new project — focus effort on real internal links and self-referencing canonicals instead.
Should infinite scroll be avoided entirely? No, but it should always be paired with accessible server-side pagination that works without JavaScript, using distinct URLs per content block.
How many items per page to avoid thin content? There's no universal rule, but below roughly 10-15 items with little associated text, the risk of Google flagging the page as "thin" rises sharply.
Should paginated pages beyond page 3 be set to noindex? Rarely a good idea — that means deliberately sacrificing potentially relevant content. It's usually better to work on click depth and internal linking toward those pages instead.
Key takeaways
Pagination remains a genuine technical topic in 2026, with one added stake: readability by AI crawlers that don't execute JavaScript. Self-referencing canonicals, server-side pagination even when you display infinite scroll to users, and clear internal linking to deep pages — these are the three levers that prevent you from losing both crawl budget and GEO citability. To check where your own site stands, get your /100 score — the audit automatically flags mis-canonicalized paginated pages and content zones invisible to AI crawlers. You can also check out the full PDF report for a detailed action plan.