
Pagination is splitting one long list — products, articles, forum threads — into a numbered sequence of pages. Get it wrong and the tail of your catalog quietly falls out of Google's reach: products on page 14 that no crawler ever discovers don't rank, don't sell, and don't show up in any report as "broken."
Pagination looks solved because every CMS ships it. It isn't. The ground shifted in 2019 and a lot of implementations — and a lot of audit checklists — never caught up.
The rel=prev/next story, and why it matters that it ended
For years the official answer was link tags in the head:
<!-- On /blog/page/3/ — the OLD guidance -->
<link rel="prev" href="https://example.com/blog/page/2/">
<link rel="next" href="https://example.com/blog/page/4/">In March 2019 Google announced it had stopped using rel="prev"/"next" as an indexing signal — and admitted it hadn't used them for years before the announcement. The tags are harmless (and other consumers like some browsers and accessibility tools still read them), but they do nothing for Google. If your pagination strategy is "we have rel=prev/next," you have no pagination strategy.
What replaced it is plainer: every page in the series is treated as an independent page. That means each page needs a self-referencing canonical, a real crawlable link path, and enough sense of place (title like "Running Shoes – Page 3") to stand on its own:
<!-- On /shoes/page/3/ — the CURRENT pattern -->
<link rel="canonical" href="https://example.com/shoes/page/3/">
<a href="/shoes/page/2/">Previous</a> <a href="/shoes/page/4/">Next</a>Pagination patterns compared, post-2019
| Pattern | Crawler discovery | Pros | Cons / SEO risk |
|---|---|---|---|
Numbered pages (/page/2/) | Excellent — plain links | Every item reachable in a bounded number of hops; easy to log-analyze; users can jump around | Deep items are many clicks from the category root; page 47 gets crawled rarely |
| "Load more" button (JS appends items) | None, unless each click also updates a real URL | Good UX middle ground; keeps one scroll context | If the button is not a progressively-enhanced <a href>, everything past batch one is invisible to crawlers |
| Infinite scroll | None by itself — Googlebot does not scroll | Engagement-friendly on feeds | Worst case for discovery; needs paginated fallback URLs (pushState to /page/n/ as the user scrolls) or the tail is gone |
| View-all page | Excellent | One URL concentrates all signals; Google historically liked this when it stays fast | Unusable past a few hundred items; page weight murders LCP on big catalogs |
| First page + strong internal linking (no series crawl reliance) | Good | Products discovered via sitemaps and cross-links instead of page-14 crawling | Requires disciplined XML sitemaps and merchandising links; pagination becomes UX-only |
The honest answer for most catalogs is numbered pages plus XML sitemaps carrying every product URL, so discovery never depends on a crawler walking to page 30. Where facets and pagination stack (/shoes/?color=blue&page=7), the URL count multiplies — settle your faceted navigation rules first, because facet math dwarfs pagination math.
How to check it on your own site
- Crawl and measure depth. In Screaming Frog, check Crawl Depth on your product/article URLs (Site Structure tab). Items sitting at depth 8+ are usually deep-pagination orphan candidates.
- Disable JavaScript and click through. Load a category with JS off (DevTools → Ctrl/Cmd-Shift-P → "Disable JavaScript"). If you cannot reach page 2 by clicking real links, neither can a crawler on the cheap render path.
- Curl page 2 and read the canonical.
curl -s https://example.com/shoes/page/2/ | grep -i canonical. It must point to page 2 itself, not page 1. - Check the status codes at the series edge. Request a page past the end (
/page/999/). It should 404 or redirect — an infinite series of empty 200 pages is a crawl trap. - Cross-check GSC. Pages report → filter URLs containing
/page/. A pile of "Duplicate, Google chose different canonical" on paginated URLs usually means page-1 canonicals (see mistakes below).
Common mistakes
- Canonicalizing every page to page 1. The most common finding in the wild. It tells Google pages 2–n are copies of page 1, so the links on them (your deep products) lose their discovery path. Fix: self-referencing canonicals on every page in the series.
- Noindexing pages 2+. Feels tidy, slowly strangles discovery — long-term noindexed pages get crawled less, and their outgoing links stop pulling weight. Fix: leave them indexable; they rarely rank anyway, but they must stay crawlable.
- "Load more" with no href. A
<button onclick>fetches items via XHR; the crawler sees 24 products and a dead end. Fix: progressive enhancement — a real<a href="/shoes/page/2/">that JS intercepts. - Pagination URLs blocked in robots.txt. Someone blocks
*page=*to save crawl budget and cuts off two-thirds of the catalog from discovery. Fix: only block pagination when every item is guaranteed discoverable elsewhere (sitemaps + cross-links), and verify that claim before shipping. - Unstable sort under the series. If default ordering shuffles per request, page boundaries move, crawlers see churn, and items flicker in and out of existence. Fix: deterministic default sort.
FAQ
Do rel="next" and rel="prev" hurt anything if I leave them in?
No. Google ignores them; some accessibility tools and browsers still use them. Leave them or remove them — just don't count them as an SEO measure.
Should paginated pages have unique titles and meta descriptions?
Append the page number ("Trail Running Shoes – Page 3"). That's enough to keep them distinguishable without writing copy nobody reads for page 3 of a listing.
Is infinite scroll bad for SEO?
Infinite scroll alone is, because Googlebot doesn't scroll. Infinite scroll paired with real paginated URLs updated via pushState — and reachable as plain links — is fine. The details are in this pagination vs load-more vs infinite scroll breakdown.
Should page 2+ be in my XML sitemap?
No. Sitemaps are for canonical content pages — put the products and articles in, not the series pages that list them.
How many items per page is right?
Whatever keeps the page fast and the series shallow. Larger page sizes (48–100 items) cut series depth substantially, which usually beats whatever marginal speed you save at 24 per page. The full implementation walkthrough is in the pagination implementation guide.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.







