Pagination divides long lists across multiple URLs. The decisions about how it’s implemented affect crawl budget, ranking signal distribution, and whether users can navigate the site at all. Modern pagination has several viable patterns; each works for different content types and breaks in different ways.
The pagination conversation in SEO changed in 2019 when Google announced it had stopped using rel=”prev” and rel=”next” link tags as indexing signals. The change left site owners to figure out paginated content without the explicit signals they’d been told to use. Seven years later, the patterns have settled into a few approaches that work, and a few that consistently produce problems.
This piece covers what pagination needs to accomplish, the patterns that work in 2026, and the implementation details that determine whether ranking flows where the site owner wants it.
What pagination has to accomplish:
Pagination exists for two reasons that pull in different directions:
| Goal | Implication |
|---|---|
| <strong>Make all content accessible</strong> | Every item in the list needs a path that crawlers and users can follow |
| <strong>Avoid overwhelming individual pages</strong> | Lists of 10,000 items don't load fast, don't display well, don't get scanned |
The trade-off determines the pattern. Approaches that prioritize accessibility (every item on a discoverable URL) lead to many pages with few items each. Approaches that prioritize page weight (each page substantial) lead to fewer pages with more items, or to patterns that don’t fully expose the content.
A blog with 200 posts can paginate at 20 posts per page across 10 pages, or at 50 posts per page across 4 pages, or use infinite scroll without traditional pagination. Each choice changes what gets indexed and how authority flows.
The patterns that work in 2026:
Four patterns handle most pagination needs:
Pattern 1: Numbered pagination with full URLs.
The classic approach: page 1 at /category, page 2 at /category/page/2, page 3 at /category/page/3. Each page is a distinct URL that returns its own content. Navigation links at the top or bottom let users move between pages.
What works: every page is crawlable through links. Users can bookmark specific pages. Search engines understand each page as a separate URL with its own content.
What needs attention: the pagination links should be standard <a href> tags, not JavaScript-only handlers. Page 1 should either be /category (without /page/1) or /category/page/1, but consistently one or the other across the site; mixing creates duplicate content.
Pattern 2: Load more with crawlable URLs in the background.
Users see a “Load more” button on page 1 that fetches and displays additional content without a page reload. In the background, the additional content is also accessible at distinct URLs (/category/page/2, etc.) that crawlers can follow.
What works: users get a smooth experience without page reloads. Search engines still crawl all pages through the background URLs.
What needs attention: the “load more” implementation has to actually expose the underlying URLs for crawling. A pure JavaScript pattern where /page/2 doesn’t exist as a server-rendered URL means crawlers can’t find the content beyond what JS loads.
Pattern 3: Infinite scroll with crawlable URLs in the background.
Similar to load more, but the additional content loads automatically as the user scrolls. Background URLs still provide the crawlable structure.
What works: maximum user experience for content-heavy sites where scrolling is natural.
What needs attention: the same as load more. The crawlable URLs have to exist and work for unauthenticated, JS-free fetches.
Pattern 4: View-all on a single page.
The entire list appears on one URL, often with internal anchors for navigation. No pagination in the traditional sense.
What works: maximum authority consolidation (all link equity flows to one URL). All content discoverable in one fetch.
What needs attention: page weight and performance. A view-all page with 5,000 items is slow to load, slow to scroll, and may exceed reasonable Core Web Vitals thresholds.
Why rel=prev/next no longer applies:
Google announced in March 2019 that rel=”prev” and rel=”next” link tags were no longer used as indexing signals. The announcement came as a surprise because the tags had been documented as standard practice for years.
The mechanism Google now uses: each paginated page gets evaluated on its own merits. Page 2 of a blog archive is a separate URL with its own content; Google decides whether to index it and how to rank it based on the standard factors.
The implication: pagination implementation should focus on accessibility (making content findable) rather than on signaling pagination relationships to Google. The tags can still be in the HTML if a CMS adds them; they don’t help, but they don’t hurt either. New implementations don’t need to bother with them.
E-commerce pagination: the cannibalization risk:
E-commerce category pages have a specific pagination problem. The category page itself (e.g., /shoes) targets the broad query “shoes.” Pagination produces /shoes/page/2, /shoes/page/3, and so on, each with similar but distinct content.
The cannibalization risk: if page 1, page 2, and page 3 are all indexed, they might split the ranking signal for “shoes.” Google has to choose which to rank, and the choice may not be page 1 (the one the site owner wants to rank).
The mitigation patterns:
- Canonical from pagination pages to page 1. Each /shoes/page/N has a canonical tag pointing to /shoes. The ranking signals consolidate on page 1; pagination pages don’t compete.
- Noindex on pagination pages. The pages are crawlable (Google can find products through them) but not indexed for ranking. Page 1 is the only page that competes.
- Self-canonical on each pagination page. Each pagination page canonicalizes to itself, allowing it to rank if Google decides it’s the best match for some query. The trade-off is potential cannibalization for the main category query.
The choice depends on whether the site values having pagination pages potentially appear in search results (for “shoes page 2” style queries, which exist for some sites) or values consolidating authority on the main category page.
For most e-commerce sites, canonical to page 1 is the safer default. Pagination pages rarely receive meaningful organic traffic on their own; the consolidation usually helps more than it hurts.
Blog and content pagination: a different calculation:
Blog category archives and tag archives have similar pagination needs to e-commerce but with different priorities.
The content on a blog category page is article titles, excerpts, and links to full articles. The full articles are at their own URLs (separate from pagination). The pagination pages exist primarily to help users browse the archive and to help crawlers discover articles.
For this pattern:
- Noindex on pagination pages often works well. Users can find articles through navigation, search, internal links, and the main category page. Pagination pages don’t need to rank for any query; they’re a discovery mechanism.
- Canonical to the main archive is an alternative if some pagination pages do receive organic traffic (rare but possible for specific topics).
- Self-canonical with the pagination pages standalone is the most permissive approach, accepting that some pages may compete for queries they shouldn’t.
The lighter-weight approach for blogs: noindex pagination pages, ensure articles are discoverable through other paths (sitemaps, internal links, related-articles modules), focus optimization on the main category page and the individual articles.
The view-all pattern: when it works:
A view-all page that shows all items on one URL can work for moderately-sized lists (50-500 items, depending on item complexity).
When view-all works:
- The list is small enough to load and scroll reasonably. A view-all page of 100 product cards is workable; 5,000 is not.
- Authority consolidation matters more than performance. All ranking signals flow to one URL.
- Users actually want to see the whole list. Some content types (a complete glossary, a complete product catalog for a small store) benefit from being on one page.
When view-all breaks:
- Performance suffers measurably. Slow LCP, slow INP from rendering many items, layout shifts as the list loads.
- The list exceeds practical browsing size. A 5,000-item page isn’t usable; users skim and leave.
- Mobile experience degrades. Long scrolling pages can be hard to navigate on mobile.
The hybrid approach: pagination for the default view, view-all as an option for users who want it. The view-all URL is canonical and indexable; the pagination URLs canonicalize to it. Best of both worlds for medium-sized lists.
Common mistakes in pagination:
Frequent pitfalls:
- JavaScript-only pagination with no crawlable URLs. “Load more” or “infinite scroll” patterns that don’t expose underlying URLs leave content uncrawlable.
- Inconsistent canonical strategy. Some pagination pages canonical to page 1, others to themselves, others to nothing. Google receives mixed signals.
- Pagination URLs that include sort and filter parameters. /category/page/2?sort=newest&filter=red creates combinatorial URL space; each combination is a separate URL.
- Page 1 at both /category and /category/page/1. Both URLs exist; both have the same content; duplicate content for the main category page.
- No way to navigate to page 1 from later pages. Users on page 5 want to get back to page 1. The pagination links should include numbered navigation, not just “next” and “previous.”
- Slow pagination loading. Each pagination click triggers a full page reload that takes 3-5 seconds. Users abandon; INP degrades on the next interaction.
Robots.txt patterns for pagination control:
When pagination produces URLs that shouldn’t be crawled (deep archive pagination, low-value combinatorial filter pages), robots.txt can keep crawlers focused on the valuable URLs. The patterns:
# Block deep archive pagination beyond page 50
User-agent: *
Disallow: /blog/page/5*
Disallow: /blog/page/6*
Disallow: /blog/page/7*
Disallow: /blog/page/8*
Disallow: /blog/page/9*
# Block paginated tag archives entirely (keep main tag pages)
User-agent: *
Disallow: /tag/*/page/
# Block pagination with sort or filter parameters
User-agent: *
Disallow: /*/page/*?sort=
Disallow: /*/page/*?filter=The discipline: block pagination patterns that produce no unique value, leave the main pagination intact (pages 1-N where N is meaningful), and verify with Search Console URL Inspection that the rules don’t accidentally catch valuable URLs. Wildcards in robots.txt are not standardized across all crawlers; Googlebot honors them, but bots without wildcard support may interpret rules differently. Test before deploying.
Performance considerations:
Pagination pages share the same performance requirements as any other page. The specific patterns that affect performance:
- Server-side rendering pagination pages keeps initial load fast and improves Googlebot’s ability to crawl efficiently.
- Pre-loading next page resources for likely user paths (the most common pagination direction) reduces perceived latency for “next page” clicks.
- Avoiding heavy client-side rendering for what should be simple list displays. A pagination page that re-renders 100 items in React on every navigation is slower than necessary.
For large e-commerce sites, pagination performance often produces the highest cumulative gain in user engagement metrics. Users browse multiple pages during a session; each pagination click that takes 2-3 seconds adds up to substantial cumulative wait time across the session.
The interaction with sitemaps:
Pagination URLs in sitemaps need careful thought. The options:
- All pagination URLs in the sitemap. Maximizes discovery; can overwhelm the sitemap with low-value URLs.
- Only main category URLs in the sitemap. Pagination URLs get discovered through crawling. Sitemap stays focused on important pages.
- Pagination URLs in a separate sitemap segment. A category-pagination-sitemap.xml that’s submitted but represents the lower-priority section.
The typical pattern that works: main category URLs in the primary sitemap; pagination URLs discoverable through links from the main category page but not in the sitemap. The sitemap signals importance; pagination pages aren’t priority indexation targets.
Mobile UX considerations:
Pagination patterns that work on desktop don’t always translate to mobile. The constraints differ in three ways:
- Numbered pagination requires more space than mobile screens have. A row of “1 2 3 4 5 … 47” buttons works at desktop widths; at mobile widths, the same row needs simplification (often just previous/next plus current page indicator).
- Infinite scroll feels more natural on mobile. The vertical scroll gesture matches how users navigate mobile content; on desktop, the same pattern can feel like the page never ends. Many sites implement different patterns per device class.
- Touch targets matter for pagination controls. Buttons need to be at least 44×44 pixels to be tappable reliably. Pagination implementations that use compact text links produce mistapped navigation on mobile devices.
The recommendation that works across most sites: implement pagination URLs and crawlable structure consistently across breakpoints, but adapt the visual UI to the device. The underlying URL structure (which is what affects SEO) stays the same; the UI surfaces it differently per device.
Site type as the determining variable:
Pagination is one of the few areas where the right answer depends substantially on the site type. E-commerce, blog, news, and reference sites all have legitimately different pagination needs. The patterns that work for one don’t always work for another.
The discipline that produces consistent results: choose a pagination pattern based on the content type and user behavior, implement it consistently across the site, and verify the implementation through crawl simulation and log analysis.
The sites that struggle with pagination are usually sites where the pattern emerged ad-hoc from CMS defaults rather than from a deliberate decision. The CMS produced pagination URLs the way it was configured to; SEO consequences emerged later. The retrofit is more expensive than the upfront decision.
The strategic question to answer first: should pagination pages rank, should they consolidate, or should they exist only as a discovery mechanism. The implementation follows the answer.