Pagination SEO Guide: How to Handle Paginated Content Without Wasting Crawl Budget

11 min read · Technical SEO · Last updated July 2026

Quick answer: Google deprecated rel=next/prev in 2019. Modern pagination SEO uses self-referencing canonicals on paginated pages, strong internal linking to page 1, and allowing Googlebot to crawl key pages while managing crawl budget by blocking low-value deep pagination pages.

Introduction

Pagination is one of the most consistently mishandled technical SEO issues on large sites. E-commerce category pages, blog archives, search results, and product listings all paginate — and most implementations either waste crawl budget on low-value pages or inadvertently block Google from reaching important products and content.

The confusion deepened when Google deprecated the rel=next/prev attribute in 2019, removing the only formal standard for signaling paginated series. Teams that had implemented it correctly now had no official replacement. Google’s guidance since then — “let Googlebot figure it out” — is technically correct but practically insufficient for sites with millions of paginated URLs.

This guide covers current best practices for every pagination scenario.

What you’ll learn:
– Why rel=next/prev was deprecated and what to use instead
– The canonical tag approach for paginated series
– When to allow vs block paginated URLs in robots.txt
– How infinite scroll and “load more” affect crawlability
– How to handle faceted navigation pagination
– Measuring whether Google is properly crawling your paginated content

Table of Contents

1. The rel=next/prev Deprecation: What Changed
2. How Google Handles Pagination Today
3. Canonical Tags and Pagination
4. When to Block Paginated Pages (and When Not To)
5. Infinite Scroll: The SEO Problem
6. Load More Buttons: A Better Pattern
7. Faceted Navigation Pagination
8. Internal Linking Within Paginated Series
9. Monitoring Paginated Crawl Coverage
10. Frequently Asked Questions

The rel=next/prev Deprecation: What Changed

From 2011 to 2019, Google supported rel=next and rel=prev HTML link attributes to signal paginated series. A category page 2 would include <link rel="prev" href="/category/"> to tell Google it was part of the same series as page 1.

In March 2019, Google announced it had stopped using these signals for indexing years earlier and formally deprecated the standard. The recommendation was to ensure each page provides value as standalone content and is crawlable via internal links.

This left three approaches that sites continue to use today:

1. Self-referencing canonicals: Each paginated page canonicalizes to itself, treating each page as a standalone document
2. Canonical to page 1: All paginated pages (page 2, 3, 4…) canonicalize to page 1
3. No canonicals, open crawling: Allow Googlebot to crawl and index all paginated pages

Each approach has tradeoffs, and the right choice depends on your content type and site size.

How Google Handles Pagination Today

Google’s current approach: it tries to identify paginated series without explicit signals. It looks for patterns in URLs (?page=2, /page/2/), in link structures (next/previous links in the HTML), and in content patterns.

For most sites under 10,000 pages, Google handles this adequately. It identifies that /category/page/2/ is part of a series with /category/, crawls the pages appropriately, and indexes either both or consolidates signals.

The problem emerges at scale. A large e-commerce site with 500 category pages and 20 pages of pagination each has 10,000 paginated URLs. Add faceted navigation (filter by color, size, brand) and that number explodes to hundreds of thousands. Google’s crawl budget cannot cover all of these, and without guidance, it will often crawl the wrong ones.

Canonical Tags and Pagination

Option 1: Self-referencing canonicals (recommended for most sites)

Each paginated page includes a canonical pointing to itself:

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

This tells Google: “This is a legitimate standalone page, not a duplicate.” It allows each paginated page to be indexed in its own right and to rank for queries that match the products on that specific page.

Use this when: Your paginated pages contain unique, valuable content (specific products not shown on page 1), and you want them crawled and potentially indexed.

Option 2: Canonical to page 1 (use with caution)

All paginated pages point their canonical to the first page:

<!-- On /category/page/2/, /category/page/3/, etc. -->
<link rel="canonical" href="https://example.com/category/">

This consolidates signals to page 1. Google treats all paginated pages as duplicates of page 1 and focuses crawl and indexing on page 1 only.

Use this when: Your paginated pages contain no unique content worth ranking (the same products appear on page 1 in different orders, or pagination is purely navigational). The risk: products only appearing on page 5 will never be indexed if page 5 is canonicalized to page 1 and never crawled independently.

Option 3: Let Google crawl everything (for large sites: not recommended)

No canonical tag guidance on paginated pages. Google crawls and indexes whatever it can reach. On a large e-commerce site, this wastes enormous crawl budget on low-value deep pagination pages.

Infinite Scroll: The SEO Problem

Infinite scroll loads new content as the user scrolls, without changing the URL or loading a new page. It is common on social feeds, news sites, and some e-commerce implementations.

The SEO problem: Googlebot does not scroll. It loads the initial page and follows links — it does not simulate user scrolling behavior. Content loaded by infinite scroll is invisible to Googlebot unless it is also accessible via direct URL.

Google’s official recommendation for infinite scroll is to implement it alongside a URL-based pagination system. The URLs (/page/2/, ?page=2) should load the same content that infinite scroll shows on scroll. Googlebot can then crawl individual page URLs and discover content, even though the user experience uses seamless scrolling.

If you use a JavaScript-based infinite scroll without URL pagination, most of your content is in a crawl dead zone. Products below the initial scroll position are not crawled, not indexed, and not ranked.

Load More Buttons: A Better Pattern

The “Load More” button pattern — where a button loads additional content without changing the URL — has the same crawlability problem as infinite scroll. The additional content is loaded by JavaScript after the initial page render. Googlebot does not click buttons.

The fix: make “Load More” a link to the next paginated URL, not a JavaScript function call.

Load More

Load More

The JavaScript can still intercept the click and load content via AJAX for a seamless user experience. But because the <a href> is present in the DOM, Googlebot can follow it and discover the products on page 2.

Faceted Navigation Pagination

Faceted navigation (filters for color, size, brand, price range) combined with pagination is the biggest crawl budget problem in e-commerce SEO. A category page with 10 filter options each with 5 values creates 5^10 = ~10 million potential URL combinations.

The standard approach:

Allow Googlebot to crawl filter combinations that have SEO value (pages that match keyword intent — “red running shoes size 10” might be a valid landing page). These should have self-referencing canonicals and unique, indexable content.

Block or noindex filter combinations with no SEO value (sort orders like “price low to high”, multi-value filter combinations like “red+blue running shoes”, paginated filtered pages like “red running shoes page 3”). Use <meta name="robots" content="noindex, follow"> for these or disallow them in robots.txt.

The decision is keyword research-driven: if real users search for “[filter value] + [category]” and there is search volume, that filtered page has potential value. If no one searches for it, it is a crawl budget waste.

Internal Linking Within Paginated Series

Regardless of your canonical strategy, paginated series should have strong internal links between pages and back to the root category.

Breadcrumbs: Every paginated page should have a breadcrumb linking back to page 1 and to parent categories. This both helps users navigate and passes PageRank back up the hierarchy.

Next/Previous links: Even though rel=next/prev attributes are deprecated, the visible <a href> next and previous navigation links still matter. They create a link chain through the series that Googlebot can follow to discover all products.

“View All” option: If your site allows users to view all products on one page without pagination, this is often the SEO-optimal choice for category pages with fewer than 200 products. A single page with all products linked from it is easier for Googlebot to crawl and index comprehensively.

Monitoring Paginated Crawl Coverage

Confirm Google is crawling your pagination correctly by:

1. Google Search Console → URL Inspection: Test a paginated URL (e.g., /category/page/5/) to see if it is indexed, the last crawl date, and what canonical Google is using.

2. Screaming Frog + robots.txt checker: Verify your robots.txt disallow rules are blocking only the URLs you intend to block and not inadvertently blocking paginated pages you want crawled.

3. Log file analysis: Filter server logs for Googlebot requests to paginated URLs. If Googlebot is not visiting /page/3/ and beyond, your products on those pages may not be indexed.

Key takeaway: Noindex + follow on pages 2+ is often the safest default for large e-commerce sites. It saves index budget (no thin paginated archive pages in the index), while still allowing Googlebot to discover and follow product links on every page.

Frequently Asked Questions

Did rel=next/prev stop working completely in 2019?
Google stopped using it for indexing. Some other search engines (Bing) may still respect it. You can leave it in the code for legacy compatibility, but it has no meaningful SEO effect on Google rankings.

Should page 2 appear in Google search results?
It depends on the content. A paginated news archive page 2 or a blog page 2 generally should not appear for search queries — it is not a useful landing page. Add noindex for clean pagination. But an e-commerce page 2 with specific products might legitimately rank for product-specific queries — use self-referencing canonical.

My category has 50 pages of pagination. Should I block all of them?
Evaluate how products are distributed. If all your best-ranking products are on pages 1–3, blocking pages 4–50 makes sense. But if pages 10–20 have strong products that external sites link to or that users specifically search for, blocking them removes potential ranking opportunities.

How does Next.js or React handle pagination for SEO?
JavaScript-rendered pagination has the same crawlability requirements as any other pagination. The paginated page URLs must return their content in the server-side rendered HTML, not require JavaScript execution for the content to appear. Next.js with SSG or SSR handles this correctly by default. Client-side-only routing does not.

Does paginated content hurt my domain’s overall SEO?
Thin paginated pages (pages that are nearly identical to page 1 with the same products rearranged) can contribute to index bloat signals if indexed in large numbers. Using noindex on deep pagination prevents this. Well-structured pagination with unique content per page does not hurt overall site health.

Conclusion

Pagination SEO in 2026 is about pragmatic crawl budget management, not rigid rule-following. There is no single “correct” approach — the right strategy depends on your content type, site size, product distribution across pages, and whether paginated pages have external links.

The default recommendation for most sites: self-referencing canonicals for pages 1–2 (or however far Googlebot naturally crawls), noindex with follow for deeper pages, and strong next/previous link structures for content discovery. Monitor with log files and GSC to confirm Googlebot is behaving as expected.

Let Ignited Nepal Handle This

We audit pagination implementations for e-commerce and content sites, identify crawl budget waste, and deliver specific canonical and robots.txt recommendations by URL template.

→ Request a Free Technical SEO Audit

Written by the Ignited Nepal SEO team. We build organic search systems for businesses across Nepal, Australia, UAE, USA, UK, and beyond. ignitednepal.com