Pagination SEO: Best Practices for Numbered Pages and Infinite Scroll

Why Pagination SEO Still Matters

Pagination creates one of the most common technical SEO challenges on content-heavy sites: the same (or very similar) content appearing at multiple URLs, split crawl budget across dozens of pages with thin content, and category pages competing with their own paginated variants for the same queries.

Get it right, and your paginated series consolidates authority on the right pages, Googlebot efficiently discovers your full content catalog, and your category landing pages rank for their target terms. Get it wrong, and you dilute signals, waste crawl budget, and create indexation confusion that takes months to untangle.

How Google Handles Pagination Today

Google dropped support for rel=prev/next in March 2019. The official position since: Google can understand paginated series without explicit markup, using signals like URL patterns, page content structure, and internal linking.

In practice, this means:

• Google evaluates each paginated page on its own merits — if it has unique, valuable content, it may index it. If it’s thin, it may not.
• Category page 1 typically receives the most PageRank via internal links and will rank for category-level queries.
• Pages 2+ have progressively weaker internal link equity and are often not indexed unless individually valuable.
• There is no “consolidation signal” like canonical provides — paginated pages are evaluated independently.

Numbered Pagination: The Standard Approach

URL Structure

Clean, consistent URL patterns help both crawlers and users understand pagination:

Preferred:
/blog/page/2/
/category/seo/page/3/
/products/?page=2

Avoid:
/blog/?p=2&sort=date&category=all&session=abc123
/content-type/category/subcategory/filter/page/2/

What to Include and Exclude

The critical decision: should your paginated pages be indexed at all?

Canonical Tags for Paginated Series

Two approaches — each has legitimate use cases:

Self-referential canonicals (page 2+ points to itself): Use when paginated pages have unique content and you want them eligible for indexing. Canonical signals to Google that this specific URL is the intended version.

Canonicalize to page 1: Use for true near-duplicates (same category page, different offset). Consolidates any signals to your main category page. Downside: pages 2+ won’t rank independently.

<!-- Page 1 - self-canonical -->
<link rel="canonical" href="https://www.example.com/blog/" />

<!-- Page 2 option A - self-referential (allow indexing) -->
<link rel="canonical" href="https://www.example.com/blog/page/2/" />

<!-- Page 2 option B - consolidate to page 1 -->
<link rel="canonical" href="https://www.example.com/blog/" />

Internal Linking for Paginated Series

Paginated navigation links distribute equity across pages 2+, but not efficiently. Supplement with:

• XML sitemap inclusion for pages 2+ (if you want them crawled and indexed)
• “View All” option as a single-page version for high-value categories (Google often prefers view-all when available)
• Category breadcrumbs on individual posts/products linking back to page 1

Infinite Scroll: The Hidden SEO Problem

Infinite scroll loads content dynamically as users scroll — great UX, poor crawlability if implemented naively. Googlebot can execute JavaScript, but it doesn’t scroll pages. Content loaded only on scroll is effectively invisible to most crawlers.

Google’s Official Recommendation for Infinite Scroll

Implement a JavaScript-powered infinite scroll that also exposes discrete paginated URLs. The pattern:

1. Initial page load at /category/ renders the first batch of content and loads as normal
2. As the user scrolls, additional content loads via AJAX
3. URL updates to /category/page/2/, /category/page/3/ as new content loads (pushState)
4. Each discrete URL is independently accessible — not just via scroll

This means if Googlebot crawls /category/page/2/ directly, it returns the correct content for that page. The infinite scroll experience is layered on top of functional paginated URLs, not instead of them.

Testing Infinite Scroll Crawlability

• Use Google Search Console URL Inspection to fetch and render specific pages in the series
• Disable JavaScript in your browser and verify content is visible on initial load
• Check server logs for Googlebot requests to page 2+ URLs — if they never appear, crawlers aren’t finding them
• Use Screaming Frog with JavaScript rendering enabled to compare crawled content vs. source

Load-More Buttons: The Better Middle Ground

“Load More” pagination (a button that appends additional items) is preferable to infinite scroll for SEO because:

• Content above the button is visible on initial page render
• Can be implemented with distinct URLs for each loaded state
• Clearer user intent signal than automatic scroll-loading

Implement with the same URL pushState pattern: button click loads content and updates URL to /page/2/, making that state independently accessible.

Crawl Budget Considerations

For most sites under 10,000 pages, crawl budget isn’t a meaningful constraint — Google will crawl everything it finds. For large sites (100K+ pages), paginated series can represent significant crawl waste:

• A blog with 5,000 posts at 10 per page = 500 archive pages, almost none of which will rank
• An e-commerce site with 200 categories × 20 pages each = 4,000 category archive pages

For large sites, consider:

• Increasing items per page to reduce total paginated URLs
• Noindexing page 2+ of thin archive series
• Using robots.txt to disallow page parameter variants that have no ranking value
• Ensuring pages 2+ have noindex if they’re canonicalized to page 1 (avoid sending conflicting signals)

E-Commerce Faceted Navigation: The Special Case

Faceted navigation generates URLs for every filter combination: color, size, price range, brand, rating. A modest catalog with 10 filter dimensions can generate millions of URL variants.

Strategy framework:

1. High-value facet combinations: Allow indexing for facet combinations that match real search demand (e.g., /shoes/womens-running/ targeting a real query). Requires keyword research to identify which facet combinations are worth indexing.
2. Low-value facet combinations: Noindex or block via robots.txt. URL parameters for sort order, view type, and multi-dimensional filter combinations rarely have search demand.
3. Parameter handling: Configure URL parameter handling to avoid Google crawling both /products/?color=blue and /products/?color=blue&sort=price as separate pages.

Site Audit Checklist for Pagination

• ☐ Are paginated URLs clean and consistent in format?
• ☐ Does page 1 have a self-referential canonical?
• ☐ Are pages 2+ indexed, noindexed, or canonicalized — and is the choice intentional?
• ☐ Is there a “View All” option for high-value categories?
• ☐ Is infinite scroll implemented with accessible paginated URLs?
• ☐ Are paginated pages included or excluded from XML sitemap intentionally?
• ☐ Does robots.txt block parameter variants with no ranking value?
• ☐ Are hreflang tags replicated across all paginated variants (for international sites)?
• ☐ Do paginated pages have unique title tags (not just “Category – Page 2”)?

Unique Title Tags for Paginated Pages

If you allow paginated pages to be indexed, give them unique, descriptive title tags — not just appending “Page 2” to the same title:

Page 1: "SEO Blog: Latest Search Engine Optimization Tips | OTT SEO"
Page 2: "SEO Blog - Page 2: More Articles on Technical SEO and Strategy | OTT SEO"
Page 3: "SEO Blog - Page 3: Content Marketing and Link Building Articles | OTT SEO"

Better: if paginated pages have thematic groupings (chronological or by topic), reflect that in the title.

Conclusion

Pagination SEO doesn’t require sophisticated tactics — it requires intentional decisions about indexation, canonical strategy, and crawl budget allocation. Decide which paginated pages have genuine ranking value, implement accordingly, and audit annually as your content volume grows. For infinite scroll, the non-negotiable requirement is implementing accessible URLs that function without JavaScript — everything else is layered on that foundation.