Any listing page that splits content across multiple URLs — category pages, search results, blog archives — creates a pagination sequence: /category/shoes, /category/shoes?page=2, /category/shoes?page=3, and so on. Each of those is a distinct, crawlable URL. For a category with 40 pages of products, that's 40 URLs competing for the same topical intent, and how you handle that sequence determines whether crawlers spend their budget productively or burn it paging through near-duplicate shells.

rel=next/prev is dead — plan accordingly

For years, <link rel="next"> and <link rel="prev"> tags were the standard way to tell Google that a set of URLs formed one logical sequence, letting it treat the series as a single unit for ranking. Google officially stopped using these signals in 2019. They don't hurt anything if they're still in your markup from a legacy implementation, but don't build new pagination strategy around them — Google now evaluates each paginated URL largely on its own, using normal crawling and canonicalization logic instead of a declared sequence relationship.

legacy-pagination-tags.html

html

<!-- Deprecated since 2019 — Google no longer uses these for ranking -->
<link rel="prev" href="https://example.com/category/shoes?page=1" />
<link rel="next" href="https://example.com/category/shoes?page=3" />

What actually works: self-referencing canonicals per page

The current best practice is simple: give each paginated page its own self-referencing canonical, not a canonical pointing back to page 1. Page 2 of a category contains products that don't exist on page 1 — treating it as a duplicate to be consolidated removes real inventory from the index. The exception is true duplicate pagination, like a ?page=1 parameter that duplicates the unparameterized root URL — that one should canonicalize to the clean root.

page-2-canonical.html

html

<!-- https://example.com/category/shoes?page=2 -->
<head>
  <link rel="canonical" href="https://example.com/category/shoes?page=2" />
</head>

Canonicalizing every page to page 1 is the single most common pagination mistake

Teams do this thinking it consolidates ranking power onto one strong page. In practice it tells Google the products on pages 2 through 40 don't need to be indexed as distinct entities, which can quietly remove the majority of a catalog from search — a real-equity loss disguised as a best practice.

View-all pages: a legitimate alternative

If a category's full product set can reasonably load on one page without destroying performance, a 'view-all' page is a clean way to sidestep pagination entirely — one URL, one canonical, full content. Google has historically shown some preference for view-all pages in results when they're genuinely crawlable and performant. The tradeoff is page weight: a view-all page with 500 products needs lazy-loading and careful Core Web Vitals management, or you've just traded an indexing problem for a performance one.

Infinite scroll needs paginated fallback URLs

Infinite scroll without discrete URLs per 'page' is effectively invisible to crawlers past the first batch of content — Googlebot doesn't scroll or click 'load more' reliably. The fix is to pair infinite scroll with real paginated URLs behind the scenes (often via the History API updating the URL as the user scrolls), so each chunk of content is independently crawlable and linkable even though the human-facing experience feels continuous.

Pagination strategies compared

Approach	Crawl efficiency	Risk
Self-referencing canonical per page	Good — each page indexed on its own merit	None if content per page is genuinely unique
Canonicalize all pages to page 1	Looks efficient, actually harmful	Deindexes unique deep-page products
View-all single page	Very good — one URL to crawl and rank	Page weight / Core Web Vitals risk at scale
Infinite scroll, no distinct URLs	Poor — crawler sees only first batch	Majority of catalog never discovered
Infinite scroll + History API URLs	Good — same UX, crawlable fallback	Requires careful implementation

Noindex, but don't disallow, thin pagination tails

On very long pagination sequences (page 30 of a sparse category), the deep pages often carry little unique value and little search demand. A reasonable middle ground is noindex on the deepest pages rather than disallowing them in robots.txt — noindex still lets crawlers pass through to follow links and reach adjacent pages, while robots.txt disallow would cut off crawl paths to content linked only from those deep pages.

Internal linking still does the heavy lifting

Regardless of which pagination technique you choose, make sure the sequence is linked plainly with real <a href> tags, not JavaScript-only click handlers. A paginated sequence crawlers can't traverse is a sequence they can't discover past page one, no matter how clean the canonical and indexing setup is.

What's next

Pagination problems are really a subset of a bigger question: how does a crawler render and parse the page at all, especially when pagination or content loading depends on JavaScript execution.

Next: JavaScript SEO & Rendering →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →